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 wi
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 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/4/13 11:38 AM, Mike Hearn wrote:
> > The Merkle branch doesn't get stored indefinitely thou
-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
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 wrote:
> No sense in compromising - you need a whole merkle path to prove the
> extra data is valid so you might as well make this a full 256
-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 d
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
6 matches
Mail list logo
