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:00:16PM +0100, Mike Hearn wrote:
Given that IP address data is inherently transient, perhaps a better
solution is to define a short hash in the coinbase that commits to extra
data that is relayed along with block data (e.g. appended to the block
message). It can then
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
7 matches
Mail list logo