Andrew Melnychuk Oseen [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-11-18 to 2023-04-26
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:20:54

- reply

📅 Original date posted:2023-04-26
🗒️ Summary of this message: Proposal for a BIP on the metadata structure of assets traded on TARO Protocol, suggesting a JSON format including ticker, type, description, image, and minter info.
📝 Original message:Big fan of this. I don't have the technical expertise to suggest much, but I think that is a really good start for a foundation of bearer instruments.
-Andrew
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Friday, April 21st, 2023 at 2:46 AM, Adam Ivansky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all / happy Friday ,
>
> I would like to propose a BIP for the metadata structure of assets traded on TARO Protocol running on Bitcoin blockchain. A new bip-taro.mediawiki file.
>
> The BIP for TARO is here https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki . TARO BIP does not explicitly talk about the format of metadata of the assets. However this is something we will have to agree on if we are to start trading NFTs, Stablecoins and different synthetic assets such as tokenized stocks / options.
>
> For the past few months I have been operating a wallet for TARO called Tiramisu Wallet on testnet ( https://testnet.tarowallet.net/ ) and I was able to put together a list of fields that the metadata should have . This is a result of myself testing different use cases for the protocol as well as external users coming in and minting different assets.
>
> My observation is that users care a lot about the ticker, asset name, description, image representing the asset, info on who minted the asset.
>
> For this reason I would like to propose a BIP for TARO Protocol asset metadata. I think this should be separate from the TARO BIP as the format of asset metadata might evolve depending on the real-life use cases and what assets end up being minted / traded on TARO.
>
> I am proposing that the metadata is structured as a JSON stored as a string and that it is formatted as follows:
>
> {
> "ticker": // [optional] Fungible assets should have ticker
> "type": // Stablecoin | Image | Video | Data ... Type of the asset
> "description": // [mandatory] Short description of the asset explaining how the asset works
> "data": // [optional] Base64 formatted image data. This is the image representation of the asset / an icon representing the asset.
> "hash_data": // [optional] Hash of the data that asset represents
> "external_url": // [optional] External URL to the thing that the asset represents
> "attributes": { // [optional] External URL to the thing that the asset represents
> "collection_name":
> ...
> }
> "minter_info": { // [optional] Information about the entity that minted the asset
> "name":
> "email":
> "phone":
> "telegram":
> "website":
> }
> }
>
> This was loosely inspired by the standard use by OpenSea https://docs.opensea.io/docs/metadata-standards only in case of TARO we have less of an incentive to make the metadata small as this data is not written to blockchain directly.
> This is why I think we should start including the actual image data into the metadata.
>
> Tiramisu wallet is on testnet right now and uses some of these JSON fields.
>
> Please let me know how you feel about this.
>
> PS: I am following the manual from here https://github.com/Roasbeef/bips/tree/bip-taro that says my first step should be sending an email to this mailing list .
>
> Best regards,
>
> Adam Ivansky
>
> Founder of Tiramisu Wallet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230426/3ae36ec9/attachment-0001.html>

2023-06-07 23:20:54

- reply

2023-06-07 23:20:14

- reply

📅 Original date posted:2023-03-04
🗒️ Summary of this message: Proposal for a new protocol rule, min_fees, to ensure a socially optimal equilibrium in a scenario where block rewards are almost zero and transaction fees are very small.
📝 Original message:From my limited knowledge in the space, and I've taken opinions of people I respect that are far more knowledgeable than me.
I don't know of any data of what happens at the point where the coinbase drops to below the fees on any chain. I don't think there has been one where that has happened. Perhaps there is a chain out there where it is fee's only? Perhaps that can provide insight.
Opinion: I think as bitcoin's capabilities grow, demand for it will as well. There are a lot of efforts to increase the amount of transactions that can fit into a block. I think the combination of limited block space and a reduced amount of bitcoin's entering the market is the right combination for the system to self sustain. I'm looking forward to seeing the result!
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Wednesday, March 1st, 2023 at 12:18 PM, Giuseppe B via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello everyone,
>
> I'm relatively new here so what I'm proposing could have already been discussed, or may be flawed or inapplicable. I apologize for that.
>
> I was picturing a situation where block rewards are almost zero, and the base layer is mainly used as a settlement layer for relatively few large transactions, since the majority of smaller ones goes through LN.
>
> In such a case it may very well be that even if transaction amounts are very consistent, transaction fees end up being very small since there is enough space for everyone in a block. Users wouldn't mind paying higher fees as they know that that would increase the network security, however nobody wants to be the only one doing that. Miners would of course like being paid more. So everyone involved would prefer higher fees but they just stay low because that's the only rational individual choice.
>
> Therefore I was imagining the introduction of a new protocol rule, min_fees, that would work like this:
> - the miner that gets to mine a block appends a min_fee field to the block, specifying the minimum fees that need to be contained in the following block in order for it to be valid.
> - one can also mine an empty block and reset the min_fee, to avoid the chain getting stuck.
>
> min_fees could either represent the total fees of the following block, or the minimal fee for each single transaction, as a percentage of the value transacted. Both seem to have some merits and some potential drawbacks. Of course min_fees=0 would correspond to the current situation.
>
> It looks to me that this could have the potential to bring the equilibrium closer to a socially optimal one (as opposed to individually optimal), and to benefit the network security in the long term. Of course it's just a rough sketch and it would deserve a much deeper analysis. I was just interested in knowing if you think that the principle has some merit or if it's not even worth discussing it for some reason that I'm not considering.
>
> Cheers,
>
> Giuseppe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230304/6a34ff0c/attachment.html>

2023-06-07 23:20:14

- reply

2023-06-07 23:19:57

- reply

📅 Original date posted:2023-03-02
🗒️ Summary of this message: The sender is proposing a tapscript that restricts the amount that multiple tapleaves can spend, with specific rules for each participant. They also suggest combining transactions and mention related BIPs.
📝 Original message:I read the draft and this seems to have some functionality that I am looking for. I'm pretty new to bitcoin-dev, but I'm persistent and have a lot of time on my hands.
I would like multiple tapleaves be restricted on the amount that they can spend.
Say an input of 1 BTC, has a locking script of a tapscript that has 1 of 3 pubkeys of Alice, Bob and Carol(participants). I want to restrict the outputs of their next transactions to .2, .3 and .5 BTC respectively.
In the event of Bob spending their output, they are restricted to make a transaction that has a change output that has at least Alice and Carol's Amount, and a 1 or 2 tapscript or a 1 of 3 tapscript if Bob didn't spend all of their funds.
In the event of two of the three participants separately broadcast their transactions, I'm hoping that the second sender, can combine the two transactions into a package where the outputs and witnesses would be adjusted where two participants share an output with their respective amounts, and the remainder participant still has their funds available.
Is this clear? I don't have a lot of experience communicating complex ideas in writing. I've been looking at some BIP's like OP_CHECKTEMPLATEVERIFY as well which had some idea's I really liked like OP_AMOUNTVERIFY. I'm not aware of the risks that the community previously discussed about the topic.
Andrew
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Thursday, March 2nd, 2023 at 6:54 AM, Greg Sanders via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Greetings AJ,
>
> Glad I could resurrect the idea!
>
>> Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
> write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
> OP_FORWARD_LEAF_UPDATE`
>
> Interesting idea! (I'll let you be the one to scope creep the proposal :) )
>
> To be pedantic, EXPR_TRIGGER would become:
>
> <trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE
>
> and at spend time the idx and hash are put into the witness stack.
>
> To be clear, <spend-delay> could be embedded in the <script> too, right, making <2> a <1> in the above? Any reason for one or the other?
>
> Another bonus from this is that you can introduce withdrawal authorization as well as part of the <script>. Current proposal has no withdrawal authorization, from what I understand. So each transition in a vault construct can have authorization, if it desires it.
>
>> I do recognise that it makes it take a variable number of stack elements
> though :)
>
> Just when I thought I was out, they pulled me back in.
>
>> I don't think replacing the internal-public-key makes sense -- if it
> was immediately spendable via the keypath before there's no reason for
> it not to be immediately spendable now.
>
> Slavishly following the current proposal was the idea to make sure all functionality was captured; I agree with this change.
>
>> Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
> you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.
>
> Previously setting CSV timeout to 0 would result in it not being satisfiable, if I'm understanding the suggestion correctly. I suppose this was a side-effect of having OP_UNVAULT take this value directly. Indeed with `OP_FORWARD_OUTPUTS` being split out there's not really a reason to use a 0 value?
>
>> I think the existing OP_VAULT cleverness would work here, allowing you
> to spend two inputs to the same output, accumulating their values.
>
> Yes I think batching story should be same hopefully. I am assuming all the accounting OP_VAULT is doing is being done here. We match against the hash passed in, and fits into the "deferred checks" IIUC.
>
>> OP_FORWARD_REFUND
>
> Again, to be pedantic EXPR_TRIGGER becomes:
>
> <trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE OP_FORWARD_REFUND
>
> Resulting in 2 more WU at spend time(for small idx). So up front committing to a refund path, perhaps with value explicitly passed in.
>
> Totally forgot about the refund path; will need to mull the issue over, see how it interacts with BYOF schemes, etc.
>
> Cheers,
> Greg
>
> On Wed, Mar 1, 2023 at 11:46 PM Anthony Towns <aj at erisian.com.au> wrote:
>
>> On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev wrote:
>>> Below is a sketch of a replacement for the two opcodes.
>>
>> I like this! I tried to come up with something along similar lines for
>> similar reasons, but I think I tried too hard to reduce it to two opcodes
>> or something and got myself confused.
>>
>>> `OP_TRIGGER_FORWARD`: Takes exactly three arguments:
>>> 1) output index to match against (provided at spend time normally)
>>> 2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
>>> (provided at spend time normally)
>>> 3) spend-delay: value to be forwarded to output given at (1)
>>
>> I think you could generalise this as follows:
>>
>> idx .. npush script OP_FORWARD_LEAF_UPDATE
>>
>> (OP_FLU :) with the behaviour being:
>>
>> pop script from the stack
>> pop npush from the stack (error if non-minimal or <0)
>> pop npush entries from the stack,
>> prefix script with a minimal push of that entry
>> pop idx off the stack (error if idx is not a valid output)
>> calculate the spk corresponding to taking the current
>> input's spk and replacing the current leaf with the
>> given script
>> check the output at idx matches this spk, and the
>> value from this input accumulates to that output
>>
>> Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
>> write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
>> OP_FORWARD_LEAF_UPDATE`
>>
>> That's an additional 5 witness bytes, but a much more generic/composable
>> opcode.
>>
>> Being able to prefix a script with push opcodes avoids the possibility
>> of being able to add OP_SUCCESS instructions, so I think this is a fairly
>> safe way of allowing a TLUV-ish script to be modified, especially compared
>> to OP_CAT.
>>
>> I do recognise that it makes it take a variable number of stack elements
>> though :)
>>
>>> As the derived tapscript, embedded in a output scriptpubkey of the form:
>>> `tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
>>> from the spending input, swap the inner pubkey for `NUMS`, use
>>> `EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
>>> scriptpubkey doesnt match, fail.
>>
>> I don't think replacing the internal-public-key makes sense -- if it
>> was immediately spendable via the keypath before there's no reason for
>> it not to be immediately spendable now.
>>
>>> Could save 2 WU having OP_FORWARD_OUTPUTS take the <spend-delay> directly
>>> as an argument, or keep it more general as I did.
>>
>> Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
>> you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.
>>
>>> Would love to know what you and others think about this direction. I
>>> apologies for any misunderstandings I have about the current OP_VAULT BIP!
>>
>> I think the existing OP_VAULT cleverness would work here, allowing you
>> to spend two inputs to the same output, accumulating their values.
>>
>> I don't think it quite gives you a way to "refund" values though -- so
>> that you can take a vault with 3 BTC, start the <delay> wait to spend
>> 1.4 BTC, and then immediately decide to spend an additional 0.8 BTC on
>> something else, without the 0.8 BTC effectively having a doubled delay.
>>
>> I think you could fix that with something as simple as an additional
>> "idx OP_FORWARD_REFUND" opcode, though -- then the restriction is just
>> that the output at the refund idx has the same sPK as this input, and
>> the total value of this input is accumulated amongst all the outputs
>> specified by OP_FORWARD opcodes. (Maybe you need to specify the refund
>> amount explicitly as well, to keep verification easy)
>>
>> That would make maybe three new opcodes to cover the "accumulate value
>> from one or more inputs into specified outputs":
>>
>> - OP_FORWARD_LEAF_UPDATE --> forward input value to modified spk
>> - OP_FORWARD_DESTINATION --> forward input value to given spk
>> - OP_FORWARD_REFUND --> forward part of input value to same spk
>>
>> along with OP_CTV:
>>
>> - OP_FORWARD_OUTPUTS --> pay to specific outputs
>>
>> OP_VAULT's "accumulate value" behaviour here makes the OP_IN_OUT_AMOUNT
>> things from TLUV more implicit and automatic, which is nice. I think
>> doing TLUV payment pools wouldn't require much more than the ability to
>> combine OP_FLU and OP_FDEST in a single script, explicitly specifying
>> how much value is extracted via OP_FDEST with the rest assigned to OP_FLU.
>>
>> Cheers,
>> aj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230302/738f7390/attachment-0001.html>

2023-06-07 23:19:57

- reply

2023-06-07 23:17:02

- reply

📅 Original date posted:2022-11-18
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221118/a95e7ca4/attachment.html>

2023-06-07 23:17:02

- reply