Good morning aj,
First off, I have little to no idea of the issues at the lower-level Bitcoin.
In any case ---
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
>
On Fri, Mar 08, 2019 at 03:20:49PM -0500, Matt Corallo via bitcoin-dev wrote:
> To make testing easier, it may make sense to keep the existing block header
> format (and PoW) and instead apply the signature rules to some field in the
> coinbase transaction.
Maybe make the signature be an optional
Hi all,
The following has some more thoughts on trying to make a NOINPUT
implementation as safe as possible for the Bitcoin ecosystem.
One interesting property of NOINPUT usage like in eltoo is that it
actually reintroduces the possibility of third-party malleability to
transactions -- ie, you pu
Hi Matt,
On Mon, Mar 11, 2019 at 10:23 PM Matt Corallo
wrote:
> I think you may have misunderstood part of the motivation. Yes, part of
> the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly
> simplifying the theoretical operation of checksig operations (thus somewhat
> simplifying
On Tue, Mar 12, 2019 at 6:39 PM Jacob Eliosoff
wrote:
> Also, if future disabling isn't the point of making a tx type like
> OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
> support of these oddball features, what do we gain by making them hard to
> use/mine?
>
The pu
Hi Matt,
(I moved your comment to this thread, where I think it is more relevant).
This is a fair point. I concede that as far as Sighash Type Byte is
concerned, the type of change is fairly similar to BIP 68 (though I don't
think the argument applies to OP_CODESEPARATOR).
I might rephrase what
On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev
wrote:
> Also, if future disabling isn't the point of making a tx type like
> OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
> support of these oddball features, what do we gain by making them hard to
>
Also, if future disabling isn't the point of making a tx type like
OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
support of these oddball features, what do we gain by making them hard to
use/mine?
I see questions like "Is it possible someone's existing tx relies on thi
On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
wrote:
> These two cases are understood and handled by current code. Generally
> the idea is take reject messages serious, but don't overrate the lack
> of. Luckily, network confirmations fill the gap. (Yes, a timeout is
I'd like
I have not seen all of the emails in reply come through on the mailing list, I
am sure it is always that way. There are a couple to reply to, replies
indented>:
On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>>
wrote:
What about putt
Note that even your carve-outs for OP_NOP is not sufficient here - if you were
using nSequence to tag different pre-signed transactions into categories
(roughly as you suggest people may want to do with extra sighash bits) then
their transactions could very easily have become un-realistically-sp
(Posting again, since my previous reply didn't appear)
On 08/03/2019 01.52, Gregory Maxwell via bitcoin-dev wrote:
> That is already required because even in the presence of perfectly
> honest and cooperative hosts reject messages at most can only tell you
> about first-hop behaviour. It won't e
Good morning Omar,
BIP32 includes this text:
> In case parse_256(I_L) >= n or K_i is the point at infinity, the resulting
> key is invalid, and one should proceed with the next value for i.
This seems to suggest that it is possible for an attacker with sufficient
compute power to find two cont
13 matches
Mail list logo
