📅 Original date posted:2019-03-14
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
> so if you used a tagged output, you could do everything normal taproot
> address could, but also do noinput sigs for them.
>
> So you might have:
>
> funding tx -> cooperative claim
>
> funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
>
> funding tx -> update 3 [TAGGED] ->
> update 4 [TAGGED,NOINPUT] ->
> settlement 4 [TAGGED,NOINPUT] ->
> claim [NOINPUT]
>
> In the cooperative case, no output tagging needed.
I might be missing something here, but how do you bind update 3 to the
funding tx output, when that output is not tagged? Do we keep each
update in multiple separate states, one bound to the funding tx output
and another signed with noinput? If that's the case we just doubled our
storage and communication requirements for very little gain. An
alternative is to add a trigger transaction that needs to be published
in a unilateral case, but that'd increase our on-chain footprint.
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:54:28
in reply to nevent1q…3gc4
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:54:28Event JSON
{
"id": "3d6d9979850dd1013564cfdea307040b01fa1a83314d23c5ed933b9f442d65f5",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315268,
"kind": 1,
"tags": [
[
"e",
"86a47a61621252784fd45b6d576812ee01ce9af9bd2a53aeaae914577c5267a8",
"",
"root"
],
[
"e",
"29e71b0d66911bf3782823e903b15703e72d8db3897feafe1ebe9f9a92b729a0",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-03-14\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e I'm thinking of tagged outputs as \"taproot plus\" (ie, plus noinput),\n\u003e so if you used a tagged output, you could do everything normal taproot\n\u003e address could, but also do noinput sigs for them.\n\u003e\n\u003e So you might have:\n\u003e\n\u003e funding tx -\u003e cooperative claim\n\u003e\n\u003e funding tx -\u003e update 3 [TAGGED] -\u003e settlement 3 -\u003e claim\n\u003e\n\u003e funding tx -\u003e update 3 [TAGGED] -\u003e \n\u003e update 4 [TAGGED,NOINPUT] -\u003e \n\u003e \t\t settlement 4 [TAGGED,NOINPUT] -\u003e \n\u003e \t\t claim [NOINPUT]\n\u003e\n\u003e In the cooperative case, no output tagging needed.\n\nI might be missing something here, but how do you bind update 3 to the\nfunding tx output, when that output is not tagged? Do we keep each\nupdate in multiple separate states, one bound to the funding tx output\nand another signed with noinput? If that's the case we just doubled our\nstorage and communication requirements for very little gain. An\nalternative is to add a trigger transaction that needs to be published\nin a unilateral case, but that'd increase our on-chain footprint.",
"sig": "3cf31a173acb2c2fa03d634bb016a62c66fdaa8fb961904ff3ac4688a9950c03d76f05e0fc4051eec211a6556b23ebb844f6c7dc24886dc2eaf09591c6ce9c7a"
}