Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Monday 03 December 2012 11:19:37 Michael Gronager wrote: The aged coins are simply included in the block mining reward, creating another incentive for miners. Further, if we include all coins in this recycle scheme coins will never be lost forever. Ignoring the cost of storing these never-spent outputs; there is absolutely no reason we need to ensure that coins aren't lost. Nor worry about those that are. The total bitcoins produced is an entirely arbitrary number -- a function of the 210,000 halving rate and the initial block reward. Satoshi could have picked anything for them and bitcoin would work exactly the same. Lost coins never enter the economy ever again, and so supply is slightly lower than it would have been, making all the non-lost coins worth ever so slightly more. Effectively: price adjustments will take care of lost coins. Andy -- Dr Andy Parkins andypark...@gmail.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
(Also posted on the forum: https://bitcointalk.org/index.php?topic=128900.0) The amount of dust in the block chain is getting large and it is growing all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi (0.0001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC. (Thanks to Jan for digging out these numbers!) This means that a huge part of the block chain is used for essentially nothing - e.g. the sum of the 11% is worth roughly 2 US cents ! The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing wrong with that, however, we should work on ensuring that too many too small payments will not kill the size of the blockchain in the end - further, they are essentially too small to be included in other transaction as the added fee will often make it more expensive to remove them. Hence, there is no incentive to get rid of them. I have an idea for a possible mitigation of this problem - introduction of demurrage - not as in it normal meaning as a percentage over time (see:http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been tried in freicoin), but as a mean to recycle pennies over time. The proposal is simple - UTXOs age out if not re-transacted - the smaller the coin the faster the aging: 1-99 Satoshi: lives for 210 blocks 100- Satoshi: lives for 2100 blocks 1-99 Satoshi: lives for 21000 blocks 100- Satoshi: lives for 21 blocks Only amounts above 1BTC lives forever - (or we could even impose aging on those too..) The aged coins are simply included in the block mining reward, creating another incentive for miners. Further, if we include all coins in this recycle scheme coins will never be lost forever. This scheme will impose some lifetimes also on e.g. colored coins (hence you need to use a certain amount to borrow space on the blockchain for the time needed, or simply transact them). If you like this I would be happy to write it into a BIP. Thoughts ? -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager grona...@ceptacle.comwrote: (Also posted on the forum: https://bitcointalk.org/index.php?topic=128900.0) The amount of dust in the block chain is getting large and it is growing all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi (0.0001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC. (Thanks to Jan for digging out these numbers!) I've noticed this too, and it is a concern indeed. I have an idea for a possible mitigation of this problem - introduction of demurrage - not as in it normal meaning as a percentage over time (see: http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been tried in freicoin), but as a mean to recycle pennies over time. The proposal is simple - UTXOs age out if not re-transacted - the smaller the coin the faster the aging: 1-99 Satoshi: lives for 210 blocks 100- Satoshi: lives for 2100 blocks 1-99 Satoshi: lives for 21000 blocks 100- Satoshi: lives for 21 blocks If this were a proposal at the time Bitcoin was created, I would definitely be in favor, but I feel we can't just change such a policy right now - it's not what people signed up for when they started using the system. I also see no way to implement this without a hard fork, which would require planning at least 1-2 years in advance (imho). By that time, the economic landscape of Bitcoin may be vastly different, and either dust spam will have killed it, or we will have found another solution already. Personally, I think the best solution is to change the mining policy to prioritize (and perhaps favor for free relay/inclusion) transactions that reduce the number of UTXO's. -- Pieter -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 1:24 PM, Michael Gronager grona...@ceptacle.comwrote: If this were a proposal at the time Bitcoin was created, I would definitely be in favor, but I feel we can't just change such a policy right now - it's not what people signed up for when they started using the system. I also see no way to implement this without a hard fork, which would require planning at least 1-2 years in advance (imho). By that time, the economic landscape of Bitcoin may be vastly different, and either dust spam will have killed it, or we will have found another solution already. Bitcoin aka the blockchain is defined by the majority of the miners. This is what people have signed up to imo. A scheme that a) is of benefit for us all and b) is also of economical benefit for the miners, will likely be accepted quite fast - especially now when the bounty was just halved... I also fear that there is a lot of BTCs that is effectively un-owned and it could even drive Satoshi to use some of his BTCs ;) I disagree completely. The only power granted to miners is to decide the order of otherwise valid transactions (up to postponing some indefinitely) - they have no ability to control the rules for validity them self In particular, the rules that prevent double spending and (monetary) inflation of the currency are deliberately NOT left to miners. If this were the case, they could just as well vote to keep the 50 BTC block payout, and that would certainly not be what people signed up for. -- Pieter -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
1) Wouldn't the need to re-transact your coins to keep them safe from vultures, result in people frantically sending coins to themselves, and thus expand the block chain, instead of reduce growth? Not at the rate suggested 2) putting those hard limits in passes a value judgement that IMO should not be present in the protocol. 1BTC may be worth a lot some day, or it could go the other way around, with dust spam of 10+ BTC. Either way the limits will have to be changed again, with yet another fork. Well, retransmitting 1BTC ones every 4 years isn't that bad. So I don't see a need for another fork for this reason. 3) The (normal) user does not have a view of his balance consisting of inputs and outputs of various sizes. He just sees his balance as one number. And somehow, inexplicably (except through a very difficult explanation), it's going down... what if he has 1 BTC in 0.999 BTC units? And it's gone after 21 blocks. Agree to this - and also to the fact that it will be hard to introduce - it would be changing the protocol quite a lot (perhaps too much). A better set of relay fee rules rewarding a decrease in # UTXOs is probably the (easiest) way forward. /M -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
The main source for these 1 Satoshi payouts is Sahtoshi Dice. Because people are making 1 satoshi bets, or is this part of their messaging system? Pieter is right, getting consensus behind your proposal is too hard and it's not likely to ever happen (I wouldn't support it, for one). Outputs that never get spent are simply using disk space, the working set is really defined by the coins that are moving. Disk space is cheap. So this problem doesn't feel that urgent to me. Now if people were routinely spending those 1 satoshi outputs, it'd be less great as it'd increase the working set size. I suspect some of these coins can be cleared over time by adjusting wallets to consolidate outputs into the change outputs when a transaction that has spare space before reaching the next size/fee level takes place. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager grona...@ceptacle.com wrote: Bitcoin aka the blockchain is defined by the majority of the miners. This is what people have signed up to imo. A scheme that a) is of benefit for us all and b) is also of economical benefit for the miners, will likely be accepted quite fast - especially now when the bounty was just halved... I also fear that there is a lot of BTCs that is effectively un-owned and it could even drive Satoshi to use some of his BTCs ;) Pieter already commented on this, but it's so important it must be said twice because everyone developing software for Bitcoin must understand and internalize it: Bitcoin is not a democracy, it's certainly not a democracy of miners. Every full node independently and autonomously validates the rules of the system without the influence of other participants. Unfortunately, there is no universally consistent way to evaluate the temporal ordering of transactions independently known— and none likely to ever exist— and a digital currency requires ordering to resolve double spends. Because of this Bitcoin must compromise the autonomy of its validation slightly: It uses a computational majority to determine transaction ordering. But only ordering! This is essential because if all the rules were subject to the whim of a computing majority the system would be far less trustworthy. The economic incentives which keep the mining participants honest depend on the value of defection being as limited as possible. So, no— you can't achieve by what you want with miners. Any miner which applied your rules would instantly stop mining from the perspective of Bitcoin users. As a miner myself, I welcome my competition adopting your proposal :P. You're looking for a hard fork of the system. Such a change must be supported by ~all users, and so it must be something which has near universal consensus that it is essential. I think it's not essential— though I agree that better UTXO set size management would have been a useful component if it had been in the origin economic promise of the system— and I already know that some participants take a principled position that views changes to the mere spendability of outputs as _theft_. Your proposal is also more economically hazardous than necessary: By paying unmoved coins to miners you create a substantial incentive for miners to delay processing transactions in the hopes that they expire first. There is also some risk that the return of large coins from the past after the currency has substantially deflated would be extremely economically disruptive. As far as your concern— as opposed to the mechanism— I share it. But it's important to note that the source of most of the problem transactions is a single source, and a rather unusual one that defies the normal anti-spamming economic incentives by attracting mentally ill people to subsidize pay for the bloating transactions, which are already penalized. I believe this specific issue can be adequately addressed primarily through a three fold process: (1) Make client software aggressive about sweeping up dust inputs: Any time a transaction is created that has change keep adding in extra inputs— smallest to largest— until an additional one would increase the cost of the transaction by 0.0001 BTC or more — the only major complication is doing this without concurrently harming privacy which is why it's not done yet in the reference client. (2) Change the default relay and mining rules to further penalize transactions with very small outputs. Making sure that its practically possible to create inexpensive transactions right now is very important for the long term success of the system while the small size of the system makes it unattractive to use, but I don't believe that applies for dust outputs. (3) Change the default relay and mining rules to further incentive reductions in the UTXO set size. This would make the actions of (1) save the participants funds instead of just being an altruistic behavior that most do because its a default. It might also be useful for client software to incorporate a destroy wallet button for people with wallets that only have dust remaining to send the private keys off to something of community benefit (e.g. bitcoin foundation, the faucet, or the developers of that that client) for recovery so that they don't perpetually bloat the UTXO set. I expect that these actions would substantially address your concerns, and even if they do not I believe that they would be the most basic prerequisites for any kind of argument that something more drastic (especially something that some would could consider theft!) is essential. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn m...@plan99.net wrote: The main source for these 1 Satoshi payouts is Sahtoshi Dice. Because people are making 1 satoshi bets, or is this part of their messaging system? It's part of their messaging system. Every losing play results in a new 1e-8 output being created. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
It's part of their messaging system. Every losing play results in a new 1e-8 output being created. Every losing play? That's ... not excellent. Well, this why the payment protocol spec has a way for merchants to reply to customers with text instead of outputs. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On 12/03/2012 10:02 AM, Gregory Maxwell wrote: (1) Make client software aggressive about sweeping up dust inputs: Any time a transaction is created that has change keep adding in extra inputs— smallest to largest— until an additional one would increase the cost of the transaction by 0.0001 BTC or more — the only major complication is doing this without concurrently harming privacy which is why it's not done yet in the reference client. FYI, Armory uses exactly this logic to try to clean up dust outputs in the user's transactions. However, there's enough conditions on it, that I don't know how often it triggers. Recommendations are welcome for how to improve it. Right now, if the transaction has less than 5 inputs, there exists dust UTXOs from addresses already included in the transaction, and those UTXOs are sufficiently small in priority, then the Armory will add them to the input side and increase the change accordingly. Looking it just made me realize I lost the last condition of making sure the tx already has a change output -- don't want to turn a free tx into a fee-needed tx just to do this. (reorganized the code https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279 recently, and must have fell through the cracks). Perhaps it could be improved by cleaning up dust from *any* address by default (not just ones already included in the tx), with the option for the user to disable that behavior. After all, anonymity was never a core feature of the network -- I think it makes sense that the logic would reduce anonymity by default in exchange for a cleaner network, with a clear option to opt-out of that logic if user cares. I think most users don't actually care... -Alan -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
Perhaps it could be improved by cleaning up dust from any address by default (not just ones already included in the tx), with the option for the user to disable that behavior. After all, anonymity was never a core feature of the network It's cool that Armory already does this. I never had time to implement good coin selection for bitcoinj :( Just a couple of points: as this is primarily a side effect of SatoshiDice, and a successful payment protocol will stop them doing it, code put in place to do temporary cleanup now probably won't seriously affect peoples privacy over the long term. Most people aren't going to end up with lots of tiny outputs. Second thing, it's best to carefully separate anonymity from privacy. Privacy is supposed to be a feature of the system (it says so in Satoshis paper) because people demand it. If I loan a tenner to my friend and he is able to find out what I earned last month, then that trade was neither anonymous nor private. In this case I want privacy but anonymity isn't useful. Mixing up anonymity with privacy is not only a public relations problem, but can lead to confusion from users when they, eg, try and buy Bitcoins from an exchange and are asked to provide ID proofs. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn m...@plan99.net wrote: Second thing, it's best to carefully separate anonymity from privacy. Privacy is supposed to be a feature of the system (it says so in Satoshis paper) because people demand it. If I loan a tenner to my friend and he is able to find out what I earned last month, then that trade was neither anonymous nor private. In this case I want privacy but anonymity isn't useful. Mixing up anonymity with privacy is not only a public relations problem, but can lead to confusion from users when they, eg, try and buy Bitcoins from an exchange and are asked to provide ID proofs. I would like to second this point...privacy is essential because the market demands it. If Bitcoin doesn't do it well (and I would argue that it doesn't today), then eventually a competitor to Bitcoin will do it better and that would be the beginning of the end for Bitcoin. Debates about whether it was or wasn't a core feature are pointless. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
These are all valid points. I hadn't really thought much about this point until you all just brought it up. The reason I so quickly spout off that phrase, is that I endlessly get requests from Armory users to implement more anonymity-based features. When I say there are bigger priorities, they suggest that anonymity is a core benefit of Bitcoin and I should be supporting it. I'm not against anonymity, and I most certainly favor privacy, but my goal was to produce a versatile client, not one focused on any one aspect -- there are plenty of people who use it for other reasons than anonymity. However, I do like Greg's comment about attacks against a blind-dust-inclusion algorithm, and suggestion to maintain a clustering of already-linked addresses. That's not terribly difficult to do with the transaction history in hand, and it could increase how often the logic triggers. I suppose these hardcore SD players probably have a lot of one-satoshi outputs that could use vacuuming... On Mon, Dec 3, 2012 at 11:18 AM, Stephen Pair step...@bitpay.com wrote: On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn m...@plan99.net wrote: Second thing, it's best to carefully separate anonymity from privacy. Privacy is supposed to be a feature of the system (it says so in Satoshis paper) because people demand it. If I loan a tenner to my friend and he is able to find out what I earned last month, then that trade was neither anonymous nor private. In this case I want privacy but anonymity isn't useful. Mixing up anonymity with privacy is not only a public relations problem, but can lead to confusion from users when they, eg, try and buy Bitcoins from an exchange and are asked to provide ID proofs. I would like to second this point...privacy is essential because the market demands it. If Bitcoin doesn't do it well (and I would argue that it doesn't today), then eventually a competitor to Bitcoin will do it better and that would be the beginning of the end for Bitcoin. Debates about whether it was or wasn't a core feature are pointless. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
My only comment is that it should be called escheatment, not demurrage ;) It's relation to demurrage is only that it might be desirable to garbage collect decayed bit-dust. We looked at it early-on in the Freicoin development, but rejected it as a possibility due to reasons others have mentioned, even though we were starting from a hard-fork position. On Mon, Dec 3, 2012 at 3:19 AM, Michael Gronager grona...@ceptacle.comwrote: (Also posted on the forum: https://bitcointalk.org/index.php?topic=128900.0) The amount of dust in the block chain is getting large and it is growing all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi (0.0001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC. (Thanks to Jan for digging out these numbers!) This means that a huge part of the block chain is used for essentially nothing - e.g. the sum of the 11% is worth roughly 2 US cents ! The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing wrong with that, however, we should work on ensuring that too many too small payments will not kill the size of the blockchain in the end - further, they are essentially too small to be included in other transaction as the added fee will often make it more expensive to remove them. Hence, there is no incentive to get rid of them. I have an idea for a possible mitigation of this problem - introduction of demurrage - not as in it normal meaning as a percentage over time (see: http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been tried in freicoin), but as a mean to recycle pennies over time. The proposal is simple - UTXOs age out if not re-transacted - the smaller the coin the faster the aging: 1-99 Satoshi: lives for 210 blocks 100- Satoshi: lives for 2100 blocks 1-99 Satoshi: lives for 21000 blocks 100- Satoshi: lives for 21 blocks Only amounts above 1BTC lives forever - (or we could even impose aging on those too..) The aged coins are simply included in the block mining reward, creating another incentive for miners. Further, if we include all coins in this recycle scheme coins will never be lost forever. This scheme will impose some lifetimes also on e.g. colored coins (hence you need to use a certain amount to borrow space on the blockchain for the time needed, or simply transact them). If you like this I would be happy to write it into a BIP. Thoughts ? -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
These discussed features are all useful but quite contradicting. I imagine that a user will be able to switch between different coin selection policies minimize fees,max privacy,defragmentation,i don't care and even switch between them for individual sends. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson andr...@petersson.at wrote: These discussed features are all useful but quite contradicting. I imagine that a user will be able to switch between different coin selection policies minimize fees,max privacy,defragmentation,i don't care and even switch between them for individual sends. While thats a fine thing— and a feature that I'd personally use— its not one that I expect to have a real measurable impact on the overall network behavior. For this kind of minutia especially, defaults are all powerful and must be the best they can be. :) -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
