* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 11:19 [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming Michael Gronager
@ 2012-12-03 12:05 ` Pieter Wuille
2012-12-03 12:24 ` Michael Gronager
2012-12-03 12:40 ` Wladimir
` (3 subsequent siblings)
4 siblings, 1 reply; 19+ messages in thread
From: Pieter Wuille @ 2012-12-03 12:05 UTC (permalink / raw)
To: Michael Gronager; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager <gronager@ceptacle•com>wrote:
> (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.00000001BTC), 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-9999 Satoshi: lives for 2100 blocks
> 10000-999999 Satoshi: lives for 21000 blocks
> 1000000-99999999 Satoshi: lives for 210000 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
[-- Attachment #2: Type: text/html, Size: 2484 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 12:05 ` Pieter Wuille
@ 2012-12-03 12:24 ` Michael Gronager
2012-12-03 12:33 ` Pieter Wuille
2012-12-03 15:02 ` Gregory Maxwell
0 siblings, 2 replies; 19+ messages in thread
From: Michael Gronager @ 2012-12-03 12:24 UTC (permalink / raw)
To: Bitcoin Dev
> 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 ;)
> 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.
Agree - initially (and possibly in parallel) this would be a nice path to follow - it could be done solely by adjusting the relay fee: Transactions that increases the # UTXOs pay extra, those that reduce it pay less (symmetrical around a minimum fee). So in other words we 'tax' increasing the size of the UTXOs.
No matter how it is done - as long as a client is not punished for getting rid of dust, and clients are rewritten to do this automatically we could re-evaluate after a some time - but currently the number of UTXOs is growing rapidly.
/M
>
> --
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 12:24 ` Michael Gronager
@ 2012-12-03 12:33 ` Pieter Wuille
2012-12-03 15:02 ` Gregory Maxwell
1 sibling, 0 replies; 19+ messages in thread
From: Pieter Wuille @ 2012-12-03 12:33 UTC (permalink / raw)
To: Michael Gronager; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
On Mon, Dec 3, 2012 at 1:24 PM, Michael Gronager <gronager@ceptacle•com>wrote:
> > 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
[-- Attachment #2: Type: text/html, Size: 1908 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 12:24 ` Michael Gronager
2012-12-03 12:33 ` Pieter Wuille
@ 2012-12-03 15:02 ` Gregory Maxwell
2012-12-03 15:17 ` Alan Reiner
1 sibling, 1 reply; 19+ messages in thread
From: Gregory Maxwell @ 2012-12-03 15:02 UTC (permalink / raw)
To: Michael Gronager; +Cc: Bitcoin Dev
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager <gronager@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 15:02 ` Gregory Maxwell
@ 2012-12-03 15:17 ` Alan Reiner
2012-12-03 15:30 ` Mike Hearn
2012-12-03 15:51 ` Gregory Maxwell
0 siblings, 2 replies; 19+ messages in thread
From: Alan Reiner @ 2012-12-03 15:17 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2294 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 15:17 ` Alan Reiner
@ 2012-12-03 15:30 ` Mike Hearn
2012-12-03 16:18 ` Stephen Pair
2012-12-03 15:51 ` Gregory Maxwell
1 sibling, 1 reply; 19+ messages in thread
From: Mike Hearn @ 2012-12-03 15:30 UTC (permalink / raw)
To: Alan Reiner; +Cc: Bitcoin Dev
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 15:30 ` Mike Hearn
@ 2012-12-03 16:18 ` Stephen Pair
2012-12-03 16:29 ` Alan Reiner
0 siblings, 1 reply; 19+ messages in thread
From: Stephen Pair @ 2012-12-03 16:18 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn <mike@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.
[-- Attachment #2: Type: text/html, Size: 1387 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 16:18 ` Stephen Pair
@ 2012-12-03 16:29 ` Alan Reiner
2012-12-03 19:50 ` Andreas Petersson
0 siblings, 1 reply; 19+ messages in thread
From: Alan Reiner @ 2012-12-03 16:29 UTC (permalink / raw)
To: Stephen Pair; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
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 <stephen@bitpay•com> wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn <mike@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.
>
[-- Attachment #2: Type: text/html, Size: 2852 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 16:29 ` Alan Reiner
@ 2012-12-03 19:50 ` Andreas Petersson
2012-12-03 20:14 ` Gregory Maxwell
0 siblings, 1 reply; 19+ messages in thread
From: Andreas Petersson @ 2012-12-03 19:50 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 19:50 ` Andreas Petersson
@ 2012-12-03 20:14 ` Gregory Maxwell
0 siblings, 0 replies; 19+ messages in thread
From: Gregory Maxwell @ 2012-12-03 20:14 UTC (permalink / raw)
To: Andreas Petersson; +Cc: bitcoin-development
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson <andreas@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. :)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 15:17 ` Alan Reiner
2012-12-03 15:30 ` Mike Hearn
@ 2012-12-03 15:51 ` Gregory Maxwell
1 sibling, 0 replies; 19+ messages in thread
From: Gregory Maxwell @ 2012-12-03 15:51 UTC (permalink / raw)
To: Alan Reiner; +Cc: bitcoin-development
On Mon, Dec 3, 2012 at 10:17 AM, Alan Reiner <etotheipi@gmail•com> wrote:
> 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...
Yea, the obvious case would look for exact matches— but because sane
software pays change to fresh addresses I expect this to trigger an
unfortunately infrequent amount of time.
Why do you bother with the 5 input limit? The way I'd handle this in
the reference client is as a pure post-processing step. E.g. take any
w/ change transaction formed and try adding small inputs in a greedy
fashion until the next would change the fees. Do you see a reason not
to do this?
A next step up in infrequency is to use input taint tracking
information to gather up coins from all inputs which are already
crosslinked. In the reference client, which doesn't avoid
crosslinking, this would likely be quite effective but I worry about
having an O(N^2)-ish algorithm as part of coin selection. And so I
think it would require maintaining in the wallet the cross link
history for each address rather than building it on the fly. This
seems like a lot of changes for a relatively modest optimization.
Another possibility would be to not apply the privacy rule to very
small inputs or to addresses which have only ever received a very
small sum total. But I don't know how to define very small in a robust
way, and I think that the privacy behavior of the software being
"inconsistent" from the users perspective would be somewhat
unfortunate. Perhaps a setting for the value considered very small
for this purpose which defaults to the relay MINFEE? (And also
include larger outputs when they're address matches).
The the problem with this is this: Say I have an address 1GMaxwellFOO
that everyone knows belongs to me. Someone who wants to identify all
my transactions sends me a constant spray of 1e-8 inputs to
1GMaxwellFOO. If the address association is ignored (even for only
very small inputs) then all my transactions become rapidly
identifiable. Privacy, of at least a basic form, is an important
element of the system, if it's not preserved than bitcoin is inferior
to traditional value transfer systems in an additional way.
(And FWIW, I've seen self-appointed sluths on IRC trying to catch
trouble makers by paying tiny amounts to their extortion addresses;
with the incorrect expectation that it would taint their other
transactions. So even when it doesn't usually work people have tried
using this to attack people)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 11:19 [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming Michael Gronager
2012-12-03 12:05 ` Pieter Wuille
@ 2012-12-03 12:40 ` Wladimir
2012-12-03 13:04 ` Michael Gronager
2012-12-03 15:00 ` Mike Hearn
` (2 subsequent siblings)
4 siblings, 1 reply; 19+ messages in thread
From: Wladimir @ 2012-12-03 12:40 UTC (permalink / raw)
To: Michael Gronager; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]
I do think it would be nice to sweep up dust transactions, however I'm not
that happy with your solution
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?
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.
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 10000 BTC in 0.9999999 BTC
units? Annnnnd it's gone after 210000 blocks.
I wonder if there is a way for the whole process to be transparent to the
user. The wallet is 'defragmented' but without losing the swept up coins to
the miner.
Wladimir
On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager <gronager@ceptacle•com>wrote:
> (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.00000001BTC), 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-9999 Satoshi: lives for 2100 blocks
> 10000-999999 Satoshi: lives for 21000 blocks
> 1000000-99999999 Satoshi: lives for 210000 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
>
[-- Attachment #2: Type: text/html, Size: 4613 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 12:40 ` Wladimir
@ 2012-12-03 13:04 ` Michael Gronager
0 siblings, 0 replies; 19+ messages in thread
From: Michael Gronager @ 2012-12-03 13:04 UTC (permalink / raw)
To: Bitcoin Dev
> 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 10000 BTC in 0.9999999 BTC units? Annnnnd it's gone after 210000 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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 11:19 [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming Michael Gronager
2012-12-03 12:05 ` Pieter Wuille
2012-12-03 12:40 ` Wladimir
@ 2012-12-03 15:00 ` Mike Hearn
2012-12-03 15:07 ` Gregory Maxwell
2012-12-03 17:02 ` Mark Friedenbach
2012-12-04 9:54 ` Andy Parkins
4 siblings, 1 reply; 19+ messages in thread
From: Mike Hearn @ 2012-12-03 15:00 UTC (permalink / raw)
To: Michael Gronager; +Cc: Bitcoin Dev
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 15:00 ` Mike Hearn
@ 2012-12-03 15:07 ` Gregory Maxwell
2012-12-03 15:09 ` Mike Hearn
0 siblings, 1 reply; 19+ messages in thread
From: Gregory Maxwell @ 2012-12-03 15:07 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev, Michael Gronager
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn <mike@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 15:07 ` Gregory Maxwell
@ 2012-12-03 15:09 ` Mike Hearn
0 siblings, 0 replies; 19+ messages in thread
From: Mike Hearn @ 2012-12-03 15:09 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev, Michael Gronager
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 11:19 [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming Michael Gronager
` (2 preceding siblings ...)
2012-12-03 15:00 ` Mike Hearn
@ 2012-12-03 17:02 ` Mark Friedenbach
2012-12-04 9:54 ` Andy Parkins
4 siblings, 0 replies; 19+ messages in thread
From: Mark Friedenbach @ 2012-12-03 17:02 UTC (permalink / raw)
To: Michael Gronager; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]
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 <gronager@ceptacle•com>wrote:
> (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.00000001BTC), 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-9999 Satoshi: lives for 2100 blocks
> 10000-999999 Satoshi: lives for 21000 blocks
> 1000000-99999999 Satoshi: lives for 210000 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
>
[-- Attachment #2: Type: text/html, Size: 3698 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
2012-12-03 11:19 [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming Michael Gronager
` (3 preceding siblings ...)
2012-12-03 17:02 ` Mark Friedenbach
@ 2012-12-04 9:54 ` Andy Parkins
4 siblings, 0 replies; 19+ messages in thread
From: Andy Parkins @ 2012-12-04 9:54 UTC (permalink / raw)
To: bitcoin-development; +Cc: Michael Gronager
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
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 19+ messages in thread