Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-06-07 Thread Olaoluwa Osuntokun via bitcoin-dev
Hi sipa, > The advantage of (a) is that it can be verified against a full block without > access to the outputs being spent by it > > The advantage of (b) is that it is more compact (scriot reuse, and outputs > spent within the same block as they are created). Thanks for this breakdown. I think y

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

2018-06-07 Thread Peter Todd via bitcoin-dev
On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote: > Are you proposing a soft fork to include the number of transactions in a > block in the block headers to compensate for the broken Merkle format? That > sounds like a good idea. > > On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoi

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

2018-06-07 Thread Bram Cohen via bitcoin-dev
Are you proposing a soft fork to include the number of transactions in a block in the block headers to compensate for the broken Merkle format? That sounds like a good idea. On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It's well kno

[bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

2018-06-07 Thread Peter Todd via bitcoin-dev
It's well known that the Bitcoin merkle tree algorithm fails to distinguish between inner nodes and 64 byte transactions, as both txs and inner nodes are hashed the same way. This potentially poses a problem for tx inclusion proofs, as a miner could (with ~60 bits of brute forcing) create a transac

Re: [bitcoin-dev] BIP suggestion: PoW proportional to block transaction sum

2018-06-07 Thread Darren Weber via bitcoin-dev
Hi Thomas, Thanks for considering this suggestion. You've raised some interesting points (and concluded that it could be very difficult to implement). I'm not yet at a point where I could answer any questions about implementation details with any authority. With that caveat, your points are wor

Re: [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set

2018-06-07 Thread Sjors Provoost via bitcoin-dev
eMMC storage, which low end devices often use, come in 2x increments. Running a pruned full node on 8 GB is difficult if not impossible (the UTXO set peaked at 3.5 GB in January, but a full node stores additional stuff). However, 16 GB is only €10 more expensive and presumably standard by the ti

Re: [bitcoin-dev] Should Graftroot be optional?

2018-06-07 Thread Tim Ruffing via bitcoin-dev
What you're saying makes sense. By the way, an even stronger reason why you shouldn't be able to "repurpose" just a Graftroot signature as a transaction: You may want to reveal to others that you've delegated. But if an observer sees the delegation (literally the Graftroot signature), this observe