On Mon, May 22, 2017 at 9:47 PM, Rusty Russell wrote:
> Gregory Maxwell via bitcoin-dev
> writes:
>> On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille
>> wrote:
>>> just the first - and one that has very low
Gregory Maxwell via bitcoin-dev writes:
> On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille
> wrote:
>> just the first - and one that has very low costs and no normative
>> datastructures at all.
>
> The serialization of the txout
On Tue, May 16, 2017 at 4:01 AM, Peter Todd via bitcoin-dev
wrote:
> To be clear, *none* of the previous (U)TXO commitment schemes require *miners*
> to participate in generating a commitment. While that was previously thought
> to
> be true by many, I've
On Mon, May 15, 2017 at 11:59:58PM +, Gregory Maxwell via bitcoin-dev wrote:
> On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev
> wrote:
> > transactions is in the header, which would let lite nodes download a UTXO
> > set from any full node
On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev
wrote:
> transactions is in the header, which would let lite nodes download a UTXO
> set from any full node and verify it by verifying only block headers
> starting from genesis.
Ya, lite nodes with
Good morning Pieter,
>4. Use cases
>
>* Replacement for Bitcoin Core's gettxoutsetinfo RPC's hash
>computation. This currently requires minutes of I/O and CPU, as it
>serializes and hashes the entire UTXO set. A rolling set hash would
>make this instant, making the whole RPC much more usable for
Hi Pieter,
I wanted to say that I thought this write-up was excellent! And efficiently
hashing the UTXO set in this rolling fashion is a very exciting idea!!
Peter R
> On May 15, 2017, at 1:01 PM, Pieter Wuille via bitcoin-dev
> wrote:
>
> Hello all,
Hello all,
I would like to discuss a way of computing a UTXO set hash that is
very efficient to update, but does not support any compact proofs of
existence or non-existence.
Much has been written on the topic of various data structures and
derived hashes for the UTXO/TXO set before (including