š
Original date posted:2011-12-08
šļø Summary of this message: A proposal to include the hash of the block a transaction wants to appear after, called the basis block, to prevent loss from an attacker's reorganization.
š Original message:Hello,
Another of my crazy ideas:
When a transaction is first broadcast, it should include the hash of the block
it wants to appear after, let's call it's basis block. That block can be
anything the claimer wants; but it allows the miners to add this condition:
the transactions outputs a new transaction claims must be before the new
transaction's basis block.
Consider this block chain fork:
* -- * -- F -- * -- 1 -- 4 -- 5
\
* -- 2 -- 3
Let's say in block 2; I transfer coins from address A to Mt.Gox (or any other
pooled-account online wallet). In block 1 I transfer credit from address A to
address B. In block 3 I transfer credit from Mt.Gox's pool to address B.
The chain at 3 races out first, but eventually the chain at 5 becomes "the
one". If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is
nothing to stop that same withdrawl making it into 4 (since it comes from a
pooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and
must wait for six confirmations of 2 before allowing use of the funds. That
is an inconvenience for all the honest users.
With my proposed change, the Mt.Gox transaction broadcast at 3 would include
"block 2" as its basis block. Therefore that transaction could never make it
into block 4, as no miner will include a transaction based on block 2 in the
block 4 chain.
Mt.Gox is probably not a good example, as they have problems with fiat to deal
with too. However, for other online wallet accounts it would allow faster
acceptance of received funds, since there is no danger of loss should an
attacker arrange a reorganisation.
This basis block would be optional (implied by the input transactions if it
isn't present); and would only need storing for the pending transactions, so
no incompatible change is needed to the block format.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nxā¦7wjrv
2023-06-07 02:42:48
in reply to nevent1qā¦730d
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 02:42:48Event JSON
{
"id": "7ae019a055c3043d7f68f210051a82826e9bda7a11c28d59fbc3ca0706f59481",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686105768,
"kind": 1,
"tags": [
[
"e",
"8f9a003a4e73153be5446636a8273274a636ac7ab0ed2daca54506b59b151886",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2011-12-08\nšļø Summary of this message: A proposal to include the hash of the block a transaction wants to appear after, called the basis block, to prevent loss from an attacker's reorganization.\nš Original message:Hello,\n\nAnother of my crazy ideas:\n\nWhen a transaction is first broadcast, it should include the hash of the block \nit wants to appear after, let's call it's basis block. That block can be \nanything the claimer wants; but it allows the miners to add this condition: \nthe transactions outputs a new transaction claims must be before the new \ntransaction's basis block.\n\nConsider this block chain fork:\n\n * -- * -- F -- * -- 1 -- 4 -- 5\n \\\n * -- 2 -- 3\n\nLet's say in block 2; I transfer coins from address A to Mt.Gox (or any other \npooled-account online wallet). In block 1 I transfer credit from address A to \naddress B. In block 3 I transfer credit from Mt.Gox's pool to address B.\n\nThe chain at 3 races out first, but eventually the chain at 5 becomes \"the \none\". If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is \nnothing to stop that same withdrawl making it into 4 (since it comes from a \npooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and \nmust wait for six confirmations of 2 before allowing use of the funds. That \nis an inconvenience for all the honest users.\n\nWith my proposed change, the Mt.Gox transaction broadcast at 3 would include \n\"block 2\" as its basis block. Therefore that transaction could never make it \ninto block 4, as no miner will include a transaction based on block 2 in the \nblock 4 chain.\n\nMt.Gox is probably not a good example, as they have problems with fiat to deal \nwith too. However, for other online wallet accounts it would allow faster \nacceptance of received funds, since there is no danger of loss should an \nattacker arrange a reorganisation.\n\nThis basis block would be optional (implied by the input transactions if it \nisn't present); and would only need storing for the pending transactions, so \nno incompatible change is needed to the block format.\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "a60b5190927a1648c21326578a544bc78d2f80c0f2adee56dab4eeae6db23c8282bfcaa2b78067ac368c57269e5d5187c92bdd35e0c6c3266f95d21ae5315438"
}