On Mon, Nov 04, 2013 at 11:11:34AM -0800, Mark Friedenbach wrote:
Now interpret the bits of that UUID as an allowed path: 0 = left, 1
= right, from the top of the tree. When you build the tree, make
sure everything that is going to be committed to uses it's allowed
path; the tree will look
On Mon, Nov 04, 2013 at 01:16:49PM -0500, Peter Todd wrote:
You'll want to put some reasonable limit on actual path lengths, just
pick something like 32 levels; if applications pick their UUIDs honestly
a collision will be very unlikely. You can also make the allowed paths
block specific by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 10:16 AM, Peter Todd wrote:
Again, the right way to do this is define the standard to use the
last txout so that midstate compression can be applied in the
future. We can re-use this for merge-mining and other commitments
easily by
I like the UUID-as-path idea. That resolves the problem of how to share the
alt-chain merkle tree quite nicely.
On Mon, Nov 4, 2013 at 7:16 PM, Peter Todd p...@petertodd.org wrote:
No sense in compromising - you need a whole merkle path to prove the
extra data is valid so you might as well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
The Merkle branch doesn't get stored indefinitely though, whereas
the coinbase hash does. The data stored in the coinbase [output]
can always just be the 256-bit root hash truncated to less.
I doubt the
Yes, sure. I was talking about the case of transiently relayed data, like
IP addresses.
On Mon, Nov 4, 2013 at 8:53 PM, Mark Friedenbach m...@monetize.io wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
The Merkle branch doesn't get stored
6 matches
Mail list logo
