📅 Original date posted:2015-05-09
📝 Original message:I think potential fee subsidies for cleaning up UTXO (and/or penalties
for creating more UTXO than you burn) are worth thinking about. As
Gavin's post ( gavinandresen.ninja/utxo-uhoh ) indicates, UTXO cost is
far higher than block storage, so charging differently for the in/out
mismatches should make good economic sense.
Ross
On 09/05/2015 20:16, Jim Phillips wrote:
> On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
> It's a very complex trade-off, which is hard to optimize for all
> use cases. Using more UTXOs requires larger transactions, and thus
> more fees in general.
>
> Unless the miner determines that the reduction in UTXO storage
> requirements is worth the lower fee. There's no protocol level
> enforcement of a fee as far as I understand it. It's enforced by the
> miners and their willingness to include a transaction in a block.
>
> In addition, it results in more linkage between coins/addresses
> used, so lower privacy.
>
> Not if you only select all the UTXOs from a single address. A wallet
> that is geared more towards privacy minded individuals may want to
> reduce the amount of address linkage, but a wallet geared towards the
> general masses probably won't have to worry so much about that.
>
> The only way you can guarantee an economical reason to keep the
> UTXO set small is by actually having a consensus rule that
> punishes increasing its size.
>
> There's an economical reason right now to keeping the UTXO set small.
> The smaller it is, the easier it is for the individual to run a full
> node. The easier it is to run a full node, the faster Bitcoin will
> spread to the masses. The faster it spreads to the masses, the more
> valuable it becomes.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/bbd40c7a/attachment.html>;
Ross Nicoll [ARCHIVE] /
npub10p…pfaef
2023-06-07 15:34:23
in reply to nevent1q…47fp
Author Public Key
npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefPublished at
2023-06-07 15:34:23Event JSON
{
"id": "f074f3acd4c4089d78379ddd5193b034e872800deff96b4254351364538549d3",
"pubkey": "787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129",
"created_at": 1686152063,
"kind": 1,
"tags": [
[
"e",
"e436370a47825fa52c60553290bd211115ae129df3a23920b2899f508d96bf5e",
"",
"root"
],
[
"e",
"df32bcb35dd371a46bea27da7caf9c91c0e9cb0a36970b917d9f4dab6327dff6",
"",
"reply"
],
[
"p",
"8b64be8dfcb19730f674fdb0169f772317a629f8dd3b8d925d342a0273bbb37b"
]
],
"content": "📅 Original date posted:2015-05-09\n📝 Original message:I think potential fee subsidies for cleaning up UTXO (and/or penalties \nfor creating more UTXO than you burn) are worth thinking about. As \nGavin's post ( gavinandresen.ninja/utxo-uhoh ) indicates, UTXO cost is \nfar higher than block storage, so charging differently for the in/out \nmismatches should make good economic sense.\n\nRoss\n\n\nOn 09/05/2015 20:16, Jim Phillips wrote:\n\u003e On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille \u003cpieter.wuille at gmail.com \n\u003e \u003cmailto:pieter.wuille at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e It's a very complex trade-off, which is hard to optimize for all\n\u003e use cases. Using more UTXOs requires larger transactions, and thus\n\u003e more fees in general.\n\u003e\n\u003e Unless the miner determines that the reduction in UTXO storage \n\u003e requirements is worth the lower fee. There's no protocol level \n\u003e enforcement of a fee as far as I understand it. It's enforced by the \n\u003e miners and their willingness to include a transaction in a block.\n\u003e\n\u003e In addition, it results in more linkage between coins/addresses\n\u003e used, so lower privacy.\n\u003e\n\u003e Not if you only select all the UTXOs from a single address. A wallet \n\u003e that is geared more towards privacy minded individuals may want to \n\u003e reduce the amount of address linkage, but a wallet geared towards the \n\u003e general masses probably won't have to worry so much about that.\n\u003e\n\u003e The only way you can guarantee an economical reason to keep the\n\u003e UTXO set small is by actually having a consensus rule that\n\u003e punishes increasing its size.\n\u003e\n\u003e There's an economical reason right now to keeping the UTXO set small. \n\u003e The smaller it is, the easier it is for the individual to run a full \n\u003e node. The easier it is to run a full node, the faster Bitcoin will \n\u003e spread to the masses. The faster it spreads to the masses, the more \n\u003e valuable it becomes.\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e\n\u003e\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/bbd40c7a/attachment.html\u003e",
"sig": "bb9db1e8551248c1ed4faf176ee1da8477d240a445a7a5ca2824a3bafe3163eade6b8d9ecb28434b971240782ad1192df4d3436d77d4142492c188c52f09cd7e"
}