Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

On Fri, May 20, 2016 at 11:46:32AM +0200, Johnson Lau wrote: > How is this compared to my earlier proposal: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html > > > ? > > In my

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

How is this compared to my earlier proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html ? In my proposal, only the (pruned) UTXO set, and 32 bytes per archived block, are

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

On Thu, May 19, 2016 at 04:23:28PM -0600, Nick ODell wrote: > What if two people create transactions from oupoints within the same MMR > tree tip, at the same time? > > For example, I create transaction A plus an MMR proof that MMR tip X will > become Y. > > On the other side of the planet, some

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

What if two people create transactions from oupoints within the same MMR tree tip, at the same time? For example, I create transaction A plus an MMR proof that MMR tip X will become Y. On the other side of the planet, someone else creates transaction B, plus an MMR proof that tip X will become Z

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

On May 19, 2016 01:53, "Peter Todd" wrote: tip of the tree. > > > > How expensive it is to update a leaf from this tree from unspent to spent? > > log2(n) operations. Updating a leaf is just as expensive as adding a new one? That's not what I expected. Or is adding a new one O (1) ? Anyway, than

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

On Wed, May 18, 2016 at 01:14:59PM +0200, Jorge Timón wrote: > On May 17, 2016 15:23, "Peter Todd via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > # TXO Commitments > > > > > Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a > > type of deterministic, in

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

On May 17, 2016 15:23, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > # TXO Commitments > > Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a > type of deterministic, indexable, insertion ordered merkle tree, which allows > new items to be chea

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

On 5/17/16, Eric Lombrozo via bitcoin-dev wrote: > Nice! > > We’ve been talking about doing this forever and it’s so desperately needed. > "So desperately needed"? How do you figure? The UTXO set is currently 1.5 GB. What kind of computer these days doesn't have 1.5 GB of memory? Since you people

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

Great post, Peter. 4) By fixing the problem (or possibly just "fixing" the problem) are we encouraging/legitimising blockchain use-cases other than BTC value transfer? Should we? I don't think it would encourage non-value-transfer usage more because, as you noted, many such use cases are valuable

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

Nice! We’ve been talking about doing this forever and it’s so desperately needed. > On May 17, 2016, at 3:23 PM, Peter Todd via bitcoin-dev > wrote: > > # Motivation > > UTXO growth is a serious concern for Bitcoin's long-term decentralization. To > run a competitive mining operation potentia

[bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

# Motivation UTXO growth is a serious concern for Bitcoin's long-term decentralization. To run a competitive mining operation potentially the entire UTXO set must be in RAM to achieve competitive latency; your larger, more centralized, competitors will have the UTXO set in RAM. Mining is a zero-su