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 else can do that" WRT 2-way-pegs was overreaching.
Yup. > I still don't see what "2-way-peg vs. 1-way-peg" has to do with > "embedded consensus vs. blockchain consensus" though, and feel it > disingenious to conflate them. 1-way-pegs don't require the Bitcoin protocol to change; 2-way-pegs do. > Blockchain consensus (eg. sidechains) can utilise either mechanism, > 1-way-peg or 2-way-peg. Arguments in favour of 1-way-peg are > interesting, but they're ultimatley just arguments in favour of one > type of sidechain over another. No, they're in favor of systems that are client-side validatable vs. systems that either allow anyone with sufficient hashing power to steal coins *or* require "moon-math" that isn't yet available to production systems. > IMO the question of whether scarcity can be preserved while enabling > innovation bears heavily on the liklihood of longterm viability of > said innovations - and perhaps of Bitcoin itself. > > FWIW I'll happily declare that I hold a modest amount of BTC and have > an interest in the price appreciating. I'm sure you'll admit you're > hardly an impartial party in this discussion yourself Peter :) But it > really shouldn't matter. I'm not here today to make it, but I think > the argument for preservation of scarcity stands quite well on its own > merits - as rightly it should, regardless of anybody's interests. But again, all these discussions about scarcity are fundementally *moral* arguments that have no bearing on what's actually the most appropriate solution for an *individual* problem. In a decentralized system filled with anonymous actors telling people "stop doing that! it's bad!" on reddit has pretty severe limitations in trying to convince people to act against their own best interests. > > 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. > > Very interesting. I admit I hadn't come across these ideas before; I > really must search the archive before posting :) They certainly offer > a measure of robustness over the naive approach. I'm not sure they > address my primary concerns however, WRT how consensus is demonstrated > and incentivised. I think you think consensus in Bitcoin is more "magical" than it really is; Bitcoin is just code running on computers; consensus isn't really incentivised at the protocol level beyond "screw it up and you'll lose money" Embedded consensus systems are no different: screw up consensus and you'll lose money in a variety of ways. > The obvious "embedded consensus" answer of "wait until N other > transactions have occurred that include a hash of system state that > includes your transaction" doesn't provide me with any confidence; it > could be simulated with a Sybil attack. No it can't - the transactions are in the blockchain so the sybil attack has to attack the host system as well. In any case, keep in mind all of this is in the context of tradeoffs: for a different and sometimes more fragile consensus mechanism embedded consensus gets immunity to attack by miners. You're trading off one type of fragility for another - I'd much rather take the "one-time" fragility inherent in having to write really solid software than the ongoing fragility of always being vulnerable to miners. Notably this is the exact same tradeoff taken elsewhere by the majority of the crypto world. -- 'peter'[:-1]@petertodd.org 000000000000000017d70ee98f4cee509d95c4f31d5b998bae6deb09df1088fc
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
