📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015-06-19 17:50, Jeff Garzik wrote:
> No. You cannot know which is the 'right' or wrong transaction. One tx
> has
> obvious nSequence adjustments, the other - the refund transaction - may
> not.
I'm still not seeing a case where a node could see conflicting
transactions on the network as part of a micropayment channel, and not
know it was observing the resolution of a channel rather than a likely
retail double spend.
If both transactions have been broadcast, then one of the conflicting
members of the set will have nSequence adjustments.
Maybe a clever griefer could try to make their retail double spend look
like a micropayment channel, but it seems like they'd be missing the
other identifiable markers of that protocol.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVhFhqAAoJECpf2nDq2eYjWtgP/2ir11TUfxoIIzK9t0groKY3
yMR32HP3caDLKdc5ML41jf0l0cp7a54sFPuRE+Am8rkg9ogcf6fho/hCwLnhhNb4
YYBqJ2pzqCU1uN8jwPYSwSw3AO+F+hPE8gcm7lKD297a1k9xpYayAFjChJowoyNT
Wuq9YDkakQeSjV1aCiRHuXNxqnnbymf9xHEiB0buVnSgnyXrgZNCnefAo8DeXYqi
FTSceakNwdkklddK5ObNNK9ZoLpjHhX6hZwRiXsOoG+WUzXhLQ+BsyIFzsCKxQk1
cXjTvLn+Ub9FasRCK5KXMBkkPa1U5JLs1nTn6eTbPyroTs10WLkXWjIpZHrkf7ZW
9RsxoKIRaJur8gbYd6BMvV5rgkfGdb6j24pVNxFF2t89SLo44H0NvqE6koNzgubG
4DyXZ+UlzxzwRVBNDeF4pdlKZGsz2ycvQPuNHRoaZY2IsieMBN/5HEqGNOmXsvKf
tCg1SInO/FkE4njCxSW0R31s2KXCpgVCuq3qmoIKZobDdx7AC8GnpY1rdxUGpVoy
USJwZ2IOgtNfl/rBtOpkp/BaUCmCYOiUj13/ycDrqWvnM4TmiDdzJNEZNfez5UQp
Uvgvstoo88sewv9hGsuBWX0nC+ze/m43ZRReFhQDsypEaOw6pL2LSG9dD3tzulax
TrbPXPlN55NarQ3nmPIW
=Hj0x
-----END PGP SIGNATURE-----
justusranvier at riseup.net [ARCHIVE] /
npub1qf…lfn9a
2023-06-07 15:39:14
in reply to nevent1q…u2uw
Author Public Key
npub1qf6k0f8p0h89d43l0vnx2xp5yrfgjyl8tg3hkg8jtyudrllgw2usdlfn9aPublished at
2023-06-07 15:39:14Event JSON
{
"id": "f403f824c0a2f8892f60e216218224d172bc7b6dd9b80cbf586bf0938e863a06",
"pubkey": "027567a4e17dce56d63f7b2665183420d28913e75a237b20f25938d1ffe872b9",
"created_at": 1686152354,
"kind": 1,
"tags": [
[
"e",
"6b4025f674cbd304cabd44490b09b3ceb927f752f6a9f4513b25fefc95bdc008",
"",
"root"
],
[
"e",
"322a7360d7299e5d4aa9c4920532eae74fa17de5d4de54c319a4db5f751e8313",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-06-19\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nOn 2015-06-19 17:50, Jeff Garzik wrote:\n\u003e No. You cannot know which is the 'right' or wrong transaction. One tx \n\u003e has\n\u003e obvious nSequence adjustments, the other - the refund transaction - may \n\u003e not.\n\nI'm still not seeing a case where a node could see conflicting \ntransactions on the network as part of a micropayment channel, and not \nknow it was observing the resolution of a channel rather than a likely \nretail double spend.\n\nIf both transactions have been broadcast, then one of the conflicting \nmembers of the set will have nSequence adjustments.\n\nMaybe a clever griefer could try to make their retail double spend look \nlike a micropayment channel, but it seems like they'd be missing the \nother identifiable markers of that protocol.\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2\n\niQIcBAEBCgAGBQJVhFhqAAoJECpf2nDq2eYjWtgP/2ir11TUfxoIIzK9t0groKY3\nyMR32HP3caDLKdc5ML41jf0l0cp7a54sFPuRE+Am8rkg9ogcf6fho/hCwLnhhNb4\nYYBqJ2pzqCU1uN8jwPYSwSw3AO+F+hPE8gcm7lKD297a1k9xpYayAFjChJowoyNT\nWuq9YDkakQeSjV1aCiRHuXNxqnnbymf9xHEiB0buVnSgnyXrgZNCnefAo8DeXYqi\nFTSceakNwdkklddK5ObNNK9ZoLpjHhX6hZwRiXsOoG+WUzXhLQ+BsyIFzsCKxQk1\ncXjTvLn+Ub9FasRCK5KXMBkkPa1U5JLs1nTn6eTbPyroTs10WLkXWjIpZHrkf7ZW\n9RsxoKIRaJur8gbYd6BMvV5rgkfGdb6j24pVNxFF2t89SLo44H0NvqE6koNzgubG\n4DyXZ+UlzxzwRVBNDeF4pdlKZGsz2ycvQPuNHRoaZY2IsieMBN/5HEqGNOmXsvKf\ntCg1SInO/FkE4njCxSW0R31s2KXCpgVCuq3qmoIKZobDdx7AC8GnpY1rdxUGpVoy\nUSJwZ2IOgtNfl/rBtOpkp/BaUCmCYOiUj13/ycDrqWvnM4TmiDdzJNEZNfez5UQp\nUvgvstoo88sewv9hGsuBWX0nC+ze/m43ZRReFhQDsypEaOw6pL2LSG9dD3tzulax\nTrbPXPlN55NarQ3nmPIW\n=Hj0x\n-----END PGP SIGNATURE-----",
"sig": "c4594bf39e8ce763134cadc76127cf8b067a4de3963c8b664c606e33418f75887b1d09ec17e8a1c7068c9c16721b743cc17cb6731fc93f40389ccde932a3176e"
}