📅 Original date posted:2015-12-30
📝 Original message:Ittay Eyal and I just put together a writeup that we're informally calling
Bitcoin-United for preserving the value of coins following a permanent fork:
http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/
Half of the core idea is to eliminate double-spends (where someone spends a
UTXO on chain A and the same UTXO on chain B, at separate merchants) by
placing transactions from A on chain B, and by taking the intersection of
transactions on chain A and chain B when considering whether a payment has
been received.
The other half of the core idea is to enable minting of new coins and
collection of mining fees on both chains, while preserving the 21M maximum.
This is achieved by creating a one-to-one correspondence between coins on
one chain with coins on the other.
Given the level of the audience here, I'm keeping the description quite
terse. Much more detail and discussion is at the link above, as well as the
assumptions that need to hold for Bitcoin-United.
The high bit is that, with a few modest assumptions, it is possible to
create a cohesive coin in the aftermath of a fork, even if the core devs
are split, and even if one of the forks is (in the worst case) completely
non-cooperative. Bitcoin-United is a trick to create a cohesive coin even
when there is no consensus at the lowest level.
Bitcoin-United opens up a lot of new, mostly game-theoretic questions: what
happens to native clients who prefer A or B? What will happen to the value
of native-A or native-B coins? And so on.
We're actively working on these questions and more, but we wanted to share
the Bitcoin-United idea, mainly to receive feedback, and partly to provide
some hope about future consensus to the community. It turns out that it is
possible to craft consensus at the network level even when there isn't one
at the developer level.
Happy New Year, and may 2016 be united,
- egs & ittay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/4b322fe8/attachment.html>;
Emin Gün Sirer [ARCHIVE] /
npub1k6…xvja6
2023-06-07 17:47:28
in reply to nevent1q…k3dm
Author Public Key
npub1k6906yrdzekdkn23mrskcf6up8s2fypqldhnz9gfc44kwsan02zq5xvja6Published at
2023-06-07 17:47:28Event JSON
{
"id": "0afa22c84f12d5bdd687bfb99688dcedd9df14c7b965a919e7359f9535dd6edb",
"pubkey": "b68afd106d166cdb4d51d8e16c275c09e0a49020fb6f311509c56b6743b37a84",
"created_at": 1686160048,
"kind": 1,
"tags": [
[
"e",
"952f2c3963bbc4e3bc8c1ee62942da7fea09db4c863ca025d9e089b9448e51cb",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-12-30\n📝 Original message:Ittay Eyal and I just put together a writeup that we're informally calling\nBitcoin-United for preserving the value of coins following a permanent fork:\n\n\nhttp://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/\n\nHalf of the core idea is to eliminate double-spends (where someone spends a\nUTXO on chain A and the same UTXO on chain B, at separate merchants) by\nplacing transactions from A on chain B, and by taking the intersection of\ntransactions on chain A and chain B when considering whether a payment has\nbeen received.\n\nThe other half of the core idea is to enable minting of new coins and\ncollection of mining fees on both chains, while preserving the 21M maximum.\nThis is achieved by creating a one-to-one correspondence between coins on\none chain with coins on the other.\n\nGiven the level of the audience here, I'm keeping the description quite\nterse. Much more detail and discussion is at the link above, as well as the\nassumptions that need to hold for Bitcoin-United.\n\nThe high bit is that, with a few modest assumptions, it is possible to\ncreate a cohesive coin in the aftermath of a fork, even if the core devs\nare split, and even if one of the forks is (in the worst case) completely\nnon-cooperative. Bitcoin-United is a trick to create a cohesive coin even\nwhen there is no consensus at the lowest level.\n\nBitcoin-United opens up a lot of new, mostly game-theoretic questions: what\nhappens to native clients who prefer A or B? What will happen to the value\nof native-A or native-B coins? And so on.\n\nWe're actively working on these questions and more, but we wanted to share\nthe Bitcoin-United idea, mainly to receive feedback, and partly to provide\nsome hope about future consensus to the community. It turns out that it is\npossible to craft consensus at the network level even when there isn't one\nat the developer level.\n\nHappy New Year, and may 2016 be united,\n- egs \u0026 ittay\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/4b322fe8/attachment.html\u003e",
"sig": "53e01f54b3d88066c9f8b8c58673f5738ccfa24ecaca2e8f22923d0eb9b3c8ece70009b2f2ff697927d7a4515bf75d6bf8d404962eeca5c37a78ef24cb2d158c"
}