Timeline for Qualitative anatonomy of a transaction that uses ANYPREVOUT
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 1, 2022 at 17:54 | comment | added | Lorban | ok thank you! this is very helpful! | |
| Aug 1, 2022 at 17:51 | comment | added | Michael Folkson | Right in protocols like Lightning and eltoo'd Lightning they require communication between Alice and Bob. In your example Alice needs to know the script that Bob encoded into the outputs of tx0 to be able to construct a transaction that spends those outputs. | |
| Aug 1, 2022 at 17:31 | comment | added | Lorban | ok but, still, suppose that someone, say Alice, is making a transaction tx1 that spends the output of a transaction tx0 made by Bob, that hasn't appeared yet. So, Alice precompiles the transaction tx1 with anyprevout, that can spend the tx0 output only using the script of tx0. But Alice may not be aware of this script, that is made by Bob and so may not be able to precompile tx1... Is this a problem? I mean, this seems to require communication between Alice and Bob... | |
| Aug 1, 2022 at 16:39 | comment | added | Michael Folkson | There can only be an ANYPREVOUT signature spending via the script path not the key path, yes. But there can be a non-ANYPREVOUT signature spending via the key path still. So in the unlikely scenario that the script path implementation was botched you could still spend from the key path with a non-ANYPREVOUT signature (assuming that a spendable key path had been encoded into the address) | |
| Aug 1, 2022 at 16:26 | comment | added | Lorban | Well actually I misunderstood the logic. The signature is done by the payee. But I still don't understand where in the witness appears this signature. ANYPREVOUT only supports spending a P2TR via the script path, so a P2TR output with an invalid script can't be spent using ANYPREVOUT. This is strange! | |
| Aug 1, 2022 at 11:27 | comment | added | Michael Folkson | The functionality we want for protocols like eltoo is for that signature to be reused in a new transaction with different inputs without requiring a new signature. | |
| Aug 1, 2022 at 11:21 | comment | added | Michael Folkson | I think you misunderstand sighash flags too. "The transaction tx makes no explicit reference to any input to be spent and will be presented later to the payer to be signed." The signer will choose to use a sighash flag like ANYPREVOUT (or SIGHASH_SINGLE, SIGHASH_ANYONECANPAY etc) at signing time and that will determine what the signer needs to sign. The transaction isn't constructed to be an ANYPREVOUT transaction and then presented to the signer. A transaction always needs inputs to spend but whether the signer signs those specific inputs is the question here. | |
| Aug 1, 2022 at 10:39 | history | edited | Michael Folkson | CC BY-SA 4.0 |
deleted 2 characters in body
|
| S Aug 1, 2022 at 10:30 | history | suggested | CommunityBot | CC BY-SA 4.0 |
grammar and better description
|
| Aug 1, 2022 at 8:53 | review | Suggested edits | |||
| S Aug 1, 2022 at 10:30 | |||||
| Jul 29, 2022 at 13:12 | history | edited | Lorban | CC BY-SA 4.0 |
grammar
|
| Jul 29, 2022 at 10:15 | comment | added | Michael Folkson | I'll make some edits later but where you say "address" you should be saying "public key". BIP118 defines a new public key type but doesn't make any changes to the address format (bech32m). | |
| Jul 29, 2022 at 10:11 | history | edited | Lorban | CC BY-SA 4.0 |
improved formatting of one formula
|
| Jul 29, 2022 at 10:06 | history | edited | Michael Folkson | CC BY-SA 4.0 |
edited body
|
| Jul 29, 2022 at 10:03 | history | asked | Lorban | CC BY-SA 4.0 |