đź“… Original date posted:2014-12-10
đź“ť Original message: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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141210/ed5fdc7d/attachment.html>;
patrick [ARCHIVE] /
npub1yj…ea069
2023-06-07 15:27:46
in reply to nevent1q…nrd9
Author Public Key
npub1yj4zu4pmn877chyt065fusvv62hndefzkkppqfvx5uxddnh55zpsfea069Published at
2023-06-07 15:27:46Event JSON
{
"id": "766615c973ce548e7b856252959615437f67b3f0b5db075aabdd2cc405c67350",
"pubkey": "24aa2e543b99fdec5c8b7ea89e418cd2af36e522b582102586a70cd6cef4a083",
"created_at": 1686151666,
"kind": 1,
"tags": [
[
"e",
"5d621269893f2dbd63283c3fef2b564d88f9f6005bf2c1f19d78db6deffd407b",
"",
"root"
],
[
"e",
"0d5e1e59b169e9dd621191cd217193b2718e8ba5085a7f5bbf0d4732de9a7775",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 Original date posted:2014-12-10\n📝 Original message:The goal is to have an opportunity cost to breaking the rules.\n\nProof of Burn is a real cost for following the rules.\n\nOn 12/10/2014 01:35 AM, Tamas Blummer wrote:\n\u003e 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. \n\u003e\n\u003e In following I outline a new mining algorithm for side chains, that burn Bitcoins to secure them.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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. \n\u003e\n\u003e 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.\n\u003e\n\u003e 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.\n\u003e\n\u003e The difficulty to mine with burn would be dynamic and would also imply a floating exchange rate between Bitcoin and the side coin.\n\u003e\n\u003e Tamas Blummer\n\u003e Bits of Proof\n\u003e\n\u003e 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server\n\u003e from Actuate! Instantly Supercharge Your Business Reports and Dashboards\n\u003e with Interactivity, Sharing, Native Excel Exports, App Integration \u0026 more\n\u003e Get technology previously reserved for billion-dollar corporations, FREE\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=164703151\u0026iu=/4140/ostg.clktrk\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141210/ed5fdc7d/attachment.html\u003e",
"sig": "8ba3232cdb3b017d5d953c789067b79e12d9b5e096adc9ef73757b79aa84473cfe40b200e97ab383f242e918b839e62454ae5859d26be6e255a672480ed3ae1b"
}