📅 Original date posted:2015-06-16
📝 Original message:Jorge Timón <jtimon at jtimon.cc> writes:
> On Jun 15, 2015 11:43 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
>
>> Though Peter Todd's more general best-effort language might make more
>> sense. It's not like you can hide an OP_RETURN transaction to make it
>> look like something else, so that transaction not going to be
>> distinguished by non-canonical ordering.
>
> What about commitments that don't use op_return (ie pay2contract
> commitments)?
I have no idea what they are? :)
> In any case, if the motivation is ordering in multi-party transactions
> there should be ways to do it without any consequences for other
> transaction types' privacy. For example you could have a deterministic
> method that depends on a random seed all parties in the transaction
> previously share. That way the ordering is deterministic for all parties
> involved in the transaction (which can use whatever channel they're using
> to send the parts to also send this random seed) while at the same time the
> order looks random (or at least not cannonical in a recognisable way) to
> everyone else.
Yes, my plan B would be an informational bip with simple code,
suggesting a way to permute a transaction based on some secret. No
point everyone reinventing the wheel, badly.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 15:36:45
in reply to nevent1q…5dsx
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 15:36:45Event JSON
{
"id": "f6b8f480395dc12a3405abd4505030567b84ceb67a6c8b6e4a8946c500649d1c",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686152205,
"kind": 1,
"tags": [
[
"e",
"981f41da2a008fa33b1384e8dd3f0d4a96b7f3bed5c463f00f9032a495226e9c",
"",
"root"
],
[
"e",
"bc7d942b65f3fb581efa204acbfab7a2295c99637d9298e200e9a3b6e4c6a650",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-06-16\n📝 Original message:Jorge Timón \u003cjtimon at jtimon.cc\u003e writes:\n\u003e On Jun 15, 2015 11:43 PM, \"Rusty Russell\" \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\n\u003e\u003e Though Peter Todd's more general best-effort language might make more\n\u003e\u003e sense. It's not like you can hide an OP_RETURN transaction to make it\n\u003e\u003e look like something else, so that transaction not going to be\n\u003e\u003e distinguished by non-canonical ordering.\n\u003e\n\u003e What about commitments that don't use op_return (ie pay2contract\n\u003e commitments)?\n\nI have no idea what they are? :)\n\n\u003e In any case, if the motivation is ordering in multi-party transactions\n\u003e there should be ways to do it without any consequences for other\n\u003e transaction types' privacy. For example you could have a deterministic\n\u003e method that depends on a random seed all parties in the transaction\n\u003e previously share. That way the ordering is deterministic for all parties\n\u003e involved in the transaction (which can use whatever channel they're using\n\u003e to send the parts to also send this random seed) while at the same time the\n\u003e order looks random (or at least not cannonical in a recognisable way) to\n\u003e everyone else.\n\nYes, my plan B would be an informational bip with simple code,\nsuggesting a way to permute a transaction based on some secret. No\npoint everyone reinventing the wheel, badly.\n\nCheers,\nRusty.",
"sig": "97a9e05a3eb3896018a96245dc228df442d0d9f5f421bf472802d7d4f7a08ee7ba15bee811e90dbedf967ed0bc4c3906c7a3174635b1654df62e12d0e7504595"
}