So with datacarrier we can store data in taproot annex with one tx which
will be data and/or extension of the script validation via PUSH_ANNEX
I looked at your links and plenty of others, but had some hard time to
find the proposal
On Sat, Feb 04, 2023 at 07:11:35PM -0500, 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.
Given today's standardness constraints,
Hi Claus,
Thanks but I am not sure to understand the solution, how the transaction
will look like and will it be standard ?
Regards
Aymeric
Le 16/02/2023 à 20:59, Claus Ehrenberg a écrit :
> I propose to require all data to be in the op_return output PLUS add a
> required op_return_hash
I propose to require all data to be in the op_return output PLUS add a
required op_return_hash field, which is checked by consensus. So that node
can re-validate the chain without having to store/download/look at the
contents of op_return data. The benefit of that little redundancy is that
It's super unclear how long it could take for such a change to be adopted
Then the answer is simple, see:
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation
Outstandingly, very, mega, bad, but working, bringing bitcoin back 10
years ago
But
https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403
"What is the process to have someone do the PR for this? Or I do it and
most likely it will be a very shxtty one since I am not a C/C++ expert,
then wasting the time of everybody
It's urgently required, I did consider
On Sat., Feb. 4, 2023, 21:01 Peter Todd, wrote:
>
>
> 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
>
On Sat, Feb 04, 2023 at 07:11:35PM -0500, 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
Yes I agree, let people decide and since taproot has no limits then it
sould be the same for OP_RETURN
I posted https://github.com/bitcoin/bitcoin/issues/27043
Le 05/02/2023 à 13:06, Peter Todd a écrit :
>
> On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte
> wrote:
>> I think
I think logically:
- if you want to store something big and can afford several txs in your
design, then you use something like witness
- if you want to store small things like signatures, addresses hashes
and some metadata and your design does not make several txs easy, then
you use OP_RETURN
On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte
wrote:
>I think logically:
>
>- if you want to store something big and can afford several txs in your
>design, then you use something like witness
>
>- if you want to store small things like signatures, addresses hashes
>and some
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
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
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
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
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,
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
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
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
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
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
Indeed the witness envelope is more costly and less easy to use (or
read/track)
But let's take a standard P2PKH or P2WPKH output, what prevents me from
adding in the beginning of scriptSig or witness while spending it:
OP_PUSH OP_DROP ? Non standard ? This one makes one transaction only
There
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
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
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
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.
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
With OP_RETURN you publish some data that are immediately visible in the
blockchain. I would consider this better (more straightforward) for things
like time-stamping.
With Taproot you need to spend the utxo to make the script visible. This
seems better when you don't want the data public but you
Could someone clarify what is the standard for OP_RETURN? As far as I
understand the data is limited to 80B and only one OP_RETURN is allowed
in one transaction, if not the tx is non standard, correct?
Then the debate can be to store in witness indeed
Or you can store in output addresses (with
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
On February 1, 2023 8:36:52 AM GMT, Kostas Karasavvas
wrote:
>With OP_RETURN you publish some data that are immediately visible in the
>blockchain. I would consider this better (more straightforward) for things
>like time-stamping.
You are incorrect. Time-stamps merely prove that data
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
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
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
34 matches
Mail list logo
