Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

2019-03-12 Thread ZmnSCPxj via bitcoin-dev
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: > >

Re: [bitcoin-dev] Signet

2019-03-12 Thread Anthony Towns via bitcoin-dev
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

[bitcoin-dev] More thoughts on NOINPUT safety

2019-03-12 Thread Anthony Towns via bitcoin-dev
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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

2019-03-12 Thread Russell O'Connor via bitcoin-dev
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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

2019-03-12 Thread Russell O'Connor via bitcoin-dev
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

Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

2019-03-12 Thread Russell O'Connor via bitcoin-dev
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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

2019-03-12 Thread Gregory Maxwell via bitcoin-dev
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 >

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

2019-03-12 Thread Jacob Eliosoff via bitcoin-dev
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

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

2019-03-12 Thread Gregory Maxwell via bitcoin-dev
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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

2019-03-12 Thread LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
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

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

2019-03-12 Thread Matt Corallo via bitcoin-dev
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

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

2019-03-12 Thread Andreas Schildbach via bitcoin-dev
(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

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

2019-03-12 Thread ZmnSCPxj via bitcoin-dev
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