* [Bitcoin-development] ACK NACK utACK "Concept ACK" @ 2014-12-09 21:14 Sergio Lerner 2014-12-09 21:30 ` Matt Corallo 0 siblings, 1 reply; 23+ messages in thread From: Sergio Lerner @ 2014-12-09 21:14 UTC (permalink / raw) To: bitcoin-development Is that the full terminology or are there more acronyms? Is this documented somewhere? Best regards, Sergio. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] ACK NACK utACK "Concept ACK" 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 0 siblings, 1 reply; 23+ messages in thread From: Matt Corallo @ 2014-12-09 21:30 UTC (permalink / raw) To: bitcoin-development Also utACK ("untested ack") and "tested ack" when people are being explicit. On 12/09/14 21:14, Sergio Lerner wrote: > Is that the full terminology or are there more acronyms? > Is this documented somewhere? > > Best regards, > Sergio. > > > > ------------------------------------------------------------------------------ > 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] ACK NACK utACK "Concept ACK" 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 ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Wladimir @ 2014-12-10 6:47 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin Dev Abbreviations: Concept ACK -> agree with the idea and overall direction, but haven't reviewed the code changes nor tested it utACK -> reviewed the code changes, but did not put it through any testing Tested ACK -> reviewed the code changes and verified the functionality/bug fix I tend to only use bare "ACK" if there is nothing to test in the first place, for example for documentation changes. Wladimir On Tue, Dec 9, 2014 at 9:30 PM, Matt Corallo <bitcoin-list@bluematt•me> wrote: > Also utACK ("untested ack") and "tested ack" when people are being explicit. > > On 12/09/14 21:14, Sergio Lerner wrote: >> Is that the full terminology or are there more acronyms? >> Is this documented somewhere? >> >> Best regards, >> Sergio. >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > ------------------------------------------------------------------------------ > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-10 6:47 ` Wladimir @ 2014-12-10 7:35 ` Tamas Blummer 2014-12-10 8:30 ` patrick ` (2 more replies) 2014-12-10 8:21 ` [Bitcoin-development] ACK NACK utACK "Concept ACK" Wladimir ` (2 subsequent siblings) 3 siblings, 3 replies; 23+ messages in thread From: Tamas Blummer @ 2014-12-10 7:35 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2361 bytes --] 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 again an external, real world resource. In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them. The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance. Those who want to mine the side chain will assemble side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain. A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. 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 not need Bitcoin miner support or even consent. Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in. The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin. Tamas Blummer Bits of Proof 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 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-15 14:55 ` Isidor Zeuner 2014-12-16 12:30 ` Tamas Blummer 2 siblings, 1 reply; 23+ messages in thread From: patrick @ 2014-12-10 8:30 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3193 bytes --] 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 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 again an external, real world resource. > > In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them. > > The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance. > > Those who want to mine the side chain will assemble side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain. > > A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. > > 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 not need Bitcoin miner support or even consent. > > Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in. > > The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin. > > Tamas Blummer > Bits of Proof > > 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd > > > ------------------------------------------------------------------------------ > 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 [-- Attachment #2: Type: text/html, Size: 4096 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-10 8:30 ` patrick @ 2014-12-16 9:55 ` Alex Mizrahi 2014-12-16 12:36 ` Peter Todd 0 siblings, 1 reply; 23+ messages in thread From: Alex Mizrahi @ 2014-12-16 9:55 UTC (permalink / raw) To: patrick; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1894 bytes --] > 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 reject the alternatives. So the thing is, relying on opportunity cost is rather problematic. 1. can't work when system isn't heavily used (you'll have to rely on the honesty of miners instead) 2. chicken-and-egg: system is not secure until it is heavily used, and it isn't heavily used until it is secure 3. finally, if the expected profit from attack is higher than the opportunity cost of it, it just makes no sense Let's put 1 and 2 aside. For the start, you need to prove that attack cannot yield profits which are higher than honest mining. The problem with it is that the total amount of money is much higher than the amount of money which is being transacted in a short time frame. And it is much higher than what fees might yield within a reasonable time frame. So if there is a way to attack the whole (with a profit proportional to the whole), you won't be able to rely on opportunity cost to prevent the attack. 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 demonstrated by ghash.io. But the thing is, Bitcoin doesn't offer one a good way to attack the whole, as there are powerful factors which will work against the attacker. But this is not the case with sidechains (or any merged-mined chains, for that matter). And once you have a clear incentive, collusion is much more likely. > Proof of Burn is a real cost for following the rules. > So what? As long as cost is less than revenue, it is OK. [-- Attachment #2: Type: text/html, Size: 2688 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-16 9:55 ` Alex Mizrahi @ 2014-12-16 12:36 ` Peter Todd 0 siblings, 0 replies; 23+ messages in thread From: Peter Todd @ 2014-12-16 12:36 UTC (permalink / raw) To: Alex Mizrahi; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1993 bytes --] 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 demonstrated by ghash.io. > But the thing is, Bitcoin doesn't offer one a good way to attack the whole, > as there are powerful factors which will work against the attacker. > But this is not the case with sidechains (or any merged-mined chains, for > that matter). > And once you have a clear incentive, collusion is much more likely. +1 It's notable that blockstream hasn't published much if anything concrete on what exactly you'd use merge-mined sidechains for; they're even worse than Ethereum in that regard. > > Proof of Burn is a real cost for following the rules. > > > > So what? As long as cost is less than revenue, it is OK. It's even better than that: if an attack does happen, the participants in the consensus system have an incentive to defend against it to maintain the value of their tokens. Proof-of-burn allows that defense to be in response to a threat, and essentially unlimited in size. So now any attacker knows that if they launch an attack in theory the response could be as strong as the value of the system itself. This can be improved upon with systems that allow the tokens to be burned, "internal" proof-of-burn. This suffers from "nothing-at-stake" vulnerabilities to an extent, OTOH within the context of the system it is a true sacrifice of value; probably not a big deal in a zookeyv-style block-DAG where multiple lines of history can be combined. Here the incentives of the defenders are even more strongly tipped towards burning their value to preserve the system, not unlike replace-by-fee-scorched-earth thinking. -- 'peter'[:-1]@petertodd.org 00000000000000000e0c078667795abe21bfdebb913eba60cc7a625c732f0a89 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 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-15 14:55 ` Isidor Zeuner 2014-12-16 8:28 ` Tamas Blummer 2014-12-16 12:30 ` Tamas Blummer 2 siblings, 1 reply; 23+ messages in thread From: Isidor Zeuner @ 2014-12-15 14:55 UTC (permalink / raw) To: patrick; +Cc: bitcoin-development > 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 the Bitcoins inside the set of outputs that can still participate. So, any notion which differentiates with respect to this must make some assumption about what defines the interest of the Bitcoin nodes as a community. Best regards, Isidor ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-15 14:55 ` Isidor Zeuner @ 2014-12-16 8:28 ` Tamas Blummer 0 siblings, 0 replies; 23+ messages in thread From: Tamas Blummer @ 2014-12-16 8:28 UTC (permalink / raw) To: Isidor Zeuner; +Cc: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 689 bytes --] 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 <cryptocurrencies@quidecco•de> wrote: > 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 the Bitcoins inside the set of > outputs that can still participate. So, any notion which > differentiates with respect to this must make some assumption about > what defines the interest of the Bitcoin nodes as a community. > > Best regards, > > Isidor > [-- Attachment #1.2: Type: text/html, Size: 2124 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 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-15 14:55 ` Isidor Zeuner @ 2014-12-16 12:30 ` Tamas Blummer 2014-12-18 16:23 ` Tamas Blummer 2 siblings, 1 reply; 23+ messages in thread From: Tamas Blummer @ 2014-12-16 12:30 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 4547 bytes --] 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 hight. 4) a side chain block releases x new side coins Since the burn hash does not reveal in advance which side chain it will be used for, the Bitcoin miner can not selectively block burn mining. They will include loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over independent burn miner of the side chain. Anyone who issues a burn transaction that complies the rules 1-3 has 1/m the chance to win the next block on the side chain. This implies a fair exchange rate of n*m satoshis = x side coins (at the margin). Should two burn transactions fulfill the mod m lottery criteria, then we have a competing fork on the side chain. Just as for Bitcoin, the next block(s) will pick the winner. To contain fork rate, the parameter m would have to be adjusted dynamically, similar to Bitcoins difficulty. It needs to increase if fork rate increases and decrease if no valid block is burned with Bitcoin blocks. Unfortunately SPV can only prove the existence of a transaction, but not the non-existence of an alternative. Therefore the fork rate within a block cycle can not be evaluated with SPV proofs. Rational burn miner who frequently faces and loses head-to-head runs with a competing forks would increase his bet for the next burn cycle, as increasing the individual bet amount has the advantage that if he wins his victory is more stable. Remember the side chain trunk is selected as the one with highest cumulative burn. Consequently cumulative burn within an adjustment period (measured in Bitcoin blocks) is expected to rise in face of high fork rate. If the sample period burn exceeds a target, then it would trigger a rise to the lottery criteria m, reducing the fork rate and vs. Tamas Blummer Bits of Proof On Dec 10, 2014, at 8:35 AM, Tamas Blummer <tamas@bitsofproof•com> wrote: > > 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 again an external, real world resource. > > In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them. > > The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance. > > Those who want to mine the side chain will assemble side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain. > > A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. > > 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 not need Bitcoin miner support or even consent. > > Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in. > > The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin. > > Tamas Blummer > Bits of Proof > > 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd [-- Attachment #1.2: Type: text/html, Size: 5871 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-16 12:30 ` Tamas Blummer @ 2014-12-18 16:23 ` Tamas Blummer 0 siblings, 0 replies; 23+ messages in thread From: Tamas Blummer @ 2014-12-18 16:23 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 5530 bytes --] 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 chain. The side chain could use work for regular blocks and a much higher “difficulty” parent chain burn lottery for less frequent “checkpoints". Eg. the side chain difficulty of 1/n of Bitcoin is attainable for a small side chain miner community to advance its chain at Bitcoin’s speed. Simultaneously the block candidates would be submitted to a Bitcoin burn lottery with 1/n odds, so the security of the side chain roughly equals that of Bitcoin at every successful burn mined checkpoint. Tamas Blummer Bits of Proof On Dec 16, 2014, at 1:30 PM, Tamas Blummer <tamas@bitsofproof•com> wrote: > 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 hight. > 4) a side chain block releases x new side coins > > Since the burn hash does not reveal in advance which side chain it will be used for, the Bitcoin miner can not selectively block burn mining. They will include loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over independent burn miner of the side chain. > > Anyone who issues a burn transaction that complies the rules 1-3 has 1/m the chance to win the next block on the side chain. This implies a fair exchange rate of n*m satoshis = x side coins (at the margin). > > Should two burn transactions fulfill the mod m lottery criteria, then we have a competing fork on the side chain. Just as for Bitcoin, the next block(s) will pick the winner. > > To contain fork rate, the parameter m would have to be adjusted dynamically, similar to Bitcoins difficulty. It needs to increase if fork rate increases and decrease if no valid block is burned with Bitcoin blocks. Unfortunately SPV can only prove the existence of a transaction, but not the non-existence of an alternative. Therefore the fork rate within a block cycle can not be evaluated with SPV proofs. > > Rational burn miner who frequently faces and loses head-to-head runs with a competing forks would increase his bet for the next burn cycle, as increasing the individual bet amount has the advantage that if he wins his victory is more stable. Remember the side chain trunk is selected as the one with highest cumulative burn. > > Consequently cumulative burn within an adjustment period (measured in Bitcoin blocks) is expected to rise in face of high fork rate. If the sample period burn exceeds a target, then it would trigger a rise to the lottery criteria m, reducing the fork rate and vs. > > Tamas Blummer > Bits of Proof > > On Dec 10, 2014, at 8:35 AM, Tamas Blummer <tamas@bitsofproof•com> wrote: > >> >> 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 again an external, real world resource. >> >> In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them. >> >> The side chain block validity rules would require that a transaction on the Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that contains the hash of the block header of the side chain. To also introduce a lottery, the burn transaction’s hash is required to satisfy some function of the block hash it was included in on the Bitcoin block chain. For example modulo m of the burn transaction hash must match modulo m of the block hash, that is not known in advance. >> >> Those who want to mine the side chain will assemble side chain block candidates that comply the rules of the side chain, then a Bitcoin transaction burning to the hash of the block candidate and submit it to the Bitcoin network. Should he burn transaction be included into the Bitcoin block chain and the Bitcoin block’s hash satisfy the lottery criteria, then the block candidate can be submitted to extend the side chain. >> >> A side chain block header sequence would be accepted as side chain trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, that linked blocks have the highest cumulative burn, if compared to alternative sequences. >> >> 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 not need Bitcoin miner support or even consent. >> >> Mining difficulty of the side chain could be adjusted by stepping up the required burn and/or hardening the criteria that links a burn proof transaction with the bitcoin block hash it is included in. >> >> The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin. >> >> Tamas Blummer >> Bits of Proof >> >> 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd > [-- Attachment #1.2: Type: text/html, Size: 7927 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] ACK NACK utACK "Concept ACK" 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:21 ` Wladimir 2014-12-10 15:45 ` Austin Walne 2014-12-10 15:52 ` Jeff Garzik 2014-12-11 12:09 ` [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain Isidor Zeuner 3 siblings, 1 reply; 23+ messages in thread From: Wladimir @ 2014-12-10 8:21 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin Dev On Wed, Dec 10, 2014 at 6:47 AM, Wladimir <laanwj@gmail•com> wrote: > Abbreviations: > > Concept ACK -> agree with the idea and overall direction, but haven't > reviewed the code changes nor tested it > utACK -> reviewed the code changes, but did not put it through any testing > Tested ACK -> reviewed the code changes and verified the functionality/bug fix And there is also NACK, that's an aspecific 'I wouldn't like this merged'. I always explain why in the text. A document on this would be welcome, as it may look like Martian to outsiders. That's been brought up many times before, but no one ever created it. Wladimir ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] ACK NACK utACK "Concept ACK" 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 0 siblings, 1 reply; 23+ messages in thread From: Austin Walne @ 2014-12-10 15:45 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev I've had these same questions myself. I'm happy to write up some documentation this afternoon. I can draft something based on this thread. What other key terminology should be included? > On Dec 10, 2014, at 00:21, Wladimir <laanwj@gmail•com> wrote: > >> On Wed, Dec 10, 2014 at 6:47 AM, Wladimir <laanwj@gmail•com> wrote: >> Abbreviations: >> >> Concept ACK -> agree with the idea and overall direction, but haven't >> reviewed the code changes nor tested it >> utACK -> reviewed the code changes, but did not put it through any testing >> Tested ACK -> reviewed the code changes and verified the functionality/bug fix > > And there is also NACK, that's an aspecific 'I wouldn't like this > merged'. I always explain why in the text. > > A document on this would be welcome, as it may look like Martian to > outsiders. That's been brought up many times before, but no one ever > created it. > > Wladimir > > ------------------------------------------------------------------------------ > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] ACK NACK utACK "Concept ACK" 2014-12-10 15:45 ` Austin Walne @ 2014-12-17 8:44 ` Wladimir 0 siblings, 0 replies; 23+ messages in thread From: Wladimir @ 2014-12-17 8:44 UTC (permalink / raw) To: Austin Walne; +Cc: Bitcoin Dev On Wed, Dec 10, 2014 at 3:45 PM, Austin Walne <austin.walne@gmail•com> wrote: > I've had these same questions myself. I'm happy to write up some documentation this afternoon. I can draft something based on this thread. What other key terminology should be included? Fanquake already started on that (but didn't even mention it here!) https://github.com/bitcoin/bitcoin/pull/5468 Wladimir ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] ACK NACK utACK "Concept ACK" 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:21 ` [Bitcoin-development] ACK NACK utACK "Concept ACK" 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 3 siblings, 1 reply; 23+ messages in thread From: Jeff Garzik @ 2014-12-10 15:52 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 372 bytes --] On Wed, Dec 10, 2014 at 1:47 AM, Wladimir <laanwj@gmail•com> wrote: > Concept ACK -> agree with the idea and overall direction, but haven't > reviewed the code changes nor tested it > Concept ACK -> like the idea; the code may need rewriting (or haven't reviewed). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ [-- Attachment #2: Type: text/html, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] ACK NACK utACK "Concept ACK" 2014-12-10 15:52 ` Jeff Garzik @ 2014-12-16 23:40 ` Btc Drak 0 siblings, 0 replies; 23+ messages in thread From: Btc Drak @ 2014-12-16 23:40 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1293 bytes --] Would someone also clarify the use of "nit" for nitpicking and how it plays in the role of consensus? It seems like it's used for minor complaints/preferences. Drak On Wed, Dec 10, 2014 at 3:52 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > > On Wed, Dec 10, 2014 at 1:47 AM, Wladimir <laanwj@gmail•com> wrote: > >> Concept ACK -> agree with the idea and overall direction, but haven't >> reviewed the code changes nor tested it >> > > Concept ACK -> like the idea; the code may need rewriting (or haven't > reviewed). > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > 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 > > [-- Attachment #2: Type: text/html, Size: 2541 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-10 6:47 ` Wladimir ` (2 preceding siblings ...) 2014-12-10 15:52 ` Jeff Garzik @ 2014-12-11 12:09 ` Isidor Zeuner 2014-12-11 14:56 ` Tamas Blummer 3 siblings, 1 reply; 23+ messages in thread From: Isidor Zeuner @ 2014-12-11 12:09 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev [...] > 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 not need Bitcoin miner support or even consent. > Miners might decide to block all burn transactions, and other nodes might decide to stop relaying them. This may be considered as preferable by all participants who do not want to add more potential for deflation. Best regards, Isidor ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 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 0 siblings, 1 reply; 23+ messages in thread From: Tamas Blummer @ 2014-12-11 14:56 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 291 bytes --] 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 [-- Attachment #1.2: Type: text/html, Size: 1278 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-11 14:56 ` Tamas Blummer @ 2014-12-15 10:21 ` Tamas Blummer 2014-12-15 12:39 ` Peter Todd 0 siblings, 1 reply; 23+ messages in thread From: Tamas Blummer @ 2014-12-15 10:21 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 248 bytes --] 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 [-- Attachment #1.2: Type: text/html, Size: 1243 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-15 10:21 ` Tamas Blummer @ 2014-12-15 12:39 ` Peter Todd 2014-12-15 13:06 ` Tamas Blummer 2015-02-04 13:54 ` Isidor Zeuner 0 siblings, 2 replies; 23+ messages in thread From: Peter Todd @ 2014-12-15 12:39 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-15 12:39 ` Peter Todd @ 2014-12-15 13:06 ` Tamas Blummer 2015-02-04 13:54 ` Isidor Zeuner 1 sibling, 0 replies; 23+ messages in thread From: Tamas Blummer @ 2014-12-15 13:06 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 3539 bytes --] 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 much more resilient to “outspend” attack, since the attacker not only needs to outspend but win the lottery for a reorg. This raises the cost of the attack by magnitudes above the regular miner burn cost. In addition, I suggest the burn transaction to include the Bitcoin block height, thereby disabling re-use of a burn, for a later reorg. Tamas Blummer Bits of Proof On Dec 15, 2014, at 1:39 PM, Peter Todd <pete@petertodd•org> wrote: > 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 #1.2: Type: text/html, Size: 4902 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2014-12-15 12:39 ` Peter Todd 2014-12-15 13:06 ` Tamas Blummer @ 2015-02-04 13:54 ` Isidor Zeuner 2015-02-06 1:34 ` Peter Todd 1 sibling, 1 reply; 23+ messages in thread From: Isidor Zeuner @ 2015-02-04 13:54 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev 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 think that approaches which change the number of coins that can possibly be circulated should be encouraged. So, I like the idea of having the "sacrificed" coins appearing in the mining fees in a future block. But what is meant with OP_DEPTH in this context? From what I read, this operation just manipulates the stack size when evaluating the script, so I don't see how it would affect miner incentives. Best regards, Isidor ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain 2015-02-04 13:54 ` Isidor Zeuner @ 2015-02-06 1:34 ` Peter Todd 0 siblings, 0 replies; 23+ messages in thread From: Peter Todd @ 2015-02-06 1:34 UTC (permalink / raw) To: Isidor Zeuner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1280 bytes --] 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 of maximum clarity with respect to modelling the value of > a Bitcoin, I don't think that approaches which change the number > of coins that can possibly be circulated should be encouraged. > > So, I like the idea of having the "sacrificed" coins appearing in the > mining fees in a future block. But what is meant with OP_DEPTH in this > context? From what I read, this operation just manipulates the stack > size when evaluating the script, so I don't see how it would > affect miner incentives. Oh, where I was saying OP_DEPTH, I was referring to a *hypothetical* opcode; I'd forgotten when I wrote that post that OP_DEPTH is an real opcode. These days I'd suggest you use the (upcoming on BTC/live on Viacoin) OP_CHECKLOCKTIMEVERIFY opcode instead. Pretty simple really: <current blockheight + 1 year worth of blocks> CHECKLOCKTIMEVERIFY -- 'peter'[:-1]@petertodd.org 0000000000000000165ecbd638ec09226f84c34d3d775d34ca5df4abfa8cb57c [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-02-06 1:34 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2014-12-15 13:06 ` Tamas Blummer 2015-02-04 13:54 ` Isidor Zeuner 2015-02-06 1:34 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox