3

Yes, assuming James sends Bob two outputs with the following spending conditions: pk($bob) || (pk($alice) && older(10)) pk($bob) || (pk($carol) && older(10)) Bob can spend these UTXOs together in one transaction by unilaterally satisfying the first spending conditions just with his signatures. Once either of the two UTXOs has ten ...


3

My first instinct was to write that we don't know this as we don't know how the exact protocol for PTLCs looks like but then I realized that unless someone finds a cool trick it will probably be hard to combine them for the following reason: With HTLCs we basically create an output in the commitment transaction that can be spend by the receiver if the ...


2

My question is whether this MusigTweak is what is called the adaptor (last argument of secp256k1_musig_session_combine_nonces) in secp256k1-zkp? No, what "Z-man" refers to as MusigTweak is not called the adaptor in secp256k1-zkp. The difference between the normal MuSig ritual and the "almost entirely MuSig" ritual is not the MuSigTweak. The MuSigTweak just ...


1

Yes the payment point would have to be included instead of the payment hash. I believe other than that nothing in the invoices would have to change. Invoices have various fields with various semantics. One of them is the field for the payment hash. In order to stay backwards compatible I guess there will be a new field for payment points (public keys) ...


Only top voted, non community-wiki answers of a minimum length are eligible