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 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
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
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
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
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".
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
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
>
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
16 matches
Mail list logo
