From: Moral Agent <ethan.scruples@gmail.com>
To: Lucas Clemente Vella <lvella@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Cc: Major Kusanagi <majorkusanagibtc@gmail.com>
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Date: Fri, 21 Jul 2017 16:17:39 -0400 [thread overview]
Message-ID: <CACiOHGxYGdaPTAt07HFFGPEDhRC4PM3FZKk8Cwc0RgDN74qQrw@mail.gmail.com> (raw)
In-Reply-To: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]
If we have a problem with a UTXO set that is too large, seems like maybe
the fair way to approach it is to enforce a limit on the growth of the UTXO
set.
Miners would eventually be forced to generate blocks that are UTXO neutral
and would factor that into their algorithm for prioritizing transactions.
Users who wish to generate a lot of outputs would need to find a buddy with
lots of inputs to consolidate and create a tumble-bit with them. A market
would spring up that would charge people for creating UTXOs and pay them
for disposing of UTXOs.
On Fri, Jul 21, 2017 at 3:59 PM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>> [...] But the fact is that if we want to make bitcoins last forever, we
>> have the accept unbounded UTXO growth, which is unscalable. So the only
>> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
>> This proposed solution however does not prevent Bitcoin from lasting
>> forever.
>>
>
> Unless there is a logical contradiction in this phrasing, the proposed
> solution does not improves scalability:
> - "Bitcoins lasting forever" implies "unscalable";
> - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> forever";
> - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
>
> In practice, the only Bitcoin lost would be those whose owners forgot
> about or has lost the keys, because everyone with a significant amount of
> Bitcoins would always shift them around before it loses any luster (I
> wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> estimate the percentage of UTXO is actually lost/forgotten, but I have the
> opinion it isn't worth the hassle.
>
> As a side note, your estimate talks about block size, which is determines
> blockchain size, which can be "safely" pruned (if you are not considering
> new nodes might want to join the network, in case the full history is
> needed to be stored somewhere). But UTXO size, albeit related to the full
> blockchain size, is the part that currently can not be safely pruned, so I
> don't see the relevance of the analysis.
>
> --
> Lucas Clemente Vella
> lvella@gmail.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3896 bytes --]
next prev parent reply other threads:[~2017-07-21 20:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 19:28 [bitcoin-dev] UTXO growth scaling solution proposal Major Kusanagi
2017-07-21 19:52 ` Jeremy
2017-07-21 19:54 ` Jameson Lopp
2017-07-22 6:43 ` Major Kusanagi
2017-07-21 19:59 ` Lucas Clemente Vella
2017-07-21 20:17 ` Moral Agent [this message]
2017-07-22 6:45 ` Major Kusanagi
2017-08-21 13:35 ` Thomas Guyot-Sionnest
2017-08-21 14:26 ` Moral Agent
2017-08-21 17:24 ` Erik Aronesty
2017-08-22 8:19 Matthew Beton
2017-08-22 13:45 ` Chris Riley
2017-08-22 14:04 ` Matthew Beton
2017-08-22 14:29 ` Erik Aronesty
2017-08-22 17:24 ` Thomas Guyot-Sionnest
2017-08-22 17:33 ` Matthew Beton
2017-08-22 18:55 ` Chris Riley
2017-08-22 20:06 ` Erik Aronesty
2017-08-22 20:20 ` Mark Friedenbach
2017-08-22 22:17 Daniele Pinna
2017-08-22 23:27 ` Thomas Guyot-Sionnest
2017-08-22 22:58 Rodney Morris
2017-08-22 23:29 ` Thomas Guyot-Sionnest
2017-08-23 3:26 ` Mark Friedenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACiOHGxYGdaPTAt07HFFGPEDhRC4PM3FZKk8Cwc0RgDN74qQrw@mail.gmail.com \
--to=ethan.scruples@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=lvella@gmail.com \
--cc=majorkusanagibtc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox