📅 Original date posted:2015-12-18
📝 Original message:On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 1) The risk of an old full node wallet accepting a transaction that is
> invalid to the new rules.
>
> The receiver wallet chooses what address/script to accept coins on.
> They'll upgrade to the new softfork rules before creating an address
> that depends on the softfork's features.
>
> So, not a problem.
Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob runs the old rules. Bob creates a p2pkh address for Mallory to use. Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob cannot properly validate and that pays into one of Mallory's wallets. Mallory then immediately spends the unconfirmed transaction into Bob's address. Bob sees what appears to be a valid transaction chain which is not actually valid.
Clueless Carol is one of the 4.9% of miners who forgot to upgrade her mining node. Carol sees that Mallory included an enormous fee in his transactions, so Carol makes sure to include both transactions in her block.
Mallory gets free beer.
Anything I'm missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/4389e72a/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/4389e72a/attachment-0001.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 17:46:45
in reply to nevent1q…z23u
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 17:46:45Event JSON
{
"id": "c850edd94e1d0665e3adbff61d2729124c34ccf5286863b8817a583b68078368",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686160005,
"kind": 1,
"tags": [
[
"e",
"98cf2e35838fa134ae6f1ae02856ea7c4d6d5aae2f9a5a6272379073f8e32519",
"",
"root"
],
[
"e",
"8a0a3c6dc449558262b25ecbfcd42e2b2d3084622f277cbed3495c387537c5eb",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2015-12-18\n📝 Original message:On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e 1) The risk of an old full node wallet accepting a transaction that is\n\u003e invalid to the new rules.\n\u003e \n\u003e The receiver wallet chooses what address/script to accept coins on.\n\u003e They'll upgrade to the new softfork rules before creating an address\n\u003e that depends on the softfork's features.\n\u003e \n\u003e So, not a problem.\n\n\nMallory wants to defraud Bob with a 1 BTC payment for some beer. Bob runs the old rules. Bob creates a p2pkh address for Mallory to use. Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob cannot properly validate and that pays into one of Mallory's wallets. Mallory then immediately spends the unconfirmed transaction into Bob's address. Bob sees what appears to be a valid transaction chain which is not actually valid.\n\nClueless Carol is one of the 4.9% of miners who forgot to upgrade her mining node. Carol sees that Mallory included an enormous fee in his transactions, so Carol makes sure to include both transactions in her block.\n\nMallory gets free beer.\n\nAnything I'm missing?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/4389e72a/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/4389e72a/attachment-0001.sig\u003e",
"sig": "0e7b6243186bb627fcf79ad9be38bdb44acfc6afae67cf0f313829bf9c49502cd1c7089a70961053e19528bd0aed90d95c9fa25b41d9b37506adcdc1d7621a01"
}