Prayank [ARCHIVE] on Nostr: š
Original date posted:2022-02-01 š Original message:Hi Bastein, > This work ...
š
Original date posted:2022-02-01
š Original message:Hi Bastein,
> This work will highly improve the security of any multi-party contract trying to build on top of bitcoin
Do you think such multi party contracts are vulnerable by design considering they rely on policy that cannot be enforced?
> For starters, let me quickly explain why the current rules are hard to work with in the context of lightning
Using the term 'rules' can be confusing sometimes because it's just a policy and different from consensus rules. I wish we could change this in the BIP with something else.
> I'm actually paying a high fee twice instead of once (and needlessly using on-chain space, our scarcest asset, because we could have avoided that additional transaction
Not sure I understand this part because if a transaction is on-chain it can't be replaced.Ā
> The second biggest pain point is rule 3. It prevents me from efficiently using my capital while it's unconfirmed
> I'm curious to hear other people's thoughts on that. If it makes sense, I would propose the following very simple rules
Looks interesting however not sure about X and Y.
--
Prayank
A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/48931d6d/attachment-0001.html>
Published at
2023-06-07 23:03:11Event JSON
{
"id": "4ff545a224ecadc3391ca6620366c64ba25ef2e2680aeb9ca294ea5be58268fd",
"pubkey": "339a4dd213c9ce6fb7143bcbd13868ec03a78b2af67b0465c7cf83164bc01fa1",
"created_at": 1686178991,
"kind": 1,
"tags": [
[
"e",
"71aa4103a9ee18292e86ffa3579e1f8f9dd5d48d8a9656c877d724e3219f53f4",
"",
"root"
],
[
"e",
"92a0feb9205b0f719ed8b7395b904736e00db02e78c2f8dd67c3bd4f43778479",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "š
Original date posted:2022-02-01\nš Original message:Hi Bastein,\n\n\u003e This work will highly improve the security of any multi-party contract trying to build on top of bitcoin\nDo you think such multi party contracts are vulnerable by design considering they rely on policy that cannot be enforced?\n\n\u003e For starters, let me quickly explain why the current rules are hard to work with in the context of lightning\nUsing the term 'rules' can be confusing sometimes because it's just a policy and different from consensus rules. I wish we could change this in the BIP with something else.\n\n\u003e I'm actually paying a high fee twice instead of once (and needlessly using on-chain space, our scarcest asset, because we could have avoided that additional transaction\nNot sure I understand this part because if a transaction is on-chain it can't be replaced.Ā \n\n\u003e The second biggest pain point is rule 3. It prevents me from efficiently using my capital while it's unconfirmed\n\u003e I'm curious to hear other people's thoughts on that. If it makes sense, I would propose the following very simple rules\nLooks interesting however not sure about X and Y.\n\n-- \nPrayank\n\nA3B1 E430 2298 178F\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/48931d6d/attachment-0001.html\u003e",
"sig": "aa5965a7bfb515348b63a390f6e499e13a5775997d6004d782575e90d08d08c38a7769c803f9d0cf335f11691df31d52580554b4f0358f6a72033ec60e772936"
}