From: Peter Todd <pete@petertodd•org>
To: Tamas Blummer <tamas@bitsofproof•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Date: Mon, 15 Dec 2014 07:39:42 -0500 [thread overview]
Message-ID: <20141215123942.GA28381@savin.petertodd.org> (raw)
In-Reply-To: <AEDF060A-17E7-4519-950A-30974D1520E3@bitsofproof.com>
[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]
On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
> Burn mining side chains might be one of the foundation ideas for that ecosystem, enabling permission-less merge mining for
> anyone with interest in a side chain.
>
> I am puzzled by the lack of feedback on the idea.
It's not a new idea actually - I outlined a system I eventually called
"zookeyv"¹ based on the notion of sacrificing Bitcoins to achieve
consensus a year and a half ago on #bitcoin-wizards. The discussion
started here and continued for a few days:
https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log
I later wrote up the idea in the context of adding Zerocoin to Bitcoin:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
For key-value mapping I eventually decided that the system didn't
necessarily need to be a strict linear blockchain - a directed acyclic
graph of commitments had advantages as there needed to be less
syncronization between transactions. This also means that the graph
doesn't necessarily need to be revealed directly in the blockchain,
exposing it to miner censorship. OTOH revealing it makes it easy to
determine if an attacker larger than you exists. These days I'd suggest
using timelock crypto to defeat miner censorship, while ensuring that in
principle consensus over all possible parts of the chain can eventually
be reached.²
Proof-of-sacrifice for consensus has a few weird properties. For
instance you can defeat attackers after the fact by simply sacrificing
more than the attacker. Not unlike having a infinite amount of mining
equipment available with the only constraint being funds to pay for the
electricity. (which *is* semi-true with altcoins!)
As for your specific example, you can improve it's censorship resistance
by having the transactions commit to a nonce in advance in some way
indistinguishable from normal transactions, and then making the
selection criteria be some function of H(nonce | blockhash) - for
instance highest wins. So long as the chain selection is based on
cumulative difficulty based on a fixed target - as is the case in
Bitcoin proper - you should get a proper incentive to publish blocks, as
well as the "total work information rachet" effect Bitcoin has against
attackers.
1) In honor of Zooko's triangle.
2) This doesn't necessarily take as much work as you might expect: you
can work backwards from the most recent block(s) if the scheme
requires block B_i to include the decryption key for block B_{i-1}.
--
'peter'[:-1]@petertodd.org
000000000000000018d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2014-12-15 12:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 21:14 [Bitcoin-development] ACK NACK utACK "Concept ACK" Sergio Lerner
2014-12-09 21:30 ` Matt Corallo
2014-12-10 6:47 ` Wladimir
2014-12-10 7:35 ` [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain Tamas Blummer
2014-12-10 8:30 ` patrick
2014-12-16 9:55 ` Alex Mizrahi
2014-12-16 12:36 ` Peter Todd
2014-12-15 14:55 ` Isidor Zeuner
2014-12-16 8:28 ` Tamas Blummer
2014-12-16 12:30 ` Tamas Blummer
2014-12-18 16:23 ` Tamas Blummer
2014-12-10 8:21 ` [Bitcoin-development] ACK NACK utACK "Concept ACK" Wladimir
2014-12-10 15:45 ` Austin Walne
2014-12-17 8:44 ` Wladimir
2014-12-10 15:52 ` Jeff Garzik
2014-12-16 23:40 ` Btc Drak
2014-12-11 12:09 ` [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain Isidor Zeuner
2014-12-11 14:56 ` Tamas Blummer
2014-12-15 10:21 ` Tamas Blummer
2014-12-15 12:39 ` Peter Todd [this message]
2014-12-15 13:06 ` Tamas Blummer
2015-02-04 13:54 ` Isidor Zeuner
2015-02-06 1:34 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141215123942.GA28381@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tamas@bitsofproof$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox