đź“… Original date posted:2014-08-05
đź“ť Original message:>
> A distinction there is that they can only become invalid via a
> conflict— replaced by another transaction authored by the prior
> signers. If no other transaction could be created (e.g. you're a
> multisigner and won't sign it again) then there is no such risk.
You need to check transaction's dependencies up to a certain depth to know
whether it is safe:
If one of inputs depends on transaction which is signed by parties with
unknown trustworthiness, then it isn't safe.
> It now introduces chance events ("act of god") into the mix where they
> they didn't exist before.
You need to check transaction's dependencies up to a certain depth to know
whether it is safe:
If one of inputs depends on transaction time-locked script (or other
unrecognized script), then it isn't safe.
Situation is identical, you might need several extra lines of code.
I think it would matter only if we had deterministic, reliable mempool and
reorganization behavior. But it's not something we can depend on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/bd7de220/attachment.html>;
Alex Mizrahi [ARCHIVE] /
npub1sw…pul5t
2023-06-07 15:24:40
in reply to nevent1q…99a3
Author Public Key
npub1swfeusu3ua9trup00qcnrgc2yndksyvgku4epk5tec7u4fmrez6qxpul5tPublished at
2023-06-07 15:24:40Event JSON
{
"id": "61c7de1bd1c14dd0d05c097c51892dd7ae5d398416523053b9d6b2487df66623",
"pubkey": "83939e4391e74ab1f02f783131a30a24db681188b72b90da8bce3dcaa763c8b4",
"created_at": 1686151480,
"kind": 1,
"tags": [
[
"e",
"862ea3dc96b72bff70fc377e79d0d6efd56d14bf0babb9aa995ab55fc1b92d18",
"",
"root"
],
[
"e",
"1248296fbf7365bc9442e000a9aeed05bf113cff49386702263faf8dec185edb",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-08-05\n📝 Original message:\u003e\n\u003e A distinction there is that they can only become invalid via a\n\u003e conflict— replaced by another transaction authored by the prior\n\u003e signers. If no other transaction could be created (e.g. you're a\n\u003e multisigner and won't sign it again) then there is no such risk.\n\n\nYou need to check transaction's dependencies up to a certain depth to know\nwhether it is safe:\n If one of inputs depends on transaction which is signed by parties with\nunknown trustworthiness, then it isn't safe.\n\n\n\u003e It now introduces chance events (\"act of god\") into the mix where they\n\u003e they didn't exist before.\n\n\nYou need to check transaction's dependencies up to a certain depth to know\nwhether it is safe:\n If one of inputs depends on transaction time-locked script (or other\nunrecognized script), then it isn't safe.\n\nSituation is identical, you might need several extra lines of code.\n\nI think it would matter only if we had deterministic, reliable mempool and\nreorganization behavior. But it's not something we can depend on.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/bd7de220/attachment.html\u003e",
"sig": "f7d88f472ea543190d84a079af70bc959a9b5be825cef4c806e1e3b80201c280c560477b6c0aaae37294a8cd5488db12866e30ef8dbfbf52090c4bdd4a1c6b84"
}