Peter Todd [ARCHIVE] on Nostr: š Original date posted:2014-12-15 š Original message:On Sun, Dec 14, 2014 at ...
š
Original date posted:2014-12-15
š Original message: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.
>
> 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 should be two-way-pegged to BTC is completely orthogonal.
>
> (ie. yes, sidechains are "economically secure", in that you're reduced
> to balancing economic incentives to avoid peg theft. But sidechains also
> give us something unique in return - the ability to innovate without
> needing to start new artificial scarcity races. Nothing else can do that.)
I covered this in my original post: 1-way-pegs allow the creation of new
valuable tokens without those tokens being useful for speculation.
To recap, a 1-way-peg allows the conversion of Bitcoins to another token
by provably destroying the Bitcoins, thus capping the maximum possible
value of that token and ensuring the token can-not become an investment.
For owners of these tokens they can convert them back to Bitcoin by
selling them at a discount to buyers who would otherwise be able to
purchase them via provable destruction. A pragmatic implementation may
wish to make obtaining the token via destruction option unattractive
compared to obtaining them through trade by incorporating a time delay
into the destruction process to encourage liquidity. (interestingly a
natural outcome of an announce-commit sacrifice-to-fees scheme)
Of course even without 1-way-pegs there's a much more important issue
with your objection: worrying about creating new artificial scarcity
races while innovating is fundementally a *moralistic* and *regulatory*
concern that has no little if any bearing on whether or not the systems
created are useful and secure. It's also an objection that raises
serious questions about conflicts of interest between giving accurate
and honest technical advice and promoting ways of using Bitcoin that
will drive the price up.
> > You know, The Great Fork of 2013 was resolved through human
> > intervention, Bitcoin nodes were not smart enough to detect that
> > something is going awry on their own.
>
> I hate to think what the outcome would've been on a proof-of-publication
> system. You don't even have a fork. You just have a whole bunch of nodes
> who sort-of-mostly agree on a shared history, except where they don't.
> Maybe they just disagree on the validity of a single transaction.
> They'll slowly diverge over time (as bad transactions are used as input
> to other transactions.) You have no reliable way to detect this lapse in
> consensus, nor any mechanism to incentivse convergence. Indeed, you have
> no consensus mechanism in the first place.
A number of mechanisms for detecting divergence are possible in embedded
consensus systems, some of them even natural outcomes. For instance
transactions can contain a hash of the previous consensus state, thereby
creating an indicator of consensus measured in terms of economic stake.
Extending that idea many anti-censorship proposals are to use such state
hashes as encryption keys - if you are out of consensus you won't even
see the transaction. (and you can't be double-spent either if
implemented correctly; see my other reply to this thread today)
> Bitcoin is where it is today because of Satoshi's elegant solution to
> exactly such problems. Which some people now appear to be in a hurry to
> discard :)
FWIW usually Satoshi's solution is described as a hack, sometimes as an
elegant hack.
> Peter Todd might disagree with the wisdom of that :) He wrote an
> excellent email to this list not long ago warning of the dangers of
> centralisation. IIRC one point he made was that scheduled, regular
> hardforks were a real threat - if a single entity (eg. the Bitcoin
> Foundation) were to become politically established as the coordinator of
> such forks, they would have de-facto control over the protocol.
Indeed I did, which is why I worked out a better way to do upgrades
almost a year ago:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06578.html
> (Also worth noting: all such systems are effectively "mandatory
> updating" due to the risk of subtle consensus bugs of the type I
> described above. Your only assurance that your view of the world is the
> same as everyone elses' is that you're running the exact same software.
> I played with Counterparty a while ago and quickly learned - the hard
> way - to do a 'git pull' before any important operation.)
The quality of Counterparty's software engineering has no bearing on
whether or not the underlying idea is a good one; you wouldn't say ring
signatures are an inherently bad idea just because the CryptoNote
implementation of them is atrocious.
--
'peter'[:-1]@petertodd.org
00000000000000000681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141214/599477c2/attachment.sig>;
š Original message: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.
>
> 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 should be two-way-pegged to BTC is completely orthogonal.
>
> (ie. yes, sidechains are "economically secure", in that you're reduced
> to balancing economic incentives to avoid peg theft. But sidechains also
> give us something unique in return - the ability to innovate without
> needing to start new artificial scarcity races. Nothing else can do that.)
I covered this in my original post: 1-way-pegs allow the creation of new
valuable tokens without those tokens being useful for speculation.
To recap, a 1-way-peg allows the conversion of Bitcoins to another token
by provably destroying the Bitcoins, thus capping the maximum possible
value of that token and ensuring the token can-not become an investment.
For owners of these tokens they can convert them back to Bitcoin by
selling them at a discount to buyers who would otherwise be able to
purchase them via provable destruction. A pragmatic implementation may
wish to make obtaining the token via destruction option unattractive
compared to obtaining them through trade by incorporating a time delay
into the destruction process to encourage liquidity. (interestingly a
natural outcome of an announce-commit sacrifice-to-fees scheme)
Of course even without 1-way-pegs there's a much more important issue
with your objection: worrying about creating new artificial scarcity
races while innovating is fundementally a *moralistic* and *regulatory*
concern that has no little if any bearing on whether or not the systems
created are useful and secure. It's also an objection that raises
serious questions about conflicts of interest between giving accurate
and honest technical advice and promoting ways of using Bitcoin that
will drive the price up.
> > You know, The Great Fork of 2013 was resolved through human
> > intervention, Bitcoin nodes were not smart enough to detect that
> > something is going awry on their own.
>
> I hate to think what the outcome would've been on a proof-of-publication
> system. You don't even have a fork. You just have a whole bunch of nodes
> who sort-of-mostly agree on a shared history, except where they don't.
> Maybe they just disagree on the validity of a single transaction.
> They'll slowly diverge over time (as bad transactions are used as input
> to other transactions.) You have no reliable way to detect this lapse in
> consensus, nor any mechanism to incentivse convergence. Indeed, you have
> no consensus mechanism in the first place.
A number of mechanisms for detecting divergence are possible in embedded
consensus systems, some of them even natural outcomes. For instance
transactions can contain a hash of the previous consensus state, thereby
creating an indicator of consensus measured in terms of economic stake.
Extending that idea many anti-censorship proposals are to use such state
hashes as encryption keys - if you are out of consensus you won't even
see the transaction. (and you can't be double-spent either if
implemented correctly; see my other reply to this thread today)
> Bitcoin is where it is today because of Satoshi's elegant solution to
> exactly such problems. Which some people now appear to be in a hurry to
> discard :)
FWIW usually Satoshi's solution is described as a hack, sometimes as an
elegant hack.
> Peter Todd might disagree with the wisdom of that :) He wrote an
> excellent email to this list not long ago warning of the dangers of
> centralisation. IIRC one point he made was that scheduled, regular
> hardforks were a real threat - if a single entity (eg. the Bitcoin
> Foundation) were to become politically established as the coordinator of
> such forks, they would have de-facto control over the protocol.
Indeed I did, which is why I worked out a better way to do upgrades
almost a year ago:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06578.html
> (Also worth noting: all such systems are effectively "mandatory
> updating" due to the risk of subtle consensus bugs of the type I
> described above. Your only assurance that your view of the world is the
> same as everyone elses' is that you're running the exact same software.
> I played with Counterparty a while ago and quickly learned - the hard
> way - to do a 'git pull' before any important operation.)
The quality of Counterparty's software engineering has no bearing on
whether or not the underlying idea is a good one; you wouldn't say ring
signatures are an inherently bad idea just because the CryptoNote
implementation of them is atrocious.
--
'peter'[:-1]@petertodd.org
00000000000000000681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141214/599477c2/attachment.sig>;