Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Christopher Allen via bitcoin-dev]

I don't have a concrete proposal in mind, I'm just trying to understand
various tradeoffs in post-taproot bitcoin in more detail.

On Tue, Jan 31, 2023 at 6:07 PM Peter Todd  wrote:

>
> >OP_FALSE
> >OP_IF
> >OP_PUSH my64bytes
> >OP_ENDIF
>
> What's wrong with OpPush  OpDrop?
>

I'm not sure pro or con of either. I just saw that proposal above recently.


> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The
> whole point of OpReturn is to standardize a way to keep such outputs out of
> the UTXO set. There is the 75% discount to using witness space. But
> considering the size of a transaction as a whole using taproot instead of
> OpReturn doesn't save much.
>

There are OP_RETURN tricks in production that do clog UTXO space. I was
trying to avoid consideration of those by just saying to compare apples vs.
apples, by presuming that any form of these transactions holding the 64
bytes is a spent transaction.

Finally, _64_ bytes is more than a mere 32 byte commitment. What specific
> use case do you actually have in mind here? Are you actually publishing
> data, or simply committing to data? If the latter, you can use ECC
> commitments and have no extra space at all.
>

I chose 64 bytes for this exercise, as I know there are tricks hiding 32
bytes as keys. As almost every op_return live out there is >32 bytes, I
wanted an example that could be a signature, two hashes, a hash plus some
metadata, etc. I also considered 96 bytes (for instance a hash and a
signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice
prohibits comparing the different approaches side-by-side.

To come back to my question another way, if you ignore the people who say
"never put anything except data facilitating coin transactions into the
bitcoin blockchain", but if you also are not trying to use the bitcoin
blockchain as a world database (ala ETH), what is the most pragmatic way to
do so that minimizes any potential harm? The answer pre-taproot was
OP_RETURN. What is it now?

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Peter Todd via bitcoin-dev]

On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev 
 wrote:
>All other things being equal, which is better if you need to place a
>64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>taproot transaction such as:
>
>OP_FALSE
>OP_IF
>OP_PUSH my64bytes
>OP_ENDIF

What's wrong with OpPush  OpDrop?

>I know that the anti-OP_RETURN folk would say “neither.” But if there was
>no other choice for a particular protocol, such as a timestamp or a
>commitment, which is better? Or is there a safer place to put 64 bytes that
>is more uncensorable but also does not clog UTXO space, only spent
>transaction `-txindex` space?
>
>My best guess was that the taproot method is better, but I suspect there
>might be some who disagree. I'd love to hear all sides.

An important consideration with using taproot is that you need to have the data 
you are committing too to be able to to spend the txout in the future. OpReturn 
doesn't have that problem, meaning that in a situation like a hard drive 
failure, you can still recover the funds from a wallet seed.

Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The whole 
point of OpReturn is to standardize a way to keep such outputs out of the UTXO 
set. There is the 75% discount to using witness space. But considering the size 
of a transaction as a whole using taproot instead of OpReturn doesn't save much.

Finally, _64_ bytes is more than a mere 32 byte commitment. What specific use 
case do you actually have in mind here? Are you actually publishing data, or 
simply committing to data? If the latter, you can use ECC commitments and have 
no extra space at all.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Christopher Allen via bitcoin-dev]

All other things being equal, which is better if you need to place a
64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
taproot transaction such as:

OP_FALSE
OP_IF
OP_PUSH my64bytes
OP_ENDIF

I know that the anti-OP_RETURN folk would say “neither.” But if there was
no other choice for a particular protocol, such as a timestamp or a
commitment, which is better? Or is there a safer place to put 64 bytes that
is more uncensorable but also does not clog UTXO space, only spent
transaction `-txindex` space?

My best guess was that the taproot method is better, but I suspect there
might be some who disagree. I'd love to hear all sides.

-- Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

[Anthony Towns via bitcoin-dev]

On Tue, Jan 31, 2023 at 01:33:13PM -1000, David A. Harding via bitcoin-dev 
wrote:
> I thought the best practice[1] was that wallets would spend to the output
> indicated by any valid bech32m address.  

I think it depends -- if the wallet in question is non-custodial and
might not be upgraded by the time witness v2 addresses are in use, then
being able to send to such addresses now makes sense. 

If it's a custodial wallet where the nominal owner of the coins isn't
the one signing the tx, then I could see a pretty strong argument to not
allowing sending to such addresses until they're in use: (a) nobody will
be running the old software, since the custodian can just force everyone
to upgrade (eg, by deploying a new version of their own website), and (b)
signing a tx to send the bitcoins you're holding on Bob's behalf to an
address that will just get them stolen could be considered as negligence,
and you might end up forced to make Bob whole again.

So maybe the argument is:

 * is this a custodial wallet? then what's the point of testing a
   scenario that's likely years away -- the custodian will probably have
   changed their system entirely by then anyway

 * is it a non-custodial wallet? then it's worth testing -- you might
   not be able to find compatible software in future to move your
   private keys and have to dig up the current software and use it. will
   it still work? but in that case, you ought to be able to capture the
   tx it generates before broadcasting it, and don't need to publish it
   on chain, and then it doesn't matter what script you use?

(For libraries and non-wallet software like block explorers or alternate
node implementations, it's a different matter)

Cheers,
aj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

[Greg Sanders via bitcoin-dev]

David,

I'm merely speaking in a descriptive sense. I predict that most custodians
are reluctant to whitelist
a witness version they know is insecure.

I'm not sure what's best for not colliding with future versions, I'll let
other wiser folks weigh in.

Cheers,
Greg

On Tue, Jan 31, 2023 at 6:33 PM David A. Harding  wrote:

> On 2023-01-31 04:30, Greg Sanders wrote:
> > Hi David,
> >
> > From practical experience, I think you'll find that most exchanges
> > will not enable sends to future segwit versions,
> > as from a risk perspective it's likely a mistake to send funds there.
>
> Hi Greg!,
>
> I thought the best practice[1] was that wallets would spend to the
> output indicated by any valid bech32m address.  You seem to implying
> that the best practice is the opposite: that wallets should only send to
> outputs they know can be secured (i.e., which are not currently
> anyone-can-spend).  The more restrictive approach seems kind of sad to
> me since any problem which can result in a user accidentally withdrawing
> to a future segwit version could even more easily result in them
> withdrawing to a witness program for which there is no solution (i.e.,
> no key or script is known to spend).
>
> If it is a best practice, then I think there's a benefit to being able
> to test it even when other people's proprietary software is involved.  A
> wallet or service likely to follow that best practice may be more likely
> to follow other best practices which cannot be as easily tested for.
> But, if it's going to be tested, I want the testing to use the address
> least likely to cause problems for protocol developers in the future.
> Do you (and others on this list) have any reason to believe OP_16
> OP_PUSH2  would be a problematic script, or can you think of a
> better script?
>
> Thanks!,
>
> -Dave
>
> [1] BIP350, emphasis in original: "[...] we emphatically recommend [...]
> ensuring that your implementation supports sending to v1 **and higher
> versions.**"
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

[David A. Harding via bitcoin-dev]

On 2023-01-31 04:30, Greg Sanders wrote:

Hi David,

From practical experience, I think you'll find that most exchanges
will not enable sends to future segwit versions,
as from a risk perspective it's likely a mistake to send funds there.


Hi Greg!,

I thought the best practice[1] was that wallets would spend to the 
output indicated by any valid bech32m address.  You seem to implying 
that the best practice is the opposite: that wallets should only send to 
outputs they know can be secured (i.e., which are not currently 
anyone-can-spend).  The more restrictive approach seems kind of sad to 
me since any problem which can result in a user accidentally withdrawing 
to a future segwit version could even more easily result in them 
withdrawing to a witness program for which there is no solution (i.e., 
no key or script is known to spend).


If it is a best practice, then I think there's a benefit to being able 
to test it even when other people's proprietary software is involved.  A 
wallet or service likely to follow that best practice may be more likely 
to follow other best practices which cannot be as easily tested for.  
But, if it's going to be tested, I want the testing to use the address 
least likely to cause problems for protocol developers in the future.  
Do you (and others on this list) have any reason to believe OP_16 
OP_PUSH2  would be a problematic script, or can you think of a 
better script?


Thanks!,

-Dave

[1] BIP350, emphasis in original: "[...] we emphatically recommend [...] 
ensuring that your implementation supports sending to v1 **and higher 
versions.**"

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Universal Coin Swap system based on bitcoin and a Bitcoin NFT system

[Aymeric Vitte via bitcoin-dev]

I am not sure to understand the current discussion about ordinals
relayed by the press, it's from my standpoint a no for storing things in
witness, and a no to use ordinals as a NFT system

Please remember that NFTs are not only electronic things, it can be real
things, or whatever you like, just referenced in the blockchain by a
"double hash" for my proposal

Bitcoin is currently completely out of the future: the so-called "web3",
and lightning will not solve everything

Then please see my two proposals and comment, it's simple and easy to
read, and just complies with all comments related to/against the
ordinals proposal (storing things for my proposals in a good old
OP_RETURN the hashes and signatures only, not flooding bitcoin with
proofs of nothing, docs, images, etc), or just point out other better
systems based on bitcoin

It just shows again that bitcoin is better in all aspects compared to
other systems

I am not against ordinals but don't see it for "web3"


Le 26/01/2023 à 21:15, Aymeric Vitte a écrit :
> Please see:
>
> "A Bitcoin NFT system"
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The
> purpose of this proposal is to propose a simple NFT system based on the
> Bitcoin blockchain, assuming that the main purpose of a NFT is to be
> sold/bought, but not only, it can be something that you keep for
> yourself proving your ownership on the blockchain, or something that you
> offer to someone else, the advantages compared to using Ethereum or any
> blockchain/sidechain on both networks (or others) will be explained below"
>
> And the continuation:
>
> "A Universal Coin Swap system based on bitcoin"
> https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 "The
> purpose here is to propose a simple Coin Swap decentralized system based
> on Bitcoin but that works for all blockchains/tokens"
>
> The idea is to propose something simple, that people can understand,
> secured, decentralized, easy to implement/use, not expensive for the
> users, unlike Ethereum solutions, showing also that bitcoin can easily
> do in a much more simple manner what ethereum is doing
>
> It's a bit similar to Lightning but not as sophisticated, basically the
> proof of deals are stored in OP_RETURN (looks trivial, yes, but unlike
> other solutions the proposals store a real proof and does not flood the
> bitcoin network with funny stuff, it could be turned into bitcoin
> contracts which most likely will not be recognized as standard), we
> cannot enforce everything like Lightning but the trust here is more
> based on a reputation model, and same as Lightning the cheater just lose
> its bitcoin or get tagged as a cheater, will be tracked and might assume
> the consequences later
>
> As written, I am a fan of Lightning but see it more as a middle/long
> term relationship between people since coins must be locked into a
> multisig transaction while here we are more talking about a one time
> deal, where you don't know if you will buy something else to the seller,
> with which coin and where (metaverse for example)
>
> For your review and comments, here or in private, no real inventions
> here but some non usual ideas like the double hash, the third party and
> others, solving also one of my personal problematic since years: "how to
> sell a secret NFT?"
>
> In any case it remains decentralized (but of course some tools/wallets
> must ease the process for the users), like Lightning, and unlike
> everything that is existing today in those areas to my knowledge, except
> Lightning again
>
> Regards
>
> Aymeric
>
>

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: 
https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: 
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: 
http://torrent-live.peersm.com
Peersm : http://www.peersm.com


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys

[Billy Tetrud via bitcoin-dev]

Ah good to know someone's put work into this kind of idea. Thanks for the
reference!

On Thu, Jan 26, 2023 at 8:31 AM darosior  wrote:

> Hello Billy,
>
> Yes it's basically a (simple) instantiation of Revault. You can find more
> at https://github.com/revault (you most likely want the
> `practical-revault` repo). There is a description of the concept, the
> specification of a communication protocol between the participants as well
> as the implementation of the whole.
>
> Such a design presents some advantages, but it has two major issues:
>
>- You need to make sure all your watchtowers received the Cancel
>signature before you sign the Unvault transaction. But how can you get this
>guarantee in the usual (and reasonable) model of an untrusted laptop?
>- You can only have policies on the Unvault transaction (eg "You can
>only Unvault up to X BTC during working hours"), not on the Spend
>transaction (eg "You can only send coins to a Script with pubkey Y required
>in all spending paths"). Revault allows to use cosigning servers that act
>as anti-replay oracles to have policies on the spend, but this is obviously
>*very* suboptimal.
>
>
> Both issues are solvable with covenants.
>
> Antoine Poinsot
> --- Original Message ---
> Le lundi 23 janvier 2023 à 6:39 PM, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
> In the discussion around James' OP_VAULT proposal, it was implied that
> precomputed vaults must use ephemeral keys that must be deleted as part of
> the vaulting protocol, like Bryan Bishop's proposal
> .
> Looking around, I haven't been able to find any wallet vault proposal that
> doesn't require ephemeral keys, so at the risk of posting something that's
> obvious to everyone, I wanted to share a simple way to do a wallet vault
> without requiring any key deletion.
>
> The basic idea is to create an N-of-N multisig address, and pre-sign some
> transactions from it with N-1 keys to an address with several timelocked
> spend paths. This has the fallback that funds can always be spent
> immediately if you use all the keys, just like a normal N-of-N multisig
> address (since that's what it is at its core), but the usage of any of the
> pre-signed transactions leads to an address that guarantees a clawback
> within a time window. Here's a 3-of-3 example:
>
> *Vault Initialization*:
> 1. Create 3 of 3 Vault Address
> 2. Create an Interim Address that can send with:
> * 1 of 3 keys after a timelock of 1 month
> * 2 of 3 keys after a timelock of 1 week
> * 3 of 3 keys with no timelock
>
> *Vaulting*:
> 1. Create a transaction sending an output to the Vault Address
> 2. Create a transaction spending that Vault Address output to the Interim
> Address
> 3. Presign one copy of the step-2 transaction for each of the three
> combinations of two keys.
> 4. Store seeds separately, store the wallet config as well as the three
> presigned transactions with each seed.
>
> *Unvaulting*:
> 1. Sign one of the pre-signed transactions with the missing signature.
> 2. Broadcast
> 3. Wait the appropriate timelock for the number of keys you want to sign
> with.
> 4. Create a transaction sending from the Interim Address.
> 5. Broadcast
>
> *Recovering *(after unvaulting step 2 after the broadcasted transaction
> to the Interim Address has been mined):
> 1. Sign the utxo with all three keys to any destination. Alternatively
> sign with two keys, wait 1 week.
> 2. Broadcast it
>
> This has the usual downsides of pre-signed vaults that you need to backup
> these transactions for each vaulting, complications involving the
> flexibility (or lack thereof) of fees, and inflexibility in how much to
> unvault (must be the whole utxo, no change). This could of course be
> augmented with various techniques to make fee handling more flexible
> (anchor outputs, multiple versions of the presigned transactions with
> different fees, etc). More complicated presigning schemes could allow for
> some flexibility in unvaulting amount (eg by sending change back into the
> vault, and creating additional pre-signed transactions for that new output).
>
> It also has the same downside that OP_CTV vaults have, where a stolen key
> can steal funds from the interim address by racing the owner with their own
> transaction once the necessary delay has passed. Note that James' OP_VAULT
> opcode wouldn't have this problem.
>
> But not requiring any toxic waste keys seems like a pretty good benefit
> over Bryan Bishop's original proposal.
>
> Anyways sorry if this was already on people's radar and just too obvious
> to post about.
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

[Greg Sanders via bitcoin-dev]

Hi David,

>From practical experience, I think you'll find that most exchanges will not
enable sends to future segwit versions,
as from a risk perspective it's likely a mistake to send funds there. That
said, as long as we don't change
the checksum again(!), updating to new versions should be fairly straight
forward. Every update will be a matter
of allowing a new version and a new length instead of requiring
library updates. Making sure the most popular
open source libraries support it is probably the best way to spend energy
ensuring that future upgrades go smoothly.

Best,
Greg

On Mon, Jan 30, 2023 at 8:25 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi y'all!,
>
> One of the benefits proposed for bech32 (and, by extension, bech32m) is
> that spender wallets shouldn't need to be upgraded to pay segwit outputs
> defined in future soft forks.  For example, Bitcoin Core today can pay a
> bech32m address for a segwit v2 output, even though no meaning has been
> assigned to output scripts matching a segwit v2 template.
>
> However, testing this behavior in production[1] can create an annoyance
> for developers of future soft forks.  They will need to deal with any
> existing outputs paid to the templates used in that proposed soft fork.
> See, for example, some discussion by developer 0xB10C about payments to
> segwit v1 addresses before activation of the taproot soft fork:
> https://b10c.me/blog/007-spending-p2tr-pre-activation/
>
> I was wondering if it would be useful to have a canonical examples of
> future segwit addresses that are designed to be very unlikely to
> interfere with future soft forks but which would still reasonably
> exercise wallets supporting bech32m.  I think of this as the rough
> equivalent of the RFC2606 domain "example.com" which has been reserved
> for examples in documentation.
>
> Specifically, I'm thinking of the following addresses, one each for
> mainnet and testnet:
>
> - HRP: bc for mainnet; tb for testent
> - Witness version: 16 (the last segwit version)
> - Witness program: 0x.  Two bytes is the minimum allowed
>by BIP141, but it's far too small to make any sort of secure
> commitment,
>so I'm hoping it won't conflict with any future use
>
> I think we should try to start with just one reserved address per
> network, but if that isn't enough, I think we could allow any two-byte
> witness program with witness version 16.
>
> Outputs paid to reserved addresses will still be anyone-can-spend, so
> there's no change required to Bitcoin Core or other software and those
> outputs can still be cleaned out of the UTXO set.  Additionally, if we
> ever *really* need that address space for a soft fork, it will be
> available.
>
> Are there any objections to this idea, or suggestions for a better way
> to go about it?
>
> Thanks!,
>
> -Dave
>
> [1] Testing in production should be avoided because it uses block space
> that could otherwise be used by actual value transfers.  Also, it costs
> money and pollutes the UTXO set (at least temporarily).  However, when
> testing whether proprietary third-party software, such as an exchange,
> supports payments to future segwit versions, sometimes the only
> convenient method is to actually pay the address for a future segwit
> version.  Additionally, my specific use case is just to write
> documentation
> about bech32m---but I worry that people will pay my example of a future
> segwit
> version address.
> ___
> 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] Ordinal Inscription Size Limits

[Erik Aronesty via bitcoin-dev]

my only concern is that as block space gets limited the likelihood of soft
fork opcode tech improvement proposals getting accepted by the community
goes down

schnorr sigs are extremely useful to me (anon, cheap multisig)

and some sort of vault tech would be very helpful as well
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev