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

[Peter Todd via bitcoin-dev]

On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev 
 wrote:
>Since bytes in the witness are cheaper than bytes in the script pubkey,
>there is a crossover point in data size where it will simply be cheaper to
>use witness data.  Where that crossover point is depends on the finer
>details of the overhead of the two methods, but you could make some
>reasonable assumptions.  Such a calculation could form the basis of a
>reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
>it would at least be coherent.

I don't think it's worth the technical complexity trying to carefully argue a 
specific limit. Let users decide for themselves how they want to use OpReturn.
___
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 February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev 
 wrote:
>I don't know, what number would you advise? When I made the
>bitcoin-transactions nodejs module some years ago the limit (from the
>specs) was 512B

1) Allowing only one OpReturn output causes problems trying to compose 
different uses of OpReturn. We should allow any number of OpReturn outputs.

2) There's no reason to put a size limit given all the other ways people can 
publish data, including with a 75% discount. Let the fee market deal with it.
___
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

[Russell O'Connor via bitcoin-dev]

Since bytes in the witness are cheaper than bytes in the script pubkey,
there is a crossover point in data size where it will simply be cheaper to
use witness data.  Where that crossover point is depends on the finer
details of the overhead of the two methods, but you could make some
reasonable assumptions.  Such a calculation could form the basis of a
reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
it would at least be coherent.

On Sat., Feb. 4, 2023, 18:17 Aymeric Vitte via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't know, what number would you advise? When I made the
> bitcoin-transactions nodejs module some years ago the limit (from the
> specs) was 512B
>
> It's not a fork, super easy to do
>
> And necessary because bitcoin on ground of I don't know what rule
> allowing the IF/ENDIF "unlimited" storage just mimics ethereum for the
> worse, and is again quite dubious to use
>
>
> Le 04/02/2023 à 23:18, Christopher Allen a écrit :
> > 520 because that is a similar limit in taproot? Some multiple of
> > hash+signature+metadata to satisfy others (that still might not be
> > satisfied by any choice).
>
>
> ___
> 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] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Aymeric Vitte via bitcoin-dev]

I don't know, what number would you advise? When I made the
bitcoin-transactions nodejs module some years ago the limit (from the
specs) was 512B

It's not a fork, super easy to do

And necessary because bitcoin on ground of I don't know what rule
allowing the IF/ENDIF "unlimited" storage just mimics ethereum for the
worse, and is again quite dubious to use


Le 04/02/2023 à 23:18, Christopher Allen a écrit :
> 520 because that is a similar limit in taproot? Some multiple of
> hash+signature+metadata to satisfy others (that still might not be
> satisfied by any choice).


___
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

[Christopher Allen via bitcoin-dev]

On Sat, Feb 4, 2023 at 12:55 PM Aymeric Vitte  wrote:

> Thanks Christopher, then I understand the process:
>
> - I must issue a PR where I switch 80 to another number, even if I am not
> a C/C++ expert it looks easy
>
Yes, this would be an easy PR, at least to start. I suspect that
longer-term, you'd need to draft some assistance to make it turn on/off
from when the bitcoin daemon is initialized. But that could wait until the
conversation has progressed some.

The harder part will be writing the initial comment, where you should
carefully explain the rationale, link to some existing conversations, try
to point out in advance the obvious objections and rationale despite them,
and explain your particular choice of number — 520 because that is a
similar limit in taproot? Some multiple of hash+signature+metadata to
satisfy others (that still might not be satisfied by any choice).

> - I  must stay calm and answer all outstanding concerns about this trivial
> change
>
> - Since I am not as clever as the bitcoin devs I must be ready to revise
> my PR at any time
>
> - This could lead for the change to be from 80B to 82.xB where x comes
> from a non understandable crypto formula
>
> - I must evangelize the change worldwide
>
> - Once accepted, I must collude (pay) with the nodes/miners so they update
> at a subtile block height decided by the community
>
That is true for forks, but I don't think this is a fork. It might require
resolving some mempool issues (for instance for mining pools). But for it
to become non-optional, you'll need to demonstrate that miners and full
nodes have turned it on. Thus that is more a conversation than "collusion
(pay)".

> And then I must pray that the PR does not survive myself
>
> Looks like a pretty straight forward process.
>
I've seen worse. I co-authored TLS 1.0 (6 years) and DID 1.0 (5 years).

> I am on this list since quite some time, so, seriously, this change is
> needed, or, as I said before, deviant behaviours will happen, because the
> "witness trick" or others do not work at all, and are clearly similar to
> ethereum messy stuff
>
You have at least Concept ACK from me! ;-)

-- 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

[Aymeric Vitte via bitcoin-dev]

Thanks Christopher, then I understand the process:

- I must issue a PR where I switch 80 to another number, even if I am
not a C/C++ expert it looks easy

- I  must stay calm and answer all outstanding concerns about this
trivial change

- Since I am not as clever as the bitcoin devs I must be ready to revise
my PR at any time

- This could lead for the change to be from 80B to 82.xB where x comes
from a non understandable crypto formula

- I must evangelize the change worldwide

- Once accepted, I must collude (pay) with the nodes/miners so they
update at a subtile block height decided by the community

And then I must pray that the PR does not survive myself

Looks like a pretty straight forward process

I am on this list since quite some time, so, seriously, this change is
needed, or, as I said before, deviant behaviours will happen, because
the "witness trick" or others do not work at all, and are clearly
similar to ethereum messy stuff


Le 04/02/2023 à 19:54, Christopher Allen a écrit :
> On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte  > wrote:
>
> What is the official bitcoin channel to request the OP_RETURN size
> change? (press often mentions that ethereum is good to manage
> changes and bitcoin a complete zero.
>
> Here is the simplified version:
>
> Most of these changes start with discussions like these, but then are
> moved concretely to a PR to bitcoin-core with the code changes (in
> this case there is no fork so pretty easy) and an introductory comment
> pointing to discussions elsewhere. 
>
> The conversation will also move to the PR itself. Part of the
> challenge now is getting review of your PRs - you’ll need to
> evangelize some and/or have social capital in the bitcoin community to
> get sufficient ACKs to your PR (and some NACKs which you will calmly
> addres), and someone will likely point something out you missed, so
> you revise the PR. 
>
> At some point hopefully there looks like all reasonable objections
> have been addressed.
>
> If there is enough interest and few objections there will be
> discussions by the community & maintainers to merge it. It is this
> last part that isn’t very transparent, especially for even a good
> proposal. The maintainers, based on their sense of the community’s
> interest and consensus, must choose when to say it is ready, and then
> decide when and to which release they wish to merge it.
>
> They often start by requesting you to revise your changes to be off by
> default, and be turned on as an option for a specific release. Often
> PR contributors know this is coming and include it.
>
> Even once it is released, this type of change can only happen after
> sufficient miners and nodes update to the release and turn it on. If
> sufficient do, then the maintainers evaluate when to have the feature
> on by default.
>
> These articles offers more perspective: 
>
>  *
>
> https://unchained.com/blog/contributing-bitcoin-core-patience/
>
>  *
>
> 
> https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core
>
>  *
>
> https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365
>
> — Christopher Allen 
>
>

-- 
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

[Christopher Allen via bitcoin-dev]

On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte  wrote:

> What is the official bitcoin channel to request the OP_RETURN size change?
> (press often mentions that ethereum is good to manage changes and bitcoin a
> complete zero.
>
Here is the simplified version:

Most of these changes start with discussions like these, but then are moved
concretely to a PR to bitcoin-core with the code changes (in this case
there is no fork so pretty easy) and an introductory comment pointing to
discussions elsewhere.

The conversation will also move to the PR itself. Part of the challenge now
is getting review of your PRs - you’ll need to evangelize some and/or have
social capital in the bitcoin community to get sufficient ACKs to your PR
(and some NACKs which you will calmly addres), and someone will likely
point something out you missed, so you revise the PR.

At some point hopefully there looks like all reasonable objections have
been addressed.

If there is enough interest and few objections there will be discussions by
the community & maintainers to merge it. It is this last part that isn’t
very transparent, especially for even a good proposal. The maintainers,
based on their sense of the community’s interest and consensus, must choose
when to say it is ready, and then decide when and to which release they
wish to merge it.

They often start by requesting you to revise your changes to be off by
default, and be turned on as an option for a specific release. Often PR
contributors know this is coming and include it.

Even once it is released, this type of change can only happen after
sufficient miners and nodes update to the release and turn it on. If
sufficient do, then the maintainers evaluate when to have the feature on by
default.

These articles offers more perspective:

   -

   https://unchained.com/blog/contributing-bitcoin-core-patience/
   -


   
https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core
   -

   https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365

— 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

[Aymeric Vitte via bitcoin-dev]

I don't get very well where all the current (other threats) discussions
are going, storing on-chain is absurd

It's absurd also to flood bitcoin with several useless transactions to
store in witness or others, looks like ethereum messy stuff

What is not absurd is to store the proofs that can be checked using a
notorious third party/sidechain but you need more than 80B

What is the official bitcoin channel to request the OP_RETURN size
change? (press often mentions that ethereum is good to manage changes
and bitcoin a complete zero)

As a very bad solution, I think I would be willing to store data in
addresses, with one single transaction, as people did in the past, then
burning bitcoins but still not expensive, or less than several txs,
because schemes involving several transactions do not work very well

In any case, we see the problem, then people will invent something and
most likely it will not comply at all with bitcoin good practices


Le 04/02/2023 à 15:11, Kostas Karasavvas via bitcoin-dev a écrit :
>
>
> On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev
>  > wrote:
>
> On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev
>  > wrote:
>
> I think the right way so people don't invent deviant things is to
> increase the size of OP_RETURN, I don't get this number of
> 80B, you can
> hardly store a signature (of what?) in there and not the
> "what" if the
> "what" is a hash for example
>
>
> Updating the size of OP_RETURN to support a hash (or two), a
> signature, and maybe a few more bytes for metadata, would be very
> helpful in a number of scenarios. It is still a limit but a
> reasonable one. Otherwise, I think we'll have a lot more
> inscription-style scenarios.
>
>
> I wouldn't be against an increase in OP_RETURN but I don't think it
> will make any difference in how often inscription-style use cases will
> be used. They will be used primarily for much larger datasets than,
> say 120 bytes, and they also have the segwit discount.
>
>
> ___
> 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] A proposal for Full RBF to not exclude Zero Conf use case

[Peter Todd via bitcoin-dev]

On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote:
> We have standard commercial information about the payment processors, non
> custodial liquidity providers and merchants which become our clients - we
> do not have any kyc/aml information or telephone number on who is sending
> our clients the bitcoin for deposit.  For us these are just bitcoin Trx
> which our clients choose to benefit from 0-conf deposit recognition. Our
> service is provided via API with the only information our clients share
> with us, regarding a specific bitcoin transaction, being public bitcoin
> information like trx hash and output address.

You know who your clients are, and thus every request for information on a
transaction is reasonably likely to be a deposit associated with the client who
requested it. Learning what addresses are associated with what entity is a
significant benefit to Chainalysis operations, and there's every reason to
expect that the data you learn will either be sold or leaked to Chainalysis
companies.

-- 
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

[Peter Todd via bitcoin-dev]

On Fri, Feb 03, 2023 at 09:07:29PM -0500, Greg Sanders wrote:
> I'm not particularly persuaded, but also not wedded to either idea.
> 
> Fixed up tests for the OP_TRUE case here:
> https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true

Thanks.

Looking through that, I think a lot of those test cases don't actually need to
be changed to OP_2, as they aren't trying to test anything related to
standardness.

-- 
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] Ordinal Inscription Size Limits

[Kostas Karasavvas via bitcoin-dev]

On Fri, Feb 3, 2023 at 10:17 PM Melvin Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> napsal:
>
>> I'm curious what opinions exist and what actions might be taken by core
>> developers regarding storing unlimited amounts of NFT (or other?) content
>> as witness data (https://docs.ordinals.com/inscriptions.html). The
>> ordinal scheme is elegant and genius IMHO, but when I think about the
>> future disk use of all unpruned nodes, I question whether unlimited storage
>> is wise to allow for such use cases. Wouldn't it be better to find a way to
>> impose a size limit similar to OP_RETURN for such inscriptions?
>>
>>
Personally, I was always considering future disk use at full capacity
anyway (and planning accordingly). Even without inscriptions/ordinals that
would happen. The latter competes for block space and are paying tx fees so
I don't see it as that much harmful (esp.now that it is out there... I
would be more conservative if we were talking about introducing it!).



> I think it would be useful to link a sat to a deed or other legal
>> construct for proof of ownership in the real world, so that real property
>> can be transferred on the blockchain using ordinals, but storing the
>> property itself on the blockchain seems nonsensical to me.
>>
>
> Low tech solution: miners charge a premium for storing images in the block
> chain.  Say 2x, 5x, 10x.
>
> This encourages bitcoin to be used as a financial network, while
> increasing the security budget.
>

How would you enforce this technically?  I only see it feasible if miners
agree by social contract.
___
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

[Kostas Karasavvas via bitcoin-dev]

On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I think the right way so people don't invent deviant things is to
>> increase the size of OP_RETURN, I don't get this number of 80B, you can
>> hardly store a signature (of what?) in there and not the "what" if the
>> "what" is a hash for example
>>
>
> Updating the size of OP_RETURN to support a hash (or two), a signature,
> and maybe a few more bytes for metadata, would be very helpful in a number
> of scenarios. It is still a limit but a reasonable one. Otherwise, I think
> we'll have a lot more inscription-style scenarios.
>

I wouldn't be against an increase in OP_RETURN but I don't think it will
make any difference in how often inscription-style use cases will be used.
They will be used primarily for much larger datasets than, say 120 bytes,
and they also have the segwit discount.
___
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

[alicexbt via bitcoin-dev]

Hi Anthony,

> As far as salience/notability goes, personally, I'd see ownership of
inscriptions as a negative indicator; "hey, when I was young and foolish I
wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
permanent cost for everyone trying to use bitcoin in future". That's not
unforgivable; people do all sorts of foolish things, and bitcoin's meant
to survive attacks, not just foolish pranks. But it doesn't seem like
something to brag about or encourage, either, at least if you want bitcoin
to be a monetary network that's usable in practice by many/most people.

Moving transactions off-chain because of emotions or personal opinions does not 
make sense. 
Everyone running a bitcoin node is aware of block limits and they could be 
filled with different type of transactions including [non-inscription txs][0] 
that use witness for complex scripts.

> And if
a public site like ordinals.net is willing to store all the inscriptions
that might be on the blockchain, they could just as easily store the
same amount of off-chain digital assets.

[Ord explorer][1] is open source and gets inscriptions from blockchain.

> Obviously blockchains aren't the only "scarce" good out there. If scarcity
is your goal, there's two very easy ways to make your own scarcity. 

Using pow doesn't make nostr relays "scarce". Its mainly used to avoid spam but 
some spammers on nostr have proved it isn't enough. 

> then in the off-chain world, they would look like two events:

Nostr relays do not guarantee that these events will be stored [forever][2].

> As I've said above, the off-chain approach seems
much better aligned with incentives to me, with the people who gain the
benefit from that association paying the cost of preserving it.

Cost for running bitcoin node do not change with inscriptions and do not depend 
on the content or intent of any bitcoin transaction. It is a permissionless 
network and users can decide how to use money and blockspace.

Campaigns to censor such transactions or other efforts to move them off-chain 
are creating a slippery slope that could affect bitcoin more than some 
inscriptions. If Casey is harassed enough on social media and ord project moves 
inscriptions off-chain, there would be forks of it doing it on-chain.


[0]: https://twitter.com/mononautical/status/1621663167582437376
[1]: https://github.com/casey/ord
[2]: https://twitter.com/damusapp/status/1621431556048035841


dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, February 4th, 2023 at 4:08 PM, Anthony Towns via bitcoin-dev 
 wrote:


> On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev 
> wrote:
> 
> > Apologies for posting! I've tried to keep discussion of ordinals and
> > inscriptions off-list, because I consider it to be of little relevance to
> > general Bitcoin development.
> 
> 
> Anything that potentially uses up a large percentage of blockspace seems
> pretty relevant to general Bitcoin development to me...
> 
> > AJ Towns writes:
> > 
> > > 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.
> 
> 
> I guess I should have explained why I think moving things off-chain is
> a worthwhile goal. Riffing off:
> 
> > Another issue is salience and scarcity, as has been mentioned. Off-chain
> > content is unbounded, and thus less scarce. Usually, we design for
> > efficiency, volume, and scale. For NFT designs, which are intended to be
> > collectable, this is in some ways counterproductive.
> 
> 
> "scarce" has two meanings -- one is that there's not much of it, the
> other is that it's highly valued (or a third, where it's is consistently
> underpriced and unavailable even for people who'd pay more, but that
> hopefully doesn't apply).
> 
> I think for bitcoin's blockspace, we ideally only want the first of
> these to be true. We want small blocks because that makes it cheap to
> verify bitcoin, which reduces the need to trust third parties and aids in
> decentralisation. But we don't want blockspace to be especially valuable,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.
> 
> Moving things off-chain helps with both these goals: it doesn't make it
> harder to validate bitcoin, and it also decreases demand for blockspace,
> making it cheaper for those cases where things can't be moved off-chain.
> 
> As a result of this approach, bitcoin blockspace is currently quite
> cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in
> a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a
> luxury purchase.
> 
> If you keep jpegs on-chain, as far as I can see, there's three outcomes:
> 
> * blockspace stays relatively cheap, and there's no "scarcity" benefit to
> minting via on-chain inscriptions; it's

Re: [bitcoin-dev] Purely off-chain coin colouring

[Aymeric Vitte via bitcoin-dev]

I still don't see in both proposals how you avoid that someone steals
your NFT, double mint it or sell it several time, because the thief can
do the very same that what your are describing, a hash of the content is
not enough, you can slightly modify an image or a document and it gives
another hash, as far as I know in all existing systems today there are
zero protection against this, I am quoting also Moxie's experience in my
proposals

That's why I am proposing the third party with a timestamp and a double
hash not related to the content itself, and the secret NFT, I don't see
the point to buy millions some electronic art that everyone can get for free

Anyway, I mostly consider that a NFT is a real good that you buy in the
metaverse, not only an electronic thing


Le 04/02/2023 à 11:38, Anthony Towns via bitcoin-dev a écrit :
> On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev 
> wrote:
>> Apologies for posting! I've tried to keep discussion of ordinals and
>> inscriptions off-list, because I consider it to be of little relevance to
>> general Bitcoin development.
> Anything that potentially uses up a large percentage of blockspace seems
> pretty relevant to general Bitcoin development to me...
>
>> AJ Towns writes:
>>> 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.
> I guess I should have explained why I think moving things off-chain is
> a worthwhile goal. Riffing off:
>
>> Another issue is salience and scarcity, as has been mentioned. Off-chain
>> content is unbounded, and thus less scarce. Usually, we design for
>> efficiency, volume, and scale. For NFT designs, which are intended to be
>> collectable, this is in some ways counterproductive.
> "scarce" has two meanings -- one is that there's not much of it, the
> other is that it's highly valued (or a third, where it's is consistently
> underpriced and unavailable even for people who'd pay more, but that
> hopefully doesn't apply).
>
> I think for bitcoin's blockspace, we ideally only want the first of
> these to be true. We want small blocks because that makes it cheap to
> verify bitcoin, which reduces the need to trust third parties and aids in
> decentralisation. But we don't want blockspace to be especially valuable,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.
>
> Moving things off-chain helps with both these goals: it doesn't make it
> harder to validate bitcoin, and it also decreases demand for blockspace,
> making it cheaper for those cases where things can't be moved off-chain.
>
> As a result of this approach, bitcoin blockspace is currently quite
> cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in
> a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a
> luxury purchase.
>
> If you keep jpegs on-chain, as far as I can see, there's three outcomes:
>
>  * blockspace stays relatively cheap, and there's no "scarcity" benefit to
>minting via on-chain inscriptions; it's cheap enough to just mint
>any random meme, and there's no prestige to doing so
>
>  * blockspace becomes filled with jpegs, driving up costs for everyone,
>making jpeg collectors happy, but transactors sad
>
>  * the amount of blockspace is increased, keeping prices low, and
>reducing "scarcity" in both senses, so also making it harder to
>validate bitcoin. no one really wins.
>
> I'd guess the first of these is the most likely, personally.
>
> As far as salience/notability goes, personally, I'd see ownership of
> inscriptions as a negative indicator; "hey, when I was young and foolish I
> wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
> permanent cost for everyone trying to use bitcoin in future". That's not
> unforgivable; people do all sorts of foolish things, and bitcoin's meant
> to survive attacks, not just foolish pranks. But it doesn't seem like
> something to brag about or encourage, either, at least if you want bitcoin
> to be a monetary network that's usable in practice by many/most people.
>
> (Even if one day that goes the other way, and there is real (and
> transferable) social value in being able to say "I donated x sats to fees
> to help secure bitcoin", such a claim is more charitable/admirable/value
> with a smaller on-chain footprint, both in that it again keeps
> validation easier, but also in that it makes it easier for others to
> also simultaneously make the same charitable contribution)
>
>> NFT collectors have a strong revealed preference for on-chain content. The
>> content of high-value NFTs is often stored partially or completely on
>> chain, 
> When you identify an NFT by a url that points at someone else's server,
> that's an obvious vulnerability, as Moxie demonstrated pretty well.
>
> But solving that by saying "okay, we'll ju

Re: [bitcoin-dev] Purely off-chain coin colouring

[Peter Todd via bitcoin-dev]

On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote:
> I think for bitcoin's blockspace, we ideally only want the first of
> these to be true. We want small blocks because that makes it cheap to
> verify bitcoin, which reduces the need to trust third parties and aids in
> decentralisation. But we don't want blockspace to be especially valuable,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.

We certainly do want blockspace to be valuable, as transaction fees have to
both be in constant demand, and rise enough to replace the inflation subsidy if
Bitcoin is to remain secure in the future. In fact at the moment, the inflation
subsidy pays miners about 50x more than fees do. Ordinals and other publication
mechanisms are of course ways that we can drive consistent demand for block
space, keeping Bitcoin secure.

Are you arguing that we should change the inflation subsidy phase-out, eg by
introducing tail emission(1) or demurrage?

1) https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary

-- 
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

[Anthony Towns via bitcoin-dev]

On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> Apologies for posting! I've tried to keep discussion of ordinals and
> inscriptions off-list, because I consider it to be of little relevance to
> general Bitcoin development.

Anything that potentially uses up a large percentage of blockspace seems
pretty relevant to general Bitcoin development to me...

> AJ Towns writes:
> > 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.

I guess I should have explained why I think moving things off-chain is
a worthwhile goal. Riffing off:

> Another issue is salience and scarcity, as has been mentioned. Off-chain
> content is unbounded, and thus less scarce. Usually, we design for
> efficiency, volume, and scale. For NFT designs, which are intended to be
> collectable, this is in some ways counterproductive.

"scarce" has two meanings -- one is that there's not much of it, the
other is that it's highly valued (or a third, where it's is consistently
underpriced and unavailable even for people who'd pay more, but that
hopefully doesn't apply).

I think for bitcoin's blockspace, we ideally only want the first of
these to be true. We want small blocks because that makes it cheap to
verify bitcoin, which reduces the need to trust third parties and aids in
decentralisation. But we don't want blockspace to be especially valuable,
as that makes it expensive to use bitcoin, which then limits who can
use it.

Moving things off-chain helps with both these goals: it doesn't make it
harder to validate bitcoin, and it also decreases demand for blockspace,
making it cheaper for those cases where things can't be moved off-chain.

As a result of this approach, bitcoin blockspace is currently quite
cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in
a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a
luxury purchase.

If you keep jpegs on-chain, as far as I can see, there's three outcomes:

 * blockspace stays relatively cheap, and there's no "scarcity" benefit to
   minting via on-chain inscriptions; it's cheap enough to just mint
   any random meme, and there's no prestige to doing so

 * blockspace becomes filled with jpegs, driving up costs for everyone,
   making jpeg collectors happy, but transactors sad

 * the amount of blockspace is increased, keeping prices low, and
   reducing "scarcity" in both senses, so also making it harder to
   validate bitcoin. no one really wins.

I'd guess the first of these is the most likely, personally.

As far as salience/notability goes, personally, I'd see ownership of
inscriptions as a negative indicator; "hey, when I was young and foolish I
wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
permanent cost for everyone trying to use bitcoin in future". That's not
unforgivable; people do all sorts of foolish things, and bitcoin's meant
to survive attacks, not just foolish pranks. But it doesn't seem like
something to brag about or encourage, either, at least if you want bitcoin
to be a monetary network that's usable in practice by many/most people.

(Even if one day that goes the other way, and there is real (and
transferable) social value in being able to say "I donated x sats to fees
to help secure bitcoin", such a claim is more charitable/admirable/value
with a smaller on-chain footprint, both in that it again keeps
validation easier, but also in that it makes it easier for others to
also simultaneously make the same charitable contribution)

> NFT collectors have a strong revealed preference for on-chain content. The
> content of high-value NFTs is often stored partially or completely on
> chain, 

When you identify an NFT by a url that points at someone else's server,
that's an obvious vulnerability, as Moxie demonstrated pretty well.

But solving that by saying "okay, we'll just externalise the storage
costs to the public, while privatising all the benefits" isn't a good
approach either.

> User protection when off-chain content is involved is fraught.

I mean, that seems trivially solvable? Users already have to store the
private key that controls ownership of these digital assets; storing the
asset as well, which doesn't need to be private, isn't a big ask. And if
a public site like ordinals.net is willing to store all the inscriptions
that might be on the blockchain, they could just as easily store the
same amount of off-chain digital assets.

> When a user buys an NFT with
> off-chain content, they now have the primary economic incentive to preserve
> that content, so that their NFT retains value and can be enjoyed or sold.

Yes -- the people who potentially benefit from the NFT should be the
ones paying the costs of preserving that NFT.

> Many existing NFT marketplaces that sell off-chain content do not explain
> t