jl2012 [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-20 📝 Original message:Rusty Russell via ...
📅 Original date posted:2015-12-20
📝 Original message:Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到:
> Jonathan Toomim via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> writes:
>> 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.
>
> Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160
> <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" scriptSig. The SegWit-usable
> outputs will (have to) look different, won't they?
>
> Cheers,
> Rusty.
I think he means Mallory is paying with an invalid Segwit input, not
output (there is no "invalid output" anyway). However, this is not a
issue if Bob waits for a few confirmations.
Published at
2023-06-07 17:46:49Event JSON
{
"id": "0f2aad68c171f3d44a87108963f0e9fd1cac95c37ac7245c141164ebc9689377",
"pubkey": "ab1c85bd5ad443631a95b228bd1630bf7acdb27f6de01a960ccfbb077831d7ec",
"created_at": 1686160009,
"kind": 1,
"tags": [
[
"e",
"98cf2e35838fa134ae6f1ae02856ea7c4d6d5aae2f9a5a6272379073f8e32519",
"",
"root"
],
[
"e",
"a5b27efaa620a95544c049ee4fee7991ece5d366ca9ee7be39318de7f1b234e5",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-12-20\n📝 Original message:Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到:\n\u003e Jonathan Toomim via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e writes:\n\u003e\u003e On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev \n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e\u003e 1) The risk of an old full node wallet accepting a transaction that \n\u003e\u003e\u003e is\n\u003e\u003e\u003e invalid to the new rules.\n\u003e\u003e\u003e \n\u003e\u003e\u003e The receiver wallet chooses what address/script to accept coins on.\n\u003e\u003e\u003e They'll upgrade to the new softfork rules before creating an address\n\u003e\u003e\u003e that depends on the softfork's features.\n\u003e\u003e\u003e \n\u003e\u003e\u003e So, not a problem.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob\n\u003e\u003e runs the old rules. Bob creates a p2pkh address for Mallory to\n\u003e\u003e use. Mallory takes 1 BTC, and creates an invalid SegWit transaction\n\u003e\u003e that Bob cannot properly validate and that pays into one of Mallory's\n\u003e\u003e wallets. Mallory then immediately spends the unconfirmed transaction\n\u003e\u003e into Bob's address. Bob sees what appears to be a valid transaction\n\u003e\u003e chain which is not actually valid.\n\u003e \n\u003e Pretty sure Bob's wallet will be looking for \"OP_DUP OP_HASH160\n\u003e \u003cpubKeyHash\u003e OP_EQUALVERIFY OP_CHECKSIG\" scriptSig. The SegWit-usable\n\u003e outputs will (have to) look different, won't they?\n\u003e \n\u003e Cheers,\n\u003e Rusty.\n\nI think he means Mallory is paying with an invalid Segwit input, not \noutput (there is no \"invalid output\" anyway). However, this is not a \nissue if Bob waits for a few confirmations.",
"sig": "6062dcf253ae6b5eecef8642b0f1d8fcacdfb19d5594f39f98d291c60d9b880fd6d54cda5bc8eecb9b5bd0f009014b076f4c0dbdd22972568e28691b34dbd922"
}