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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
