Michael Gronager [ARCHIVE] on Nostr: 📅 Original date posted:2013-03-11 📝 Original message:The point with UTXO is in ...
📅 Original date posted:2013-03-11
📝 Original message:The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared.
If we succeed with that then I don't see a problem in a growing set of UTXO, may that be due to abuse/misuse or just massive use. A properly designed DHT should be able to scale to this.
However, that being said, if you worry about the size of the UTXO set you should change the current coin choosing algorithm to simply get rid of dust.
The current algorithm (ApproximateBestSubset) tend to accumulate dust as dust tend to be on an other scale than a real transactions and hence it is never included.
Regarding the demurrage/escheatment road, I agree that this is for another project. However, if users/developers like this idea, they can just implement a coin choosing algorithm donating dust as miner fee and use it on their satoshi-dice polluted wallet ;)
/M
On 11/03/2013, at 21:08, Rune Kjær Svendsen <runesvend at gmail.com> wrote:
> On Mon, Mar 11, 2013 at 12:01 PM, Jorge Timón <jtimonmv at gmail.com> wrote:
> On 3/10/13, Peter Todd <pete at petertodd.org> wrote:
> > It's also been suggested multiple times to make transaction outputs with
> > a value less than the transaction fee non-standard, either with a fixed
> > constant or by some sort of measurement.
>
> As said on the bitcointalk thread, I think this is the wrong approach.
> This way you effectively disable legitimate use cases for payments
> that "are worth" less than the fees like smart property/colored coins.
> While the transactions pay fees, they should not be considered spam
> regardless of how little the quantities being moved are.
>
> Then your only concern are unspent outputs and comparing fees with
> values doesn't help in any way.
>
>
> Just activate a non-proportional
> demurrage (well, I won't complain if you just turn bitcoin into
> freicoin, just think that non-proportional would be more acceptable by
> most bitcoiners) that incentives old transactions to be moved and
> destroys unspent transactions with small amounts that don't move to
> another address periodically. This has been proposed many times before
> too, and I think it makes a lot more sense.
>
> From an economic point of view this *does* make sense, in my opinion. Storing an unspent transaction in the block chain costs money because we can't prune it. However, it would completely destroy confidence in Bitcoin, as far as I can see. It makes sense economically, but it isn't feasible if we want to maintain people's confidence in Bitcoin.
>
> I like Jeff's proposal of letting an alt-coin implement this. If it gets to the point where Bitcoin can't function without this functionality, it'll be a lot easier to make the transition, instead of now, when it's not really needed, and the trust in Bitcoin really isn't that great.
>
> /Rune
>
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
📝 Original message:The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared.
If we succeed with that then I don't see a problem in a growing set of UTXO, may that be due to abuse/misuse or just massive use. A properly designed DHT should be able to scale to this.
However, that being said, if you worry about the size of the UTXO set you should change the current coin choosing algorithm to simply get rid of dust.
The current algorithm (ApproximateBestSubset) tend to accumulate dust as dust tend to be on an other scale than a real transactions and hence it is never included.
Regarding the demurrage/escheatment road, I agree that this is for another project. However, if users/developers like this idea, they can just implement a coin choosing algorithm donating dust as miner fee and use it on their satoshi-dice polluted wallet ;)
/M
On 11/03/2013, at 21:08, Rune Kjær Svendsen <runesvend at gmail.com> wrote:
> On Mon, Mar 11, 2013 at 12:01 PM, Jorge Timón <jtimonmv at gmail.com> wrote:
> On 3/10/13, Peter Todd <pete at petertodd.org> wrote:
> > It's also been suggested multiple times to make transaction outputs with
> > a value less than the transaction fee non-standard, either with a fixed
> > constant or by some sort of measurement.
>
> As said on the bitcointalk thread, I think this is the wrong approach.
> This way you effectively disable legitimate use cases for payments
> that "are worth" less than the fees like smart property/colored coins.
> While the transactions pay fees, they should not be considered spam
> regardless of how little the quantities being moved are.
>
> Then your only concern are unspent outputs and comparing fees with
> values doesn't help in any way.
>
>
> Just activate a non-proportional
> demurrage (well, I won't complain if you just turn bitcoin into
> freicoin, just think that non-proportional would be more acceptable by
> most bitcoiners) that incentives old transactions to be moved and
> destroys unspent transactions with small amounts that don't move to
> another address periodically. This has been proposed many times before
> too, and I think it makes a lot more sense.
>
> From an economic point of view this *does* make sense, in my opinion. Storing an unspent transaction in the block chain costs money because we can't prune it. However, it would completely destroy confidence in Bitcoin, as far as I can see. It makes sense economically, but it isn't feasible if we want to maintain people's confidence in Bitcoin.
>
> I like Jeff's proposal of letting an alt-coin implement this. If it gets to the point where Bitcoin can't function without this functionality, it'll be a lot easier to make the transition, instead of now, when it's not really needed, and the trust in Bitcoin really isn't that great.
>
> /Rune
>
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development