On Thu, Feb 23, 2017 at 07:32:43PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 7:15 PM, Peter Todd wrote:
>
> >
> > Glad we're on the same page with regard to what's possible in TXO
> > commitments.
> >
> > Secondly, am I correct in saying your UTXO commitments scheme requires
> > random
>
On Thu, Feb 23, 2017 at 7:15 PM, Peter Todd wrote:
>
> Glad we're on the same page with regard to what's possible in TXO
> commitments.
>
> Secondly, am I correct in saying your UTXO commitments scheme requires
> random
> access? While you describe it as a "merkle set", obviously to be merkelized
On Thu, Feb 23, 2017 at 07:02:36PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 6:58 PM, Peter Todd wrote:
>
> >
> > So to be clear, do you agree or disagree with me that you *can* extract a
> > compact proof from a MMR that a given output is unspent?
> >
>
> After wading through your logi
On Thu, Feb 23, 2017 at 6:58 PM, Peter Todd wrote:
>
> So to be clear, do you agree or disagree with me that you *can* extract a
> compact proof from a MMR that a given output is unspent?
>
After wading through your logic on how updates are done, I agree that that
can be done, but apples to appl
On Thu, Feb 23, 2017 at 06:50:10PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd wrote:
>
> > I think you've misunderstood what TXO commitments are. From my article:
> >
> > "A merkle tree committing to the state of all transaction outputs, both
> > spent
> > and unspent,
On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd wrote:
> I think you've misunderstood what TXO commitments are. From my article:
>
> "A merkle tree committing to the state of all transaction outputs, both
> spent
> and unspent, can provide a method of compactly proving the current state
> of an
> out
On Thu, Feb 23, 2017 at 04:49:01PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 3:51 PM, Peter Todd wrote:
>
> > On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote:
> > >
> > > I can't speak to MMRs (they look a bit redundant with the actual
> > blockchain
> > > history to my eye) b
On Thu, Feb 23, 2017 at 3:51 PM, Peter Todd wrote:
> On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote:
> >
> > I can't speak to MMRs (they look a bit redundant with the actual
> blockchain
> > history to my eye) but circling back to utxo commitments, the benefits
> are
>
> In what way d
Maybe not, unlike frozen objects (certificates, etc), trees are supposed
to extend
Then you can perform progressive hash operations on the objects, ie
instead of hashing the intermediate hash of the objects you do it
continuously (ie instead of hashing the hash of hash file a + hash file
b + hash
On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >
> > What problem does this try to solve, and what does it have to do with
> > bitcoin?
> >
>
> I can't speak to MMRs
On Thu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> What problem does this try to solve, and what does it have to do with
> bitcoin?
>
I can't speak to MMRs (they look a bit redundant with the actual blockchain
history to my eye) but c
On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wrote:
> Worth noting: the impact of the SHA1 collison attack on Git is *not* limited
> only to maintainers making maliciously colliding Git commits, but also
> third-party's submitting pull-reqs containing commits, trees, and esp
On Thu, Feb 23, 2017 at 01:28:18PM -0500, G. Andrew Stone wrote:
> Can an insertion ordered MMR allow an efficient nonexistence proof?
Why do you want a non-existance proof?
It supports an efficient *spentness* proof, which is sufficient for what we
need in Bitcoin, and much more scalable.
--
h
Can an insertion ordered MMR allow an efficient nonexistence proof?
On Feb 23, 2017 1:20 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Feb 23, 2017 at 09:53:58AM -0800, Chris Priest wrote:
> > On 2/22/17, Peter Todd via bitcoin-dev
> > wrote:
> > > Rep
On Thu, Feb 23, 2017 at 09:53:58AM -0800, Chris Priest wrote:
> On 2/22/17, Peter Todd via bitcoin-dev
> wrote:
> > Reposting something that came up recently in a private discussion with some
> > academics:
> >
> > Concretely, let's define a prunable MMR with the following grammar. This
> > defini
Worth noting: the impact of the SHA1 collison attack on Git is *not* limited
only to maintainers making maliciously colliding Git commits, but also
third-party's submitting pull-reqs containing commits, trees, and especially
files for which collisions have been found. This is likely to be exploitab
On 2/22/17, Peter Todd via bitcoin-dev
wrote:
> Reposting something that came up recently in a private discussion with some
> academics:
>
> Concretely, let's define a prunable MMR with the following grammar. This
> definition is an improvement on whats in the python-proofmarshal by
> committing
>
17 matches
Mail list logo
