đź“… Original date posted:2018-09-06
đź“ť Original message:Humour me please,
Where you say "create transactions which are only valid if they are mined on top of a specific block." - in practice, does that usually means at any height above a specific block?
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Ruben Somsen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Sunday, 2 September 2018 3:26:54 AM
To: bitcoin-dev at lists.linuxfoundation.org
Subject: [bitcoin-dev] Guiding transaction fees towards a more censorship resistant outcome
When a user creates a transaction with a fee attached, they are
incentivizing miners to add this transaction to the blockchain. The
task is usually not very specific -- as long as it ends up in a valid
chain with the most Proof-of-Work, miners get paid. The payment is an
incentive for miners to act in the way that users desire.
To the user, there’s an individual benefit: their transaction gets
added. To the network, there’s a shared benefit: all fees add to the
security of other transactions in the chain. Miners can choose to
ignore the incentives, but they would be leaving money on the table
(and eventually get replaced by more competitive miners).
Transactions from Bitcoin Core are slightly more specific about what
they ask miners to do. Every transaction is only valid at a block
height that is one higher than the last block. This incentivizes
miners to build on top of the last block, instead of going back and
reorganizing the blockchain. This is especially important in a future
scenario where the fee reward is larger than the block reward.
BIP 115* by Luke-jr is even more specific. It enables users to create
transactions which are only valid if they are mined on top of a
specific block. While originally designed as a form of replay
protection, it actually serves as a deterrent for miners to reorganize
the blockchain. If they orphan a block, it will invalidate
transactions that demanded the inclusion of the orphaned block. This
increases the cost of intentionally reorganizing the blockchain.
Coinjoin**, the act of combining payments of multiple users into a
single transaction, can be seen as yet another method for users to be
more specific. The fate of their payments are now intertwined with
that of others. If miners wish to censor a single payment, they have
to reject the entire transaction, and the associated fee amount.
Techniques like mimblewimble simplify this process, by making coinjoin
non-interactive.
This brings us to a theoretical scenario where:
- every block contains only a single coinjoin transaction
- the validity of this transaction depends on the inclusion of a
specific previous block
- the block reward is negligible compared to transaction fees
In this scenario, if miners wish to undo a specific transaction that
happened two blocks ago, they would have to create three empty blocks
(receiving negligible compensation) in order to overtake the longest
chain. And even then, users can still refuse to let their new
transactions be mined on top of the empty blocks, disincentivizing
such behavior completely.
While not easy to achieve in practice (e.g. resolving natural forks
becomes more complicated), it demonstrates that users can become more
empowered than they are today, benefitting censorship resistance***.
It is this line of thinking that I wish to convey. Perhaps it may
inspire further ideas in this direction.
-- Ruben Somsen
* BIP 115: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbitcoin%2Fbips%2Fblob%2Fmaster%2Fbip-0115.mediawiki&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=req4KYOcztXLAG%2Fu4RrmhLREGBF28JNTe45pO86kRd4%3D&reserved=0
** Coinjoin: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitcointalk.org%2Findex.php%3Ftopic%3D279249.0&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=d%2B06jxrKubWhLwoInFEgo8eHvI9f1j74QN8WH7xrVos%3D&reserved=0
*** Risk sharing principle:
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibbitcoin%2Flibbitcoin%2Fwiki%2FRisk-Sharing-Principle&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=NA3HxqI5PnuyaI9hyCaw0rcaFsrhD%2FXQB8biWJXej8g%3D&reserved=0
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-dev&data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&sdata=9P7UetPmKWngjgjNPE0%2BAMgdzuL2DgqBLoLti82f23M%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180906/43a9fa13/attachment.html>;
Damian Williamson [ARCHIVE] /
npub1sp…8lz2h
2023-06-07 18:14:26
in reply to nevent1q…ydpc
Author Public Key
npub1spe4rkz350zpn7h2pz07t8sdwgt440zmx9k530afwj6gmq7q0lksh8lz2hPublished at
2023-06-07 18:14:26Event JSON
{
"id": "bbc28b9b4140d4d0018165da6de0f14cfd233ccf62174e752aae5936c45400dd",
"pubkey": "807351d851a3c419faea089fe59e0d72175abc5b316d48bfa974b48d83c07fed",
"created_at": 1686161666,
"kind": 1,
"tags": [
[
"e",
"b1b8d6a636632f332d8cfbd297f72dc31d3a0d9195af550294df2fc650ebeade",
"",
"root"
],
[
"e",
"e7dd6970ef39ff134b30a4a673e6d76e81ae8d00ddb5bac2d906a21e6c666708",
"",
"reply"
],
[
"p",
"c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0"
]
],
"content": "📅 Original date posted:2018-09-06\n📝 Original message:Humour me please,\n\n\nWhere you say \"create transactions which are only valid if they are mined on top of a specific block.\" - in practice, does that usually means at any height above a specific block?\n\n________________________________\nFrom: bitcoin-dev-bounces at lists.linuxfoundation.org \u003cbitcoin-dev-bounces at lists.linuxfoundation.org\u003e on behalf of Ruben Somsen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSent: Sunday, 2 September 2018 3:26:54 AM\nTo: bitcoin-dev at lists.linuxfoundation.org\nSubject: [bitcoin-dev] Guiding transaction fees towards a more censorship resistant outcome\n\nWhen a user creates a transaction with a fee attached, they are\nincentivizing miners to add this transaction to the blockchain. The\ntask is usually not very specific -- as long as it ends up in a valid\nchain with the most Proof-of-Work, miners get paid. The payment is an\nincentive for miners to act in the way that users desire.\n\nTo the user, there’s an individual benefit: their transaction gets\nadded. To the network, there’s a shared benefit: all fees add to the\nsecurity of other transactions in the chain. Miners can choose to\nignore the incentives, but they would be leaving money on the table\n(and eventually get replaced by more competitive miners).\n\nTransactions from Bitcoin Core are slightly more specific about what\nthey ask miners to do. Every transaction is only valid at a block\nheight that is one higher than the last block. This incentivizes\nminers to build on top of the last block, instead of going back and\nreorganizing the blockchain. This is especially important in a future\nscenario where the fee reward is larger than the block reward.\n\nBIP 115* by Luke-jr is even more specific. It enables users to create\ntransactions which are only valid if they are mined on top of a\nspecific block. While originally designed as a form of replay\nprotection, it actually serves as a deterrent for miners to reorganize\nthe blockchain. If they orphan a block, it will invalidate\ntransactions that demanded the inclusion of the orphaned block. This\nincreases the cost of intentionally reorganizing the blockchain.\n\nCoinjoin**, the act of combining payments of multiple users into a\nsingle transaction, can be seen as yet another method for users to be\nmore specific. The fate of their payments are now intertwined with\nthat of others. If miners wish to censor a single payment, they have\nto reject the entire transaction, and the associated fee amount.\nTechniques like mimblewimble simplify this process, by making coinjoin\nnon-interactive.\n\nThis brings us to a theoretical scenario where:\n\n- every block contains only a single coinjoin transaction\n- the validity of this transaction depends on the inclusion of a\nspecific previous block\n- the block reward is negligible compared to transaction fees\n\nIn this scenario, if miners wish to undo a specific transaction that\nhappened two blocks ago, they would have to create three empty blocks\n(receiving negligible compensation) in order to overtake the longest\nchain. And even then, users can still refuse to let their new\ntransactions be mined on top of the empty blocks, disincentivizing\nsuch behavior completely.\n\nWhile not easy to achieve in practice (e.g. resolving natural forks\nbecomes more complicated), it demonstrates that users can become more\nempowered than they are today, benefitting censorship resistance***.\nIt is this line of thinking that I wish to convey. Perhaps it may\ninspire further ideas in this direction.\n\n-- Ruben Somsen\n\n\n* BIP 115: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbitcoin%2Fbips%2Fblob%2Fmaster%2Fbip-0115.mediawiki\u0026amp;data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019\u0026amp;sdata=req4KYOcztXLAG%2Fu4RrmhLREGBF28JNTe45pO86kRd4%3D\u0026amp;reserved=0\n\n** Coinjoin: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitcointalk.org%2Findex.php%3Ftopic%3D279249.0\u0026amp;data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019\u0026amp;sdata=d%2B06jxrKubWhLwoInFEgo8eHvI9f1j74QN8WH7xrVos%3D\u0026amp;reserved=0\n\n*** Risk sharing principle:\nhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibbitcoin%2Flibbitcoin%2Fwiki%2FRisk-Sharing-Principle\u0026amp;data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019\u0026amp;sdata=NA3HxqI5PnuyaI9hyCaw0rcaFsrhD%2FXQB8biWJXej8g%3D\u0026amp;reserved=0\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-dev\u0026amp;data=02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636716143839246019\u0026amp;sdata=9P7UetPmKWngjgjNPE0%2BAMgdzuL2DgqBLoLti82f23M%3D\u0026amp;reserved=0\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180906/43a9fa13/attachment.html\u003e",
"sig": "439f76e8d10d543f93beda628cf01f8294ac1a18e331488dedd644ca19aa13f3ab7e862209cff222e6cea4260c0f8c8bc61a8bce2f39977d0d86197ea26e84ba"
}