Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2015-02-05 Thread Peter Todd
On Wed, Feb 04, 2015 at 02:54:43PM +0100, Isidor Zeuner wrote: > Hi there, > > comments in-line: > > >> 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 the sake

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2015-02-04 Thread Isidor Zeuner
Hi there, comments in-line: > > 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 the sake of maximum clarity with respect to modelling the value of a Bitcoin, I don't th

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-18 Thread Tamas Blummer
Moving further with the Idea: Alternative to re-adjusting the lottery criteria, the side chain block candidate could be required to prove a work to be eligible for the burn lottery. A mix of required burn, work and luck could be tailored to achieve the desired "51% resilience” of the side cha

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Peter Todd
On Tue, Dec 16, 2014 at 11:55:50AM +0200, Alex Mizrahi wrote: > Usually at this point people say "we assume that miners aren't going to > collude, otherwise even Bitcoin is not secure". > Well, this is BS. The fact that a pool can acquire more than 50% of total > hashpower was successfully demonstr

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Tamas Blummer
Let me be more concrete in implementation details: 1) burn transaction sends at least n satoshis to an OP_RETURN h, 2) h mod m matches the bitcoin block hash mod m, for the block the burn transaction was mined into. 3) The side chain block header hashes to h and also contains the bitcoin block

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Alex Mizrahi
> The goal is to have an opportunity cost to breaking the rules. > You could as well have said "The goal is to implement it in a specific way I want it to be implemented." This makes zero sense. You aren't even trying to compare properties of different possible implementations, you just outright

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Tamas Blummer
The output has to be burned otherwise there is no cost of expressing any number of alternate opinions the same time. Tamas Blummer Bits of Proof On Dec 15, 2014, at 3:55 PM, Isidor Zeuner wrote: > For every participant who could try to decide about the adequateness > of the cost, no direct eff

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-15 Thread Isidor Zeuner
> The goal is to have an opportunity cost to breaking the rules. > > Proof of Burn is a real cost for following the rules. > For every participant who could try to decide about the adequateness of the cost, no direct effect comes from the difference between Proof of Burn, and approaches which keep

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-15 Thread Tamas Blummer
Peter, Thanks for the research, I am glad that the idea, that proof-of-burn can “transfer" proof-of-work was discussed earlier, as those discussions give some attack vectors that I can reevaluate in a new context, that is side chains. I think that the lottery component I suggested, makes it

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-15 Thread Peter Todd
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 n

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-15 Thread Tamas Blummer
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. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-11 Thread Tamas Blummer
Isodor: Rational Miner will include burn transaction for fee, no doubt. Censoring transactions is against Bitcoin’s core values, unlikely to get wide support for any form of that. Patrick: Mining is at cost even if following the rules. No change to that. Tamas Blummer Bits of Proof signature.

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-11 Thread Isidor Zeuner
[...] > The Bitcoin miner will include burn transactions because they offer > Bitcoin fees. Bitcoin miner can not selectively block side chains > since the hashes associated with the burn do not disclose which side > chain or other project they are for. Here you have a “merged > mining” that does n

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-10 Thread patrick
The goal is to have an opportunity cost to breaking the rules. Proof of Burn is a real cost for following the rules. On 12/10/2014 01:35 AM, Tamas Blummer wrote: > We spend scarce resources external to the digital realm to create Bitcoin. > Real world sacrifice is needed to avoid “nothing at sta

[Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-09 Thread Tamas Blummer
We spend scarce resources external to the digital realm to create Bitcoin. Real world sacrifice is needed to avoid “nothing at stake” and sybil attacks. With Bitcoin we now have a scarce resource within the digital realm, so it appeals my intuition to re-use it for sacrifice instead of linking