Re: [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee.
Hello Andrew, As ZmnSCPxj mentioned, covenant schemes are probably something that you should be looking at and thinking about. In addition to CTV, I'd also recommend you take a look (if you haven't already) at `TAPLEAF_UPDATE_VERIFY` (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html). From your description, it sounds like you may be barking up a similar tree. Rijndael On 11/21/22 6:52 PM, ZmnSCPxj via bitcoin-dev wrote: > Good morning Andrew, > >> >> Can output amounts be mapped to a tap branch? For the goal of secure partial >> spends of a single UTXO? Looking for feedback on this idea. I got it from >> Taro. > > Not at all. > > The issue you are facing here is that only one tap branch will ever consume > the entire input amount. > That is: while Taproot has multiple leaves, only exactly one leaf will ever > be published onchain and that gets the whole amount. > > What you want is multiple tree leaves where ALL of them will EVENTUALLY be > published, just not right now. > > In that case, look at the tree structures for `OP_CHECKTEMPLATEVERIFY`, which > are exactly what you are looking for, and help make `OP_CTV` a reality. > > Without `OP_CHECKTEMPLATEVERIFY` it is possible to use presigned transactions > in a tree structure to do this same construction. > Presigned transactions are known to be larger than `OP_CHECKTEMPLATEVERIFY` > --- signatures on taproot are 64 bytes of witness, but an > `OP_CHECKTEMPLATEVERIFY` in a P2WSH reveals just 32 bytes of witness plus the > `OP_CHECKTEMPLATEVERIFY` opcode. > > Regards, > ZmnSCPxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee.
Good morning Andrew, > > > Can output amounts be mapped to a tap branch? For the goal of secure partial > spends of a single UTXO? Looking for feedback on this idea. I got it from > Taro. Not at all. The issue you are facing here is that only one tap branch will ever consume the entire input amount. That is: while Taproot has multiple leaves, only exactly one leaf will ever be published onchain and that gets the whole amount. What you want is multiple tree leaves where ALL of them will EVENTUALLY be published, just not right now. In that case, look at the tree structures for `OP_CHECKTEMPLATEVERIFY`, which are exactly what you are looking for, and help make `OP_CTV` a reality. Without `OP_CHECKTEMPLATEVERIFY` it is possible to use presigned transactions in a tree structure to do this same construction. Presigned transactions are known to be larger than `OP_CHECKTEMPLATEVERIFY` --- signatures on taproot are 64 bytes of witness, but an `OP_CHECKTEMPLATEVERIFY` in a P2WSH reveals just 32 bytes of witness plus the `OP_CHECKTEMPLATEVERIFY` opcode. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee.
Can output amounts be mapped to a tap branch? For the goal of secure partial
spends of a single UTXO? Looking for feedback on this idea. I got it from Taro.
Merkel_tree_root_tweak = tagged_hash(“root” || left_hash || right_hash)
Tree_branch = tagged_hash(“branch” || left_hash || right_hash ) ||
right_output_sum + left_relative_output_amount
Tree_leaf = tagged_hash("leaf" || script ) || relative_output_amount
Transaction Validation:
There would be one output with an amount that is negative.
The negative amount would flag this transaction as relative amount spends.
The miner fee would be the absolute of the output amount.
The witness would include the txout amount.
Txout is less than other inputs that referencing this output.
Questions:
Would this require a hard fork?
Would the sum be required in the asset tree?. The sum at the root would be
implicitly 1.0. How big can a taproot tree get before it is too cumbersome?
Could multiple taproot trees be put inside a tweak?
Am I missing anything vital?
Possible Benefits
Perhaps slightly increase privacy of output amounts?
Reduced growth rate of UTXO’s. This scheme would be consuming N inputs and
producing 1 output.
Drawbacks
I think this would disable the ability for output change addresses to be the
same as inputs as the spending amounts are absolute.
Transaction Example
Inputs : [1.5,.3,.1]
TapTree:
Branch sum :1
Change Address : .5
Branch sum: .5
AlicePubKey: .2
Branch sum: .3
BobPub and BobHash: .1
Branch sum: .2
CaroPub and DavePub and CarolDaveHash : .1
ErinPub and CarolDaveHash and after 10days : .1
Outputs: [-.0.001]
Alice spending example
Alice sends to new address : .1 * (sum of Inputs + outputs) = 0.18999
Alice New Change Address = .1 * (sum of Inputs + outputs) = 0.18999
Application
I think something like this would provide away to onboard a lot of lightning
channels with a single UTXO output. An exchange could schedule open lightning
channels at certain time intervals, perhaps every 10 minutes. Ideally, people
would provide pubkeys and payment, to be placed in a tap leaf. Similar to
selling seats for an aircraft flight.
Thanks for reading
Andrew
Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
