public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee.
@ 2022-11-18 21:11 Andrew Melnychuk Oseen
  2022-11-21 23:52 ` ZmnSCPxj
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Melnychuk Oseen @ 2022-11-18 21:11 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 15445 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee.
  2022-11-18 21:11 [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee Andrew Melnychuk Oseen
@ 2022-11-21 23:52 ` ZmnSCPxj
  2022-11-26  0:12   ` Rijndael
  0 siblings, 1 reply; 3+ messages in thread
From: ZmnSCPxj @ 2022-11-21 23:52 UTC (permalink / raw)
  To: Andrew Melnychuk Oseen, Bitcoin Protocol Discussion


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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee.
  2022-11-21 23:52 ` ZmnSCPxj
@ 2022-11-26  0:12   ` Rijndael
  0 siblings, 0 replies; 3+ messages in thread
From: Rijndael @ 2022-11-26  0:12 UTC (permalink / raw)
  To: ZmnSCPxj, Bitcoin Protocol Discussion, Andrew Melnychuk Oseen

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-11-26  0:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-18 21:11 [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee Andrew Melnychuk Oseen
2022-11-21 23:52 ` ZmnSCPxj
2022-11-26  0:12   ` Rijndael

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox