📅 Original date posted:2022-02-10
📝 Original message:
That's not really pinning; painning usually refers to pinning something to
the bottom of the mempool whereas these mechanisms make it easier to
guarantee that progress can be made on confirming the transactions you're
interested in.
Often times in these protocols "the call is coming inside the house". It's
not a third party adding fees we are scared of, it's a direct party to the
protocol!
Sponsors or fee accounts would enable you to ensure the protocol you're
working on makes forward progress. For things like Eltoo the internal
ratchet makes this work well.
Protocols which depend on in mempool replacements before confirmation
already must be happy (should they be secure) with any prior state being
mined. If a third party pays the fee you might even be happier since the
execution wasn't on your dime.
Cheers,
Jeremy
On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> > Happy new years devs,
> >
> > I figured I would share some thoughts for conceptual review that have
> been
> > bouncing around my head as an opportunity to clean up the fee paying
> > semantics in bitcoin "for good". The design space is very wide on the
> > approach I'll share, so below is just a sketch of how it could work which
> > I'm sure could be improved greatly.
> >
> > Transaction fees are an integral part of bitcoin.
> >
> > However, due to quirks of Bitcoin's transaction design, fees are a part
> of
> > the transactions that they occur in.
> >
> > While this works in a "Bitcoin 1.0" world, where all transactions are
> > simple on-chain transfers, real world use of Bitcoin requires support for
> > things like Fee Bumping stuck transactions, DoS resistant Payment
> Channels,
> > and other long lived Smart Contracts that can't predict future fee rates.
> > Having the fees paid in band makes writing these contracts much more
> > difficult as you can't merely express the logic you want for the
> > transaction, but also the fees.
> >
> > Previously, I proposed a special type of transaction called a "Sponsor"
> > which has some special consensus + mempool rules to allow arbitrarily
> > appending fees to a transaction to bump it up in the mempool.
> >
> > As an alternative, we could establish an account system in Bitcoin as an
> > "extension block".
>
> <snip>
>
> > This type of design works really well for channels because the addition
> of
> > fees to e.g. a channel state does not require any sort of pre-planning
> > (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> > design is naturally immune to pinning issues since you could offer to
> pay a
> > fee for any TXID and the number of fee adding offers does not need to be
> > restricted in the same way the descendant transactions would need to be.
>
> So it's important to recognize that fee accounts introduce their own kind
> of
> transaction pinning attacks: third parties would be able to attach
> arbitrary
> fees to any transaction without permission. This isn't necessarily a good
> thing: I don't want third parties to be able to grief my transaction
> engines by
> getting obsolete transactions confirmed in liu of the replacments I
> actually
> want confirmed. Eg a third party could mess up OpenTimestamps calendars at
> relatively low cost by delaying the mining of timestamp txs.
>
> Of course, there's an obvious way to fix this: allow transactions to
> designate
> a pubkey allowed to add further transaction fees if required. Which Bitcoin
> already has in two forms: Replace-by-Fee and Child Pays for Parent.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220210/bfed4525/attachment.html>;
Jeremy Rubin [ARCHIVE] /
npub1xu…fzef0
2023-06-09 13:05:08
in reply to nevent1q…36xh
Author Public Key
npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0Published at
2023-06-09 13:05:08Event JSON
{
"id": "351fe179959767f1cac188da55b1bf976b56b789e276bdf4ed6155fd1e5721e2",
"pubkey": "372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a",
"created_at": 1686315908,
"kind": 1,
"tags": [
[
"e",
"89c09cd12ad867d6d2e1314b947516b47b5e1de41f7e8e55839a0abf57779c80",
"",
"root"
],
[
"e",
"90721c28aad999531869eded42f2af2596dd95006447ac512deb03b77e4a79ae",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-02-10\n📝 Original message:\nThat's not really pinning; painning usually refers to pinning something to\nthe bottom of the mempool whereas these mechanisms make it easier to\nguarantee that progress can be made on confirming the transactions you're\ninterested in.\n\nOften times in these protocols \"the call is coming inside the house\". It's\nnot a third party adding fees we are scared of, it's a direct party to the\nprotocol!\n\nSponsors or fee accounts would enable you to ensure the protocol you're\nworking on makes forward progress. For things like Eltoo the internal\nratchet makes this work well.\n\nProtocols which depend on in mempool replacements before confirmation\nalready must be happy (should they be secure) with any prior state being\nmined. If a third party pays the fee you might even be happier since the\nexecution wasn't on your dime.\n\nCheers,\n\nJeremy\n\nOn Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:\n\u003e \u003e Happy new years devs,\n\u003e \u003e\n\u003e \u003e I figured I would share some thoughts for conceptual review that have\n\u003e been\n\u003e \u003e bouncing around my head as an opportunity to clean up the fee paying\n\u003e \u003e semantics in bitcoin \"for good\". The design space is very wide on the\n\u003e \u003e approach I'll share, so below is just a sketch of how it could work which\n\u003e \u003e I'm sure could be improved greatly.\n\u003e \u003e\n\u003e \u003e Transaction fees are an integral part of bitcoin.\n\u003e \u003e\n\u003e \u003e However, due to quirks of Bitcoin's transaction design, fees are a part\n\u003e of\n\u003e \u003e the transactions that they occur in.\n\u003e \u003e\n\u003e \u003e While this works in a \"Bitcoin 1.0\" world, where all transactions are\n\u003e \u003e simple on-chain transfers, real world use of Bitcoin requires support for\n\u003e \u003e things like Fee Bumping stuck transactions, DoS resistant Payment\n\u003e Channels,\n\u003e \u003e and other long lived Smart Contracts that can't predict future fee rates.\n\u003e \u003e Having the fees paid in band makes writing these contracts much more\n\u003e \u003e difficult as you can't merely express the logic you want for the\n\u003e \u003e transaction, but also the fees.\n\u003e \u003e\n\u003e \u003e Previously, I proposed a special type of transaction called a \"Sponsor\"\n\u003e \u003e which has some special consensus + mempool rules to allow arbitrarily\n\u003e \u003e appending fees to a transaction to bump it up in the mempool.\n\u003e \u003e\n\u003e \u003e As an alternative, we could establish an account system in Bitcoin as an\n\u003e \u003e \"extension block\".\n\u003e\n\u003e \u003csnip\u003e\n\u003e\n\u003e \u003e This type of design works really well for channels because the addition\n\u003e of\n\u003e \u003e fees to e.g. a channel state does not require any sort of pre-planning\n\u003e \u003e (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of\n\u003e \u003e design is naturally immune to pinning issues since you could offer to\n\u003e pay a\n\u003e \u003e fee for any TXID and the number of fee adding offers does not need to be\n\u003e \u003e restricted in the same way the descendant transactions would need to be.\n\u003e\n\u003e So it's important to recognize that fee accounts introduce their own kind\n\u003e of\n\u003e transaction pinning attacks: third parties would be able to attach\n\u003e arbitrary\n\u003e fees to any transaction without permission. This isn't necessarily a good\n\u003e thing: I don't want third parties to be able to grief my transaction\n\u003e engines by\n\u003e getting obsolete transactions confirmed in liu of the replacments I\n\u003e actually\n\u003e want confirmed. Eg a third party could mess up OpenTimestamps calendars at\n\u003e relatively low cost by delaying the mining of timestamp txs.\n\u003e\n\u003e Of course, there's an obvious way to fix this: allow transactions to\n\u003e designate\n\u003e a pubkey allowed to add further transaction fees if required. Which Bitcoin\n\u003e already has in two forms: Replace-by-Fee and Child Pays for Parent.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220210/bfed4525/attachment.html\u003e",
"sig": "9ed1f1dd67f190ad0382c0363f83abc1966a3428373992b37ccc35d1f0af1ba50000fa168a880a28540631acc0b9b00ff7c7b83971bf3ffa955fe29b2bbd7fcb"
}