Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-20 Thread Peter Todd
On Wed, Dec 17, 2014 at 10:55:28PM +1100, Gareth Williams wrote: I covered this in my original post: 1-way-pegs allow the creation of new valuable tokens without those tokens being useful for speculation. I stand corrected. A permanent 1-way-peg is sufficient to preserve scarcity; nothing

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-17 Thread Gareth Williams
On Mon, Dec 15, 2014 at 3:52 PM, Peter Todd p...@petertodd.org wrote: Comparisons with the SPV security of sidechains are fallacious. The alternative to a proof-of-publication system reliant on client-side validation is a blockchain. The question of whether the token used on said blockchain

[Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-17 Thread paul snow
[[Since I sent this while the List Server was down, it didn't actually go to everyone. Forgive me if you ended up with two copies.]] Peter provides an excellent summary of Proof of Publication, which starts with defining it as being composed of a solution to the double spend problem. He

[Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-16 Thread paul snow
Peter provides an excellent summary of Proof of Publication, which starts with defining it as being composed of a solution to the double spend problem. He requires Proof-of-receipt (proof every member of p in audience P has received a message m), Proof-of-non-publication (proof a message m has

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-16 Thread odinn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 bleep bloop Peter Todd: On Fri, Dec 12, 2014 at 01:41:34PM +, odinn wrote: Peter... It kind of sounds to me that (as fine of a position paper as this is) on _certain_ points, you're falling prey to the but it's inefficient, but it's a

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-14 Thread Peter Todd
On Fri, Dec 12, 2014 at 07:50:48PM +0200, Alex Mizrahi wrote: I think what Gareth was getting at was that with client-side validation there can be no concept of a soft-fork. And how certain are you that the consensus rules will never change? Yes, it is true that you can't do a

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-14 Thread Peter Todd
On Sun, Dec 14, 2014 at 12:32:22AM +1100, Gareth Williams wrote: On 13/12/14 04:04, Alex Mizrahi wrote: Well, client-side validation is mathematically secure, while SPV is economically secure. I.e. it is secure if you make several assumptions about economics of the whole thing.

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-14 Thread Peter Todd
On Fri, Dec 12, 2014 at 01:41:34PM +, odinn wrote: Peter... It kind of sounds to me that (as fine of a position paper as this is) on _certain_ points, you're falling prey to the but it's inefficient, but it's a scamcoin, but luke-jr told me so argument... I prefer to make robust arguments;

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-13 Thread Gareth Williams
On 13/12/14 04:04, Alex Mizrahi wrote: Well, client-side validation is mathematically secure, while SPV is economically secure. I.e. it is secure if you make several assumptions about economics of the whole thing. Comparisons with the SPV security of sidechains are fallacious. The alternative

[Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Peter Todd
Introduction While not a new concept proof-of-publication is receiving a significant amount of attention right now both as an idea, with regard to the embedded consensus systems that make use of it, and in regard to the sidechains model proposed by Blockstream that rejects it. Here

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Gareth Williams
On 12/12/14 20:05, Peter Todd wrote: Secondly using a limited-supply token in a proof-of-publicaton system is what lets you have secure client side validation rather than the alternative of 2-way-pegging that requires users to trust miners not to steal the pegged funds. Secure and client

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread odinn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Peter... It kind of sounds to me that (as fine of a position paper as this is) on _certain_ points, you're falling prey to the but it's inefficient, but it's a scamcoin, but luke-jr told me so argument... I think the Mastercoin devs are doing fine

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/12/2014 01:41 PM, odinn wrote: I think the Mastercoin devs are doing fine work I wonder if all the Mastercoin devs would agree with that statement. - -- Support online privacy by using email encryption whenever possible. Learn how here:

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Alex Mizrahi
Secure and client side validation don't really belong in the same sentence, do they? Well, client-side validation is mathematically secure, while SPV is economically secure. I.e. it is secure if you make several assumptions about economics of the whole thing. In my opinion the former is

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Alex Mizrahi
I think what Gareth was getting at was that with client-side validation there can be no concept of a soft-fork. And how certain are you that the consensus rules will never change? Yes, it is true that you can't do a soft-fork, but you can do a hard-fork. Using scheduled updates: client simply