On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote:
> On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
> >You could try statically analyze `` to determine whether the
> >IF branch could ever be taken. For example there is no path through
> >the "inscription
On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
>You could try statically analyze `` to determine whether the
>IF branch could ever be taken. For example there is no path through
>the "inscription script" that would result in all the crap being dropped
>by the end of
On Fri, Feb 17, 2023 at 11:35:34PM +, Andrew Poelstra via bitcoin-dev wrote:
>
> If you ban any of these specific script fragments then spammers will
> just use `IF ENDIF` and provide the `FALSE` as a zero push.
> And banning *this* would ban legitimate use cases.
>
I realize this is
On Fri, Feb 17, 2023 at 03:56:31PM +0100, vjudeu via bitcoin-dev wrote:
> > [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
>
> I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS.
> Because "OP_FALSE OP_IF OP_ENDIF" is effectively the same as
>
On Friday, February 17th, 2023 at 10:51 AM, Anthony Towns via bitcoin-dev
wrote:
> I think it's probably less complex to close some of the doors?
> 2) are short ids available/meaningful to send prior to VERACK being
> completed?
Ah, I hadn't considered this nuance. If we don't care about
On Thu, Feb 16, 2023 at 05:43:22PM +, Dhruv M via bitcoin-dev wrote:
> Problem:
> - 1 byte message type IDs are lacking a co-ordination mechanism when multiple
> in-flight BIPs are proposing new message types as the id space is reduced
> form 12 ASCII bytes to 1 byte.
> - 1 byte IDs are
> [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS.
Because "OP_FALSE OP_IF OP_ENDIF" is effectively the same as
"OP_NOP", and putting NOPs in many places is considered non-standard. The same
is
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
10 matches
Mail list logo
