05:15:18 -xmr-pr- ACK-J opened issue #8171: "Export_Transfers All" contains a duplicate attribute
05:15:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8171
09:38:51 <ErCiccione> Now that the new fee structure has been agreed on, should we have another meeting dedicated to the network upgrade?
10:13:56 <selsta> Saturday again?
10:27:19 <ErCiccione> I would move to sunday if there is nothing else planned at that time.
10:32:40 <Scalability> Community and MoneroKon meetings this Sunday. 1600 and 1800 UTC.
11:49:41 <ErCiccione> Saturday is fine for me, but depends by the people here
14:19:06 <Urawa> hello
16:00:11 <Siren[m]> Is the wallet file format documented somewhere?
16:00:32 <moneromooo> No.
17:40:44 <jeffro256[m]> Are there any plans to break up wallet2.cpp into multiples files? (as it is 14K lines currently with tons of scope creep). Is this even something that you all would like?
17:42:10 <UkoeHB> jeffro256[m]: there is this https://github.com/monero-project/monero/issues/8157#issuecomment-1021530383 from endogenic 
18:12:32 <fullmetalScience> Is there a known bug for the amount of an outgoing transaction being correct as long as it is "pending", but dropping to 0 once the transaction is confirmed?
18:14:08 <fullmetalScience> So far I've tried four times with two different node addresses.
18:15:46 <moneromooo> No.
18:16:00 <moneromooo> File a bug on github with all the info you have.
18:17:34 <UkoeHB> fullmetalScience: are you sending the amount to your own address?
18:19:06 <fullmetalScience> UkoeHB: Damn. I must not have been thinking straight.
18:19:57 <moneromooo> If you're implying this'd be the reason, it should not, it's meant to keep the info. It'll only go back to 0 when rescanning, which is not the case here.
18:22:04 <fullmetalScience> The destination I intended to send to also has a dedicated sub-address in my wallet. So when I did `address all` and just copied the address next to the name of that "destination" I tricked myself into thinking I copied their address from `address_book`.
18:23:18 <UkoeHB> Well... in jamtis we have some methods of disambiguating self-spends from change outs, so hopefully it will be easier to track that kind of thing.
18:24:43 <fullmetalScience> moneromooo: I'll blame my auto-pilot on this one 😁
18:27:31 <fullmetalScience> I'm having a look at the jamtis readme right now. Thanks for the hint - very helpful.
18:45:24 <aksion[m]> Tell me, is mining theoretically possible, just to secure your transaction? That is, those will have the priority right to mining and only to the extent that they provide a commission for their transaction. But if you are too lazy yourself, then already at the auction to sell this right to mine another.
18:47:51 <UkoeHB> what?
18:47:54 <moneromooo> Can you rephrase that ? I have no idea what it means.
18:47:57 <selsta> :D
18:48:37 <moneromooo> If you sent a tx, you can certainly mine and hope to contribute to securing your tx.
18:49:14 <moneromooo> Your chance of finding a block with your tx being your hash rate over the network hash rate.
18:53:19 <aksion[m]> <moneromooo> "Can you rephrase that ? I have..." <- To make sure that only those who make a transaction (transfer) have the right (opportunity) to mine. And mining in the amount necessary to ensure this transfer (transaction). Then the problem with complexity and empty balls is solved. Those who actually make the transaction will mine. You won't need a lot of complexity
18:54:01 <moneromooo> Why would you want to do that ?
18:54:13 <selsta> Don't broadcast your transaction if you don't want others to mine it.
18:56:08 <aksion[m]> moneromooo: To improve the energy efficiency of cryptocurrencies. Reduce the complexity of mining. So that anyone can mine on a weak device and not for profit, but to support the system and their transaction. That is, the system will be supported by the volume of people who actually use it.
18:57:10 <moneromooo> Why do you think it would improve the energy efficiency of cryptocurrencies ? Why do you think it would reduce the complexity of mining ?
19:01:14 <moneromooo> I think I see why you think it would improve the energy efficiency of cryptocurrencies.
19:01:29 <moneromooo> But if Alice is a miner, then Alice could, for every block she wants to mine:
19:01:35 <moneromooo> - create a scratch tx
19:01:42 <moneromooo> - include it in the block
19:01:47 <moneromooo> - try to mine it
19:02:13 <moneromooo> If she finds a block, she spent nothing, though the chain has extra data to verify
19:02:29 <moneromooo> If she does not find a block, she loses nothing, since the tx was not relayed
19:02:46 <moneromooo> So the only difference with now is one extra pointless tx per block, adding to chain bloat
19:02:55 <moneromooo> Am I wrong and did you have a better idea ?
19:06:47 <fullmetalScience> Would Jamtis be any different for vanity address generation?
19:15:27 <aksion[m]> <moneromooo> "Am I wrong and did you have a..." <- The idea was this - that's accumulated in the queue of transactions that need a block. All these people have the priority right to mine (search) this block on their computing devices. They merge into a temporary pool or p2pool, find a block, commit their transactions and the temporary pool breaks up. Then the next ones. If someone does not want to participate, they delegate the right to
19:15:27 <aksion[m]> mine this transaction in a free manner at the auction.
19:16:07 <moneromooo> That looks like incresaing mining complexity by a huge amount.
19:17:23 <moneromooo> You'd have to have this secondary pool be PoW maintained in order for the "right to mine" to be consensus. I think this might just move the hash rate, not reduce it.
19:17:33 <moneromooo> Not quite sure though.
19:19:47 <aksion[m]> moneromooo: How many transactions are placed in a block? Not so much. This means that a small number of people will have the right to find the block, which means that the complexity can be done a little
19:21:10 <moneromooo> By complexity, do you mean difficulty ?
19:22:27 <moneromooo> (aka hash rate)
19:23:54 <fullmetalScience> aksion[m]: Everyone who desires to mine would just add their transaction to the pool, just as moo explained. Then you would have the same hashrate as today, but blocks bloated with effectively useless transactions.
19:24:21 <aksion[m]> I don't really understand the intricacies of the whole technology, I just thought that it was necessary to somehow remove mining into the void, when people mine not for the sake of maintaining the system, but for profit, thereby forcing them to increase complexity due to the large number of miners. The complexity should be proportional to the number of transactions, the one who makes the transfers is the one who supports the system with
19:24:21 <aksion[m]> priority right. That's really if you're too lazy for someone, then you can delegate the right by paying at an auction to someone who will do it for him. But it is impractical to keep many hundreds of miners who just want to make money and who do not care about the system itself for the sake of fewer transactions, and this is what leads to the energy efficiency of cryptocurrencies
19:25:43 <aksion[m]> fullmetalScience: Yes, but they will not have the right to mine rewards more than the transaction fee. They will be at a loss if they put up their transaction (since the commission will be less than it). It will not be profitable for them to do so
19:25:58 <moneromooo> I will assume from the context complexity == difficulty. Disregard my earlier comments about increased "complexity" then.
19:26:13 <fullmetalScience> The entire functioning of this dimension is possible thanks to people and things working "for profit".
19:26:40 <moneromooo> In order for your system to work, you will have to make your txpool consensus, or it'll be subverted. Do you agree with this ?
19:27:14 <jeffro256[m]> aksion So if I understand correctly, your idea would be for each sender to mine their own transaction?
19:27:45 <aksion[m]> fullmetalScience: Yes, but the profits are different. The profit from "not paying a commission to the bank" (not a loss) is also a profit for someone. I think people will be happy to support the system in order not to pay a commission to banks
19:29:42 <jberman[m]> I think IOTA's tangle is kind of this idea, but among many other problems with IOTA, they have yet to prove it's possible to reach consensus on the network (& prevent double spends/spam) without a central coordinator
19:30:31 <aksion[m]> jeffro256[m]: Well, about yes. So that he can search for the block that his transaction will enter in the pool in proportion to the amount of power allocated to him for this purpose. To make it a priority . And only if you are too lazy or do not want to, then you paid someone else - someone who is ready to do this work of calculations for him, which he will look for at auction (who is cheaper)
19:30:41 <fullmetalScience> <aksion[m]> "I don't really understand the..." <- Miners do care very much about the system thanks to the fees. Turning the idea around you could just zero block rewards and fees. That way you can guarantee that only people interested in transacting actually expand the energy for mining. It would also guarantee this blockchain to be the least secure.
19:33:52 <jeffro256[m]> > So that he can search for the block that his transaction will enter in the pool in proportion to the amount of power allocated to him for this purpose.
19:33:53 <jeffro256[m]> How would this work since the blockchain is immutable?
19:37:49 <aksion[m]> I just want to find a way to limit the number of persons eligible for mining, only to those who are really interested in the functioning of the system, that is, those who keep money and make mutual settlements separately. Then there will be no huge capacities, energy-efficient ones that work and because of which complexity increases, just because they want to earn money, and not to use the system for its intended purpose
19:42:34 <aksion[m]> Finding a block is only necessary to commit transactions in the block. So why a bunch of miners who don't need it, who don't make a transaction. A group of those who need a transaction gathers, exactly as much as is placed in a block, they unite in a pool or p2pool, find a block, fix it in the blockchain and the pool breaks up. All those who are not interested will not participate in this with their capacities, which will reduce the
19:42:35 <aksion[m]> complexity and, accordingly, the energy consumption around the world. This will be an energy-efficient cryptocurrency. Exactly as much power and energy will be spent as is technically necessary to ensure transactions
19:43:42 <moneromooo> In order for your system to work, you will have to make your txpool consensus, or it'll be subverted. Do you agree with this ?
19:50:46 <aksion[m]> Okay, then method 2.
19:50:47 <aksion[m]> To make sure that the mined can be spent only on the commission when paying for the transaction. That is, the reward for mining cannot be spent on anything other than paying the commission of their transactions. Then there would be no those who mine for profit. People would mine only in the amount they need to pay the commission of their transactions.
19:53:06 <aksion[m]> Thus, the number of miners will be limited by the activity of the network and really interested. There will be no need to increase the complexity of the network.
19:55:25 <moneromooo> If you make it so block rewards can not be used other than paying for tx fees, people will not mine, except for those who want to pwn you and don't mind paying for it. Boom, you're screwed.
20:09:01 <fullmetalScience> <aksion[m]> "Finding a block is only necessar..." <- I disagree on Monero not being energy-efficient in the first place. The game theory, simplified, makes it so that a higher value summons more protection (more energy expanded). Lower value asks for less protection.
20:34:02 <jeffro256[m]> Howdy yall I posted a PR: https://github.com/monero-project/monero/pull/8172
20:34:29 <jeffro256[m]> I just removed the unused SMTP code. I really tried to find somewhere that they were referenced, but I couldn't find anhthing
20:34:53 <jeffro256[m]> I figured someone thought there was going to be email integration at some point 
20:45:18 -xmr-pr- jeffro256 opened pull request #8172: Remove unused SMTP code
20:45:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8172
21:02:34 <aksion[m]> <moneromooo> "If you make it so block rewards..." <- But it can be done that the coin cannot be stored, but entered and withdrawn only for transfer. That is, you can buy a coin for fiat only from the one who received the transfer in coin, and you can sell it only to the one who wants to make the transfer. For example, you can make the transfer time no more than a day, otherwise your monero is again sold to another who wants to make the
21:02:35 <aksion[m]> transfer, and you get the fiat back.
21:02:35 <aksion[m]> But you have to provide the transfer by mining and storing the node.