📅 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
Michael Gronager [ARCHIVE] /
npub1nc…gw452
2023-06-07 11:35:46
in reply to nevent1q…l4xk
Author Public Key
npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452Published at
2023-06-07 11:35:46Event JSON
{
"id": "9cf05190e6b12b97abbf37a808264b8f35ee8f18f4be3e1eea6b482776143951",
"pubkey": "9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02",
"created_at": 1686137746,
"kind": 1,
"tags": [
[
"e",
"ac08c1a6c33933128b534f22efee5bb15c3746d60deefafe520b9c4fff7b646d",
"",
"root"
],
[
"e",
"756571520086f4f32796c25e072fb065724cb28be30a721bf615dcd33e2c8373",
"",
"reply"
],
[
"p",
"8438bef57d05ffe31835fbb52e2f974f014354f84bcd030510336c6b24a3f95c"
]
],
"content": "📅 Original date posted:2013-03-11\n📝 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. \n\nIf 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.\n\nHowever, 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. \n\nThe 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.\n\nRegarding 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 ;)\n\n/M\n \nOn 11/03/2013, at 21:08, Rune Kjær Svendsen \u003crunesvend at gmail.com\u003e wrote:\n\n\u003e On Mon, Mar 11, 2013 at 12:01 PM, Jorge Timón \u003cjtimonmv at gmail.com\u003e wrote:\n\u003e On 3/10/13, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \u003e It's also been suggested multiple times to make transaction outputs with\n\u003e \u003e a value less than the transaction fee non-standard, either with a fixed\n\u003e \u003e constant or by some sort of measurement.\n\u003e \n\u003e As said on the bitcointalk thread, I think this is the wrong approach.\n\u003e This way you effectively disable legitimate use cases for payments\n\u003e that \"are worth\" less than the fees like smart property/colored coins.\n\u003e While the transactions pay fees, they should not be considered spam\n\u003e regardless of how little the quantities being moved are.\n\u003e \n\u003e Then your only concern are unspent outputs and comparing fees with\n\u003e values doesn't help in any way.\n\u003e \n\u003e \n\u003e Just activate a non-proportional\n\u003e demurrage (well, I won't complain if you just turn bitcoin into\n\u003e freicoin, just think that non-proportional would be more acceptable by\n\u003e most bitcoiners) that incentives old transactions to be moved and\n\u003e destroys unspent transactions with small amounts that don't move to\n\u003e another address periodically. This has been proposed many times before\n\u003e too, and I think it makes a lot more sense.\n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e /Rune\n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester\n\u003e Wave(TM): Endpoint Security, Q1 2013 and \"remains a good choice\" in the\n\u003e endpoint security space. For insight on selecting the right partner to\n\u003e tackle endpoint security challenges, access the full report.\n\u003e http://p.sf.net/sfu/symantec-dev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester \n\u003e Wave(TM): Endpoint Security, Q1 2013 and \"remains a good choice\" in the \n\u003e endpoint security space. For insight on selecting the right partner to \n\u003e tackle endpoint security challenges, access the full report. \n\u003e http://p.sf.net/sfu/symantec-dev2dev_______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "705b403d6ea5e1e901552e7c2eef03449247cbed8385f58ff5856b77c90ee42713ae98b055ec46a16904f885e326292d67249210abc8b099e3a1da1b2a2b4480"
}