Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
> OP_TRUE is the obvious way to do this, and it results with a 1 on the stack, which plays better with other standardness rules. What other standardness rules? MINAMALIF? How does that interact with the proposal? On Thu, Feb 2, 2023 at 3:22 PM Peter Todd wrote: > On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote: > > Quickly checked, it fails a number of standardness tests in > unit/functional > > tests in Bitcoin Core, at least. > > > > OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I > > just independently arrived at the same conclusion. > > Well, frankly I really don't like the idea of using OP_2 just to avoid > changing > some unit tests. We're doing something that many people will use for years > to > come, that's unnecessarily obscure just because we don't want to spend a > bit of > some modifying some tests to pass. > > OP_TRUE is the obvious way to do this, and it results with a 1 on the > stack, > which plays better with other standardness rules. OP_2 means we *also* may > need > to special case having a 2 on the stack in certain implementations of other > standardness rules. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote: > Quickly checked, it fails a number of standardness tests in unit/functional > tests in Bitcoin Core, at least. > > OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I > just independently arrived at the same conclusion. Well, frankly I really don't like the idea of using OP_2 just to avoid changing some unit tests. We're doing something that many people will use for years to come, that's unnecessarily obscure just because we don't want to spend a bit of some modifying some tests to pass. OP_TRUE is the obvious way to do this, and it results with a 1 on the stack, which plays better with other standardness rules. OP_2 means we *also* may need to special case having a 2 on the stack in certain implementations of other standardness rules. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
Quickly checked, it fails a number of standardness tests in unit/functional tests in Bitcoin Core, at least. OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I just independently arrived at the same conclusion. On Thu, Feb 2, 2023 at 10:06 AM Peter Todd wrote: > On Thu, Feb 02, 2023 at 09:59:09AM -0500, Greg Sanders wrote: > > Hi Peter, > > > > For the most principled of reasons: > > > > Because I have to change test vectors everywhere! > > Specifically, you mean you'd have to change tests that test something is > non-standard? > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Purely off-chain coin colouring
I am not an expert with RGB, but it looks limited (only bitcoin chains
from the github repo, apparently on hold), distributed over the
"lightning network" or LN nodes (what is it?), or Bifrost extension,
with a dubious token floating around, like ethereum mess as RGB docs
describe Ethereum (and myself also), layer2 or layer3, certainly not
decentralized (like still Bitcoin and Ethereum)
It's of course useless to trust IPFS or Bittorrent to store things
because you cannot control the seeders who have zero incentive to seed
such things
That's why in my much more simple proposals a well known third party is
there, wayback machine, github, twitter, etc, if they disappear then
probably internet has disappeared too, if they get censored you can
still get a snapshot of what you did
The intent is certainly not to store NFTs in Bitcoin, only hashes,
signatures and addresses, same for the third party proof, the NFT
content if not real is stored elsewhere (up to people to decide where)
Additionally you can store in the third party the proof that something
exists (the secret NFT), for example a small copy of the NFT electronic
art, the buyer will get the full version once the deal is done and once
he gets the decryption key, having the NFT for himself only
My proposals are not addressing wider D-stuff topics, supposedly
decentralized, but no
So I don't think that it's a waste of time to change the OP_RETURN max
size, currently it cannot even store +
, probably it's logical to align it to the script size limit
(520B)
Or as I said previously deviant practices can happen, not expensive and
just burning satoshis, which is not a super idea
I don't get why on bitcoin all proposals must always be super
complicate, mine are simple, then take 5mn to read them
Le 02/02/2023 à 15:30, Peter Todd via bitcoin-dev a écrit :
> On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
>> Hi *,
>>
>> Casey Rodarmor's ordinals use the technique of tracking the identity of
>> individual satoshis throughout their lifetime:
>
>
>> I think, however, that you can move inscriptions entirely off-chain. I
>> wrote a little on this idea on twitter already [1], but after a bit more
>> thought, I think pushing things even further off-chain would be plausible.
> On the FAQ of the Ordinals website they discuss off-chain data storage and
> reject the idea:
>
> "Some Ethereum NFT content is on-chain, but much is off-chain, and is
> stored on
> platforms like IPFS or Arweave, or on traditional, fully centralized web
> servers. Content on IPFS is not guaranteed to continue to be available,
> and
> some NFT content stored on IPFS has already been lost. Platforms like
> Arweave
> rely on weak economic assumptions, and will likely fail catastrophically
> when
> these economic assumptions are no longer met. Centralized web servers may
> disappear at any time."
>
> https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
>
> That same FAQ also mention RGB and Taro, which already implements an off-chain
> data model based on my Proofmarshal work. The Ordinals community is well aware
> of the trade-offs and have chosen to publish their data on chain. This is a
> collectables market based on artificial scarcity after all, so some
> conspicuous
> consumption isn't going to be a deterrent.
>
> Frankly, I think further discussion of this on the bitcoin-dev mailing list,
> with the aim of getting Ordinals and others to do something else, is a waste
> of
> everyones' time. The fact that publishing data on chain lets you take
> advantage of the very large network of archival Bitcoin nodes to publish and
> store your data indefinitely is a clear benefit that people will always be
> willing to pay for. The only realistic thing Bitcoin can do to discourage this
> is tweaks to the blocksize and segwit discount, which of course has well-known
> downsides.
>
> There's a clear social/economic benefit to the Ordinals community that the
> complete set of Ordinalds - and their inscriptions - is easy to extract and
> will be available as long as Bitcoin block data itself will be available.
> That's not going away and we should acknowledge that benefit honestly.
>
>> Implementing that is fairly straightforward: you just need a protocol
>> for creating an asset offchain and associating it with an ordinal --
>> nothing needs to happen on-chain at all. That is, you can do something
>> as simple as posting a single nostr message:
>>
>> {
>> "pubkey":
>> "kind": 0,
>> "tags": [
>> ["ord", "txid:vout:sat"]
>> ],
>> "content": [jpeg goes here],
>> "id":
>> "sig":
>> }
> nostr doesn't even have a clear data persistence model. As you know, nostr
> messages are passed around by relays that make no enforceable promise of
> actually keeping those messages or making them available. nostr doesn't have
> any kind of blockchain, making it diffcult for others to
Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
On Thu, Feb 02, 2023 at 09:59:09AM -0500, Greg Sanders wrote: > Hi Peter, > > For the most principled of reasons: > > Because I have to change test vectors everywhere! Specifically, you mean you'd have to change tests that test something is non-standard? -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
Hi Peter, For the most principled of reasons: Because I have to change test vectors everywhere! Greg On Thu, Feb 2, 2023 at 9:52 AM Peter Todd wrote: > On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev > wrote: > > Hello again dev, > > > > Due to the interest in the proposal and the prodding of certain folks, > I've > > written up a short draft BIP of the Ephemeral Anchors idea here: > > > https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki > > > > The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has > been > > refreshed on top of the latest V3 proposal, but the BIP itself is > > unaffected. > > The BIP states that: > > Why OP_2 not OP_TRUE? OP_TRUE is often used in test vectors, using > OP_2 has > the same benefits and none of these common collisions. > > Why is a "collision" harmful in this case? > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev wrote: > Hello again dev, > > Due to the interest in the proposal and the prodding of certain folks, I've > written up a short draft BIP of the Ephemeral Anchors idea here: > https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki > > The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has been > refreshed on top of the latest V3 proposal, but the BIP itself is > unaffected. The BIP states that: Why OP_2 not OP_TRUE? OP_TRUE is often used in test vectors, using OP_2 has the same benefits and none of these common collisions. Why is a "collision" harmful in this case? -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Purely off-chain coin colouring
On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
On the FAQ of the Ordinals website they discuss off-chain data storage and
reject the idea:
"Some Ethereum NFT content is on-chain, but much is off-chain, and is
stored on
platforms like IPFS or Arweave, or on traditional, fully centralized web
servers. Content on IPFS is not guaranteed to continue to be available, and
some NFT content stored on IPFS has already been lost. Platforms like
Arweave
rely on weak economic assumptions, and will likely fail catastrophically
when
these economic assumptions are no longer met. Centralized web servers may
disappear at any time."
https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
That same FAQ also mention RGB and Taro, which already implements an off-chain
data model based on my Proofmarshal work. The Ordinals community is well aware
of the trade-offs and have chosen to publish their data on chain. This is a
collectables market based on artificial scarcity after all, so some conspicuous
consumption isn't going to be a deterrent.
Frankly, I think further discussion of this on the bitcoin-dev mailing list,
with the aim of getting Ordinals and others to do something else, is a waste of
everyones' time. The fact that publishing data on chain lets you take
advantage of the very large network of archival Bitcoin nodes to publish and
store your data indefinitely is a clear benefit that people will always be
willing to pay for. The only realistic thing Bitcoin can do to discourage this
is tweaks to the blocksize and segwit discount, which of course has well-known
downsides.
There's a clear social/economic benefit to the Ordinals community that the
complete set of Ordinalds - and their inscriptions - is easy to extract and
will be available as long as Bitcoin block data itself will be available.
That's not going away and we should acknowledge that benefit honestly.
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>
> {
> "pubkey":
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id":
> "sig":
> }
nostr doesn't even have a clear data persistence model. As you know, nostr
messages are passed around by relays that make no enforceable promise of
actually keeping those messages or making them available. nostr doesn't have
any kind of blockchain, making it diffcult for others to archive messages
completely. Advocating for its use in a protocol designed to support valuable
collectables expected to be owned for a significant amount of time is reckless.
You know, we've been through all this before, years ago when colored coins were
first being discussed. Bitcoin Core devs who knew better would try to
discourage use of the Bitcoin chain for purposes they didn't approve of, by
suggesting solutions that they knew full well didn't really work. Solutions
like using OpenTimestamps inappropriately, alternative publication methods that
failed to provide the same level of security as Bitcoin, etc. It was dishonest
then, and it's disappointing to see a new generation of Bitcoin devs continue
this pattern of dishonesty.
> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.
The RGB protocol already does off-chain custody proofs, and implements NFTs.
You can already use this for real with Iris Wallet - the ownership chain of a
RGB asset is _not_ visible on the blockchain, as ownership does not follow
satoshis. With more work, digital assets can even be transferred with
O(log_2(n)) scaling allowing billions of transfers per second:
https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
This of course is irrelevant to Ordinals, which will never have such a large
market.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
___
Re: [bitcoin-dev] Purely off-chain coin colouring
Hi Anthony,
> I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.
Whole point of inscriptions is to keep something on-chain associated with your
sats so this approach goes against the concept and what makes them interesting
in the first place.
> Implementing that is fairly straightforward: you just need a protocol
for creating an asset offchain and associating it with an ordinal --
nothing needs to happen on-chain at all. That is, you can do something
as simple as posting a single nostr message:
All events may not be permanently stored by Nostr relays. In addition to
rendering inscriptions meaningless, this creates a dependency.
> The "inscription" approach might still be desirable for broadcasting
information that might otherwise be subject to heavy censorship; presuming
that the censoring entity isn't also willing and able to censor bitcoin
itself.
If bitcoin transactions can be censored then we have bigger problems to care
about as bitcoin will have no value without censorship resistance.
Lastly, I would add that inscriptions involve "financial" transactions,
associating sats with image is freedom and got historical reasons for it.
Writing something on paper or drawing an image on copper is not same as doing
it on gold.
Disclaimer: My opinion on inscriptions can be biased because I am working on a
startup that will use inscriptions and satscard(coinkite)
/dev/fd0
floppy disc guy
Sent with Proton Mail secure email.
--- Original Message ---
On Thursday, February 2nd, 2023 at 2:45 PM, Anthony Towns via bitcoin-dev
wrote:
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
>
> On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev
> wrote:
>
> > Briefly, newly mined satoshis are sequentially numbered in the order in
> > which they are mined. These numbers are called "ordinal numbers" or
> > "ordinals". When satoshis are spent in a transaction, the input satoshi
> > ordinal numbers are assigned to output satoshis using a simple
> > first-in-first-out algorithm.
>
>
> This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
>
> When accompanied by a standard for associating some data or right with
> such an identity, this allows the creation of non-fungible tokens (or
> semi-fungible tokens) whose ownership can be transferred by a bitcoin
> transaction.
>
> The proposed BIP doesn't document any method for associating data or a
> right with an ordinal, but the "ord" tool defines "inscriptions" to fill
> this gap [0], providing a way of including mime-encoded data in a taproot
> witness. To make such an inscription, two transactions are required:
> one paying some sats to a special scriptPubKey that commits to the
> inscribed data, and a second that spends those sats to the owner of the
> newly inscribed ordinal, and in so doing revealing the full inscription.
>
> [0] https://docs.ordinals.com/inscriptions.html
>
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
>
> [1] https://twitter.com/ajtowns/status/1619554871166013441
>
> In particular, rather than looking at it as being the owner of the sats
> that inscribes some content on those sats (analogously to signing a $100
> bill [2]), you could look at it as saying "the owner of this thing is
> whoever owns this particular sat" (eg instead of "whoever owns this
> share certificate is a shareholder", it's "whoever owns the $1 bill with
> serial number X is a shareholder").
>
> [2]
> https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
>
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>
> {
> "pubkey":
>
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id":
>
> "sig":
>
> }
>
> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.
>
> [3] If the satoshi was lost to fees at some
Re: [bitcoin-dev] Purely off-chain coin colouring
Hi AJ and List,
This reminds me of a series of blog posts Peter Todd wrote a few years
ago about using "single use seals" for tracking (fungible) assets
anchored to Bitcoin[0]. I believe that the RBG Protocol Project and Taro
are both using the same underlying principle.
Having the actual application data offchain, but with a commitment to a
UTXO and then using Bitcoin only as a proof-of-publication system to
prevent double-spends seems like a really good idea. As you point out,
in addition to being cheaper and more scalable, it means that not
everyone on the network has to know that there's an asset involved. It
just looks like plain old bitcoin transfers.
A lot of people have written about or are (I think) working on
implementations of this idea. I really like your suggestion of using
nostr. Clients can keep the asset metadata chains locally in their
client and (re)broadcast them to application-specific nostr relays, or
to general public relays depending on application needs. Maybe there's a
marketplace application that has its own relays and also broadcasts
asset metadata to relays used by popular gallery systems. Or maybe your
client just sends to any relay it sees that doesnt have the event. Big
design space there.
- rijndael
0: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
On 2/2/23 4:15 AM, Anthony Towns via bitcoin-dev wrote:
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
>
> On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev
> wrote:
>> Briefly, newly mined satoshis are sequentially numbered in the order in
>> which they are mined. These numbers are called "ordinal numbers" or
>> "ordinals". When satoshis are spent in a transaction, the input satoshi
>> ordinal numbers are assigned to output satoshis using a simple
>> first-in-first-out algorithm.
> This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
>
> When accompanied by a standard for associating some data or right with
> such an identity, this allows the creation of non-fungible tokens (or
> semi-fungible tokens) whose ownership can be transferred by a bitcoin
> transaction.
>
> The proposed BIP doesn't document any method for associating data or a
> right with an ordinal, but the "ord" tool defines "inscriptions" to fill
> this gap [0], providing a way of including mime-encoded data in a taproot
> witness. To make such an inscription, two transactions are required:
> one paying some sats to a special scriptPubKey that commits to the
> inscribed data, and a second that spends those sats to the owner of the
> newly inscribed ordinal, and in so doing revealing the full inscription.
>
> [0] https://docs.ordinals.com/inscriptions.html
>
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
>
> [1] https://twitter.com/ajtowns/status/1619554871166013441
>
> In particular, rather than looking at it as being the owner of the sats
> that inscribes some content on those sats (analogously to signing a $100
> bill [2]), you could look at it as saying "the owner of this thing is
> whoever owns this particular sat" (eg instead of "whoever owns this
> share certificate is a shareholder", it's "whoever owns the $1 bill with
> serial number X is a shareholder").
>
> [2]
> https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
>
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>
>{
> "pubkey":
> "kind": 0,
> "tags": [
>["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id":
> "sig":
>}
>
> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.
>
> [3] If the satoshi was lost to fees at some point, you could continue to
> follow ownership by including an entire block in the custody chain.
> But seems better to just consider it as "abandoned" or "lost to the
> public domain" at that point.
>
> This approach allows all the "inscription" data to be entirely off-chain,
> the only thing that requires a transaction on-chain is
Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Hello Christopher, I think if the protocol that you were designing always had <80 bytes, I'd prefer the OP_RETURN. I think the "witness envelope" has two major disadvantages compared to the OP_RETURN method: 1. You need to first spend to he address that commits to the script that encodes your data payload. So you have a two step process of first spending to a "commitment" address and then a second spend to "reveal" your payload. You can CPFP to get them both into the same block, but its still two transactions, so more cost, etc. 2. Because of the two step process in (1), if for some reason you were unable to get the "reveal" transaction into a block (for example there's widespread censorship of transactions that match the format of the "reveal" script), then you might have money that's stuck in the "commit" stage of the protocol. The way out of this would be to get your money out via the keypath or another tapleaf, but then you need to spend money to cancel a step in your protocol. Of course there could be widespread censorship of your OP_RETURNs too, but you don't have to spend funds on the cancellation spends. I think (2) is actually a pretty weak argument because as we saw in the full-rbf discussion, as long as there's some threshold number of nodes in the network that relay transactions to miners, you can probably find a path to a miner (IIRC the number was on the order of 15% of the network?). So I think the big reason to pick OP_RETURN over the witness embedding is that you save a transaction and possibly some failure-recovery/cancellation logic. Obviously if your data is larger than 80 bytes, then you probably want to do the witness-embedding method. If your data smaller, then a pay-to-contract tweak probably the best thing from a space and fingerprinting perspective. - rijndael On 1/31/23 7:46 PM, 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 > > 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] Purely off-chain coin colouring
In your system what is the off-chain mechanism? And what prevent a thief
to steal your NFT?
I have submitted several time "A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
It's more simple, the NFT (whether real or electronic) is referenced by
a initial hash (which is not the hash for example of your jpeg file
because easy to fake) and then get a final reference which is the hash
of the initial hash
The idea is that the real owner must prove that he has the knowledge of
the initial hash (for example luxury bag, you print the double hash on
it, and give the initial hash to the buyer, if the owner/seller can't
prove that he knows the inital hash, the bag is stolen or counterfeit
(with the double hash))
The NFT owner references the NFT signed by him in some trusted third
party allowing a timestanp (wayback machine for example), it proves that
he is the first one to have the knowledge of the double hash, so a thief
cannot intercept the "minting" transaction (if any because not really
necessary since the public key of the owner is known from the third
party) and steal the NFT for himself or do/replay a transaction with
this NFT, minting it or selling it several time
A third party is involved but it remains decentralized
Then the NFT owner and buyer exchange some information like for
lightning and do one transaction on Bitcoin storing the deal, see the
details in the proposals depending on what kind of deal occur between
the buyer and the seller, like lightning, if someone cheats, then he
loses his bitcoin
It's minimal, understandable, secured, decentralized and not expensive,
that's why I don't see very well why to complicate with ordinals
The proposal envisions the concept of "secret" NFTs also
The continuation of this proposal is "A Universal Coin Swap system based
on Bitcoin" https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
It's simple also, you go from Decentraland to the Sandbox but don't have
SAND and want to pay with MANA, you agree on a MANA/SAND deal with the
seller which is stored in Bitcoin signed by both, then you pay with
MANA, other use cases are described in the proposal
Note: both proposals need to be modified since I thought OP_RETURN max
size was 512B and it is in fact 80B, which does not work for all cases
Le 02/02/2023 à 10:15, Anthony Towns via bitcoin-dev a écrit :
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
>
> On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev
> wrote:
>> Briefly, newly mined satoshis are sequentially numbered in the order in
>> which they are mined. These numbers are called "ordinal numbers" or
>> "ordinals". When satoshis are spent in a transaction, the input satoshi
>> ordinal numbers are assigned to output satoshis using a simple
>> first-in-first-out algorithm.
> This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
>
> When accompanied by a standard for associating some data or right with
> such an identity, this allows the creation of non-fungible tokens (or
> semi-fungible tokens) whose ownership can be transferred by a bitcoin
> transaction.
>
> The proposed BIP doesn't document any method for associating data or a
> right with an ordinal, but the "ord" tool defines "inscriptions" to fill
> this gap [0], providing a way of including mime-encoded data in a taproot
> witness. To make such an inscription, two transactions are required:
> one paying some sats to a special scriptPubKey that commits to the
> inscribed data, and a second that spends those sats to the owner of the
> newly inscribed ordinal, and in so doing revealing the full inscription.
>
> [0] https://docs.ordinals.com/inscriptions.html
>
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
>
> [1] https://twitter.com/ajtowns/status/1619554871166013441
>
> In particular, rather than looking at it as being the owner of the sats
> that inscribes some content on those sats (analogously to signing a $100
> bill [2]), you could look at it as saying "the owner of this thing is
> whoever owns this particular sat" (eg instead of "whoever owns this
> share certificate is a shareholder", it's "whoever owns the $1 bill with
> serial number X is a shareholder").
>
> [2]
> https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
>
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>
> {
> "pubkey":
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
>
Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Thanks, then this limitation should be rethought I think (see the email I just sent replying to the coloured thread) Because it forces people to store in witness (less easy to track/show I believe) or adopt some deviant behavior (like storing in addresses where the utxo will remain unspendable forever) Le 02/02/2023 à 12:49, Peter Todd a écrit : > On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote: >> As far as I can read nobody replied to the initial question: what is >> considered as good/best practice to store in Bitcoin? > Your answer is beyond not putting unspendable data in the UTXO set, the exact > details don't really matter. Do what makes sense for your specific > application. > >> Reiterating my question: what are the current rules for OP_RETURN, max >> size and number of OP_RETURN per tx > Max 80 bytes, one OpReturn output per tx. > > This of course is the standardness rule. With a miner willing to mine non-std > transactions anything goes. > -- 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] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
As far as I can read nobody replied to the initial question: what is considered as good/best practice to store in Bitcoin? Reiterating my question: what are the current rules for OP_RETURN, max size and number of OP_RETURN per tx Le 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit : > On Wed, Feb 01, 2023 at 02:02:41PM +, Andrew Poelstra wrote: >> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote: >>> >>> 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? >>> >> This is a technical nit, but the reason is that is limited to 520 >> bytes (and I believe, 80 bytes by standardness in Taproot), so if you >> are pushing a ton of data and need multiple pushes, it's more efficient >> to use FALSE IF ... ENDIF since you avoid the repeated DROPs. > Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's > not executed. But in this example we're just talking about 64 bytes, so that > limit isn't relevant and OpPush OpDrop should be sufficient. > > Specifically for more than 520 bytes you run into the the > MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all > scripts regardless of standardness at script execution: > >// >// Read instruction >// >if (!script.GetOp(pc, opcode, vchPushValue)) >return set_error(serror, SCRIPT_ERR_BAD_OPCODE); >if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE) >return set_error(serror, SCRIPT_ERR_PUSH_SIZE); > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- 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] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote: > As far as I can read nobody replied to the initial question: what is > considered as good/best practice to store in Bitcoin? Your answer is beyond not putting unspendable data in the UTXO set, the exact details don't really matter. Do what makes sense for your specific application. > Reiterating my question: what are the current rules for OP_RETURN, max > size and number of OP_RETURN per tx Max 80 bytes, one OpReturn output per tx. This of course is the standardness rule. With a miner willing to mine non-std transactions anything goes. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ 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
On Wed, Feb 01, 2023 at 02:02:41PM +, Andrew Poelstra wrote: > On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote: > > > > > > 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? > > > > This is a technical nit, but the reason is that is limited to 520 > bytes (and I believe, 80 bytes by standardness in Taproot), so if you > are pushing a ton of data and need multiple pushes, it's more efficient > to use FALSE IF ... ENDIF since you avoid the repeated DROPs. Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's not executed. But in this example we're just talking about 64 bytes, so that limit isn't relevant and OpPush OpDrop should be sufficient. Specifically for more than 520 bytes you run into the the MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all scripts regardless of standardness at script execution: // // Read instruction // if (!script.GetOp(pc, opcode, vchPushValue)) return set_error(serror, SCRIPT_ERR_BAD_OPCODE); if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE) return set_error(serror, SCRIPT_ERR_PUSH_SIZE); -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Purely off-chain coin colouring
Hi *,
Casey Rodarmor's ordinals use the technique of tracking the identity of
individual satoshis throughout their lifetime:
On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> Briefly, newly mined satoshis are sequentially numbered in the order in
> which they are mined. These numbers are called "ordinal numbers" or
> "ordinals". When satoshis are spent in a transaction, the input satoshi
> ordinal numbers are assigned to output satoshis using a simple
> first-in-first-out algorithm.
This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
When accompanied by a standard for associating some data or right with
such an identity, this allows the creation of non-fungible tokens (or
semi-fungible tokens) whose ownership can be transferred by a bitcoin
transaction.
The proposed BIP doesn't document any method for associating data or a
right with an ordinal, but the "ord" tool defines "inscriptions" to fill
this gap [0], providing a way of including mime-encoded data in a taproot
witness. To make such an inscription, two transactions are required:
one paying some sats to a special scriptPubKey that commits to the
inscribed data, and a second that spends those sats to the owner of the
newly inscribed ordinal, and in so doing revealing the full inscription.
[0] https://docs.ordinals.com/inscriptions.html
I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.
[1] https://twitter.com/ajtowns/status/1619554871166013441
In particular, rather than looking at it as being the owner of the sats
that inscribes some content on those sats (analogously to signing a $100
bill [2]), you could look at it as saying "the owner of this thing is
whoever owns this particular sat" (eg instead of "whoever owns this
share certificate is a shareholder", it's "whoever owns the $1 bill with
serial number X is a shareholder").
[2]
https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
Implementing that is fairly straightforward: you just need a protocol
for creating an asset offchain and associating it with an ordinal --
nothing needs to happen on-chain at all. That is, you can do something
as simple as posting a single nostr message:
{
"pubkey":
"kind": 0,
"tags": [
["ord", "txid:vout:sat"]
],
"content": [jpeg goes here],
"id":
"sig":
}
You can prove current ownership of the message by showing a custody
chain, that is the transaction specified by "txid" in the "ord" tag,
then every transaction that spent the given sat, until you get to one
that's still in the utxo set [3]. You don't need to provide witness
data or validate any of these tx's signatures, as that is already
implicit in that you end up at a tx in the utxo set. Just calculating
the txids and comparing against the output containing the sat you're
interested in is sufficient.
[3] If the satoshi was lost to fees at some point, you could continue to
follow ownership by including an entire block in the custody chain.
But seems better to just consider it as "abandoned" or "lost to the
public domain" at that point.
This approach allows all the "inscription" data to be entirely off-chain,
the only thing that requires a transaction on-chain is transferring
ownership to someone else. That allows the NFT's existance can be kept
entirely private if desired; it also makes it cheap to create a new NFT
(you don't need to pay any on-chain fees at all); and it doesn't impose
an outsized overhead on people who aren't interested in your inscriptions,
but may be interested either in bitcoin per se, or in other inscriptions.
For things that have real intrinsic value -- equity rights in a company,
bragging rights for supporting an artist, etc -- this seems like it's
probably a viable approach: owners can "self-custody" all the information
about the things they own without having to rely on third parties,
transfers are no more censorable than any other bitcoin transaction
(especially if the association of the NFT with some particular sat is
not widely known), etc.
The "inscription" approach might still be desirable for broadcasting
information that might otherwise be subject to heavy censorship; presuming
that the censoring entity isn't also willing and able to censor bitcoin
itself. It's not clear that there's any "rights" to be owned for such a
case -- you can't buy the right to be the person that first published
it, and the point of widely broadcasting the information is so it's
not a secret only known to a few anymore. Also, claiming ownership of
such information would presumably make you a target for the censor,
even if just as an example for others. So I'm dubious of the value of
associating an inscription with an ordinal for that use case.
It's also
[bitcoin-dev] Costless bribes against time-sensitive protocols
## Intro Most of it feels like implicit knowledge, but I couldn't find anything written so here it is. The ideas towards anchor outputs and the conclusions probably have some new perspectives. This post is about the game-theoretic security of time-sensitive protocols if miners are open to censorship for a reward. To become practical, the following has to happen. 1) a substantial hashrate has to be willing to participate in this behaviour, according to the known formula from the Whitepaper. The more blocks it takes to attack (defined by a particular protocol configuration and could be tuned), the exponentially higher % hashrate is required. 2) a communication layer is required to send bribes to these miners. This could be a private transaction relay network, or a mempool allowing still-time-locked transactions. It could be even an announcement board (e.g., submitting raw txs under a Twitter hashtag and inviting miners to monitor it). 3) a bribe transaction construction (will be explained later). In this post, I talk about the case when: 1. a significant hashrate (e.g., 95%+) is open to take these bribes; 2. but miners don't trust each other; 3. and there is no reorgs. Assumption \*(2) is more nuanced. What I mean here is roughly "miner X would rather take an immediate gain than commit to a lenghty scenario where many miners coordinate to take reward on behalf of each other and then distribute it accordingly to the hashrate". The game theory of this assumption should be better defined in the future. We will see, how widely known tweaks lift the bar for (2) and (3) and how this could be further improved. *A special case of this scenario is miners withholding Alice's transaction to force her to bump fees, even if Bob hasn't submitted a bribe. Here I assume miners won't do it unless there is an external incentive (Bob's bribe), although this issue is also interesting.* ## Simple opcode-based construction The simplest time-sensitive two-party contract is PowSwap (a bet on the future block issuance rate), a single on-chain UTXO with the following spending conditions: - Alice’s key can spend if height=H is reached; - Bob’s key can spend if Time=T is reached. Say H is approaching quickly, and T is far behind. Bob now uses a private mining relay to submit his non-mineable transaction paying e.g. half of the UTXO value towards fees. Alice has two problems: 1) she can’t figure out why her transaction isn’t mined and how much fee to overpay; 2) the attack is free for Bob (he has nothing to lose), while Alice loses everything up to the full UTXO value. ## Simple nLockTime-based construction If parties use pre-signed transactions with nLockTime (instead of the opcodes), Bob’s fee can be pre-signed to a rather low value, so that Alice can reasonably overbid it without much loss (she probably doesn't even need to take any action). Bob can, however, bump the fee by creating a CPFP transaction with super-high fee. All it requires now is submitting twice as much data to the private mining relay (and burning slightly more in fees). ## nLockTime-based construction with OP_CSV output If Bob’s output can’t be spent right away, but is forced to be deterred to even one block in the future, it makes taking this bribe not rational: a censoring miner can’t be sure about the deferred reward (remember, miners don't trust each other). At the same time, mining the honest transaction and taking its fee is always available earlier. Smart contracts could possibly make it rational for miners (see [1]), e.g. by allowing Bob to allocate the bribe based on the historic hashrate distribution linked to coinbase pubkeys. At the same time, this approach makes dynamic fee management impossible. ## Anchor outputs Anchor outputs allow bringing external capital for fee management while locking internal capital. Bob can use this capital for a bribe. If the attack fails, Bob's external capital remains safe, so this is not so bad for Bob. The attack can be more costly if this external capital was claimable: - by Alice: e.g., Alice can steal a (covenanted) anchor output if it's revealed before Bob's nLockTime makes it mineable (requires her to monitor the private relay); - or by miners, e.g. if Alice forces Bob, at contract setup, to use a reverse time-lock (the anchor can be stolen by miner if seen before time=T); or if mining Alice's honest transaction also allows miners to take Bob's fee output (e.g., Alice's honest transaction *could* act as a parent/preimage, conditionally, although this may require reverse time-locking Alice to protect Bob...) *Ephemeral anchors doesn’t do much w.r.t. our trade-off, as it is a mempool-oriented thing.* ## Lightning Lightning is different from the described protocol in two things: 1) It relies on intermediate transactions (e.g., Commitment in Poon-Dryja); 2) Usually both parties have some balance in the channel. I believe that (1) doesn’t change
