On Tue, May 16, 2017 at 03:15:17PM +0300, Alex Mizrahi via bitcoin-dev wrote:
> > Something I've recently realised is that TXO commitments do not need to be
> > implemented as a consensus protocol change to be useful.
>
>
> You're slow, Peter. I figured this out back in 2013:
>
> https://bitcoin
> Something I've recently realised is that TXO commitments do not need to be
> implemented as a consensus protocol change to be useful.
You're slow, Peter. I figured this out back in 2013:
https://bitcointalk.org/index.php?topic=153662.10
___
bitcoin-d
Peter Todd & Eric Lombrozo,
I also think communicating the UTXO would be increadibly useful. I just made a
writeup called "Synchronization Checkpoints" on github.
"https://github.com/bitcoin/bitcoin/issues/9885"; This idea also doesn't use
commitments.
But... Commitments would be a plus, becau
On Wed, Feb 22, 2017 at 08:11:47PM -0500, Peter Todd via bitcoin-dev wrote:
> 5) By *not* committing the TXO commitment in the block itself, we obsolete my
> concept of delayed TXO commitments: you don't need to have calculated the TXO
> commitment digest to validate a block anyway!
Thinking about
This kind of thing is long overdue!
I think it’s a great idea to attempt this without soft forking TXO
commitments yet so we can see what works best.
- E
On Wed, Feb 22, 2017 at 5:11 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Something I've recently realis
Something I've recently realised is that TXO commitments do not need to be
implemented as a consensus protocol change to be useful. All the benefits they
provide to full nodes with regard to allowing for old UTXO data to be pruned -
and thus solving the UTXO bloat problem - can be implemented even
