Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-01-28 Thread Russell O'Connor via bitcoin-dev
On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne wrote: > > I don't think implementing a CTV opcode that we expect to largely be > obsoleted by a TXHASH at a later date is yielding good value from a soft > fork process. > > This presumes the eventual adoption of TXHASH (or something like it). >

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-01-28 Thread Russell O'Connor via bitcoin-dev
On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns wrote: > > An Alternative Proposal:: > > ... > > > For similar reasons, TXHASH is not amenable to extending the set of > txflags > > at a later date. > > > I believe the difficulties with upgrading TXHASH can be mitigated by > > designing a robust

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-01-27 Thread Russell O'Connor via bitcoin-dev
on of perhaps scalability). > - Bringing CTV to an implemented state of near-unanimous "we could do > this, technically" is good for concretely driving the process of review for > any covenant proposals forward, irrespective of if we ultimately activate. > (I.e., if there were a reas

[bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-01-26 Thread Russell O'Connor via bitcoin-dev
Recapping the relationship between CTV and ANYPREVOUT:: It is known that there is a significant amount of overlap in the applications that are enabled by the CTV and ANYPREVOUT proposals despite the fact that their primary applications (congestion control for CTV and eltoo lightning channels for

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-07 Thread Russell O'Connor via bitcoin-dev
On Wed, Jul 7, 2021 at 9:12 AM Russell O'Connor wrote: > > On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj wrote: > >> Good morning Russell, >> >> > Hi ZmnSCPxj, >> > >> > I don't believe we need to ban Turing completeness for the sake of >> banning Turing completeness. >> >> Well I believe we should

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-07 Thread Russell O'Connor via bitcoin-dev
On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj wrote: > Good morning Russell, > > > Hi ZmnSCPxj, > > > > I don't believe we need to ban Turing completeness for the sake of > banning Turing completeness. > > Well I believe we should ban partial Turing-completeness, but allow total >

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-06 Thread Russell O'Connor via bitcoin-dev
If the main outstanding issue is whether to split R or S, I think as far as Elements goes, I am inclined to go with the CAT option regardless of whether Bitcoin chooses to split R/S or not (not that I'm necessarily a decision maker here). The issue here is that (a) Elements already has CAT, and

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-06 Thread Russell O'Connor via bitcoin-dev
On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud wrote: > > when people are talking about enabling covenants, we are talking about > whether OP_CAT should be allowed or not > > Are they? Are you implying that anything that enables covenants is > equivalent to enabling OP_CAT? Generally when I think

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-05 Thread Russell O'Connor via bitcoin-dev
Hi ZmnSCPxj, I don't believe we need to ban Turing completeness for the sake of banning Turing completeness. My concerns have always been around ensuring that transaction and block validation is not unduly burdensome for nodes. So for Bitcoin Script, we want to bound the amount of resources

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread Russell O'Connor via bitcoin-dev
On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor wrote: > Bear in mind that when people are talking about enabling covenants, we are > talking about whether OP_CAT should be allowed or not. > > That said, recursive covenants, the type that are most worrying, seems to > require some kind of

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread Russell O'Connor via bitcoin-dev
Bear in mind that when people are talking about enabling covenants, we are talking about whether OP_CAT should be allowed or not. That said, recursive covenants, the type that are most worrying, seems to require some kind of OP_TWEAK operation, and I haven't yet seen any evidence that this can be

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread Russell O'Connor via bitcoin-dev
On Sun, Jul 4, 2021 at 1:30 PM Jeremy wrote: > I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound > to the txdata? When might you use this? > I don't feel strongly about *ADD. I just figured it might be useful to do a 2-of-3 between Alice, Bob and an Oracle signed value.

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-03 Thread Russell O'Connor via bitcoin-dev
There is one line written at https://github.com/ElementsProject/elements/pull/949/files#r660130155. I suppose we need to decide on which variants of *VERIFY and *ADD we want to include (presumably all of them) and choose which opcodes they will be assigned to. And I guess for CHECKSIGFROMSTACKADD

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-03 Thread Russell O'Connor via bitcoin-dev
Hi Jermy, As you are aware, we, and by we I mean mostly Sanket, are developing an updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements. The plan here would be to effectively support the an interface to the variable-length extension of BIP-0340 schnorr signatures. BIP-0340 would

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

2021-06-12 Thread Russell O'Connor via bitcoin-dev
On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud wrote: > > taproot annex > > From what I can tell, the annex is basically additional inputs to a script > that might have additional constraints put on it. Is that right? I don't > quite follow how moving the max height to the annex helps script

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

2021-06-11 Thread Russell O'Connor via bitcoin-dev
On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte wrote: > @Billy I like the idea. It is very obvious how useful an opcode like this > would be! (My background is in wallet implementation) > > @Russell I do understand your concerns of monotonism, however I'm having a > hard time really coming up

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

2021-06-10 Thread Russell O'Connor via bitcoin-dev
As it stands today, in order to double spend a transaction during a reorg, one must take an active role of recognizing that a reorg has happened, hope that the new branch has completely omitted your spending transaction, and then quickly broadcast a replacement transaction with a higher fee to

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

2021-06-10 Thread Russell O'Connor via bitcoin-dev
This is a continuation of the thread at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html on this topic. I still remain unconvinced that we ought to give up on the "reorg safety" property that is explicitly part of Bitcoin's design. On Thu, Jun 10, 2021 at 1:56 PM

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

2021-04-16 Thread Russell O'Connor via bitcoin-dev
Firstly, a minor point is that your proposal is a soft-fork, not a hard-fork. But more importantly, adding limitations on OP_RETURN transactions is not helpful. Users who want to embed arbitrary data in their transactions can always do so by encoding their data inside the values of legacy

Re: [bitcoin-dev] maximum block height on transaction

2021-04-09 Thread Russell O'Connor via bitcoin-dev
>From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119: We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg > after a segmentation, transactions need to be able to get into the chain in > a later block. The OP_BLOCKNUMBER transaction and all its dependants would

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Russell O'Connor via bitcoin-dev
On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor wrote: > On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote: > >> >> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" ) >> >> Ten minute estimators can say: >> >> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 *

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Russell O'Connor via bitcoin-dev
On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote: > > You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" ) > > Ten minute estimators can say: > > You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016)) > minutes" ) > > And nine minute estimators can say: > >

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Russell O'Connor via bitcoin-dev
I'm pretty sure that the question of "is signalling still possible by the time enough miners have upgraded and are ready to start signalling?" Strongly benefits from a guaranteed number of signaling periods that height based activation offers. Especially for the short activation period of Speedy

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

2021-03-06 Thread Russell O'Connor via bitcoin-dev
Hi Andrew, This is a slight misunderstanding of the proposal. Rather than an extended lockin period (a term I've erroneously used in the past) it is really a minimum activation height. Thus using your figures it would instead be: * start height = 681408 /* about May 1st */ * timeout height =

Re: [bitcoin-dev] Making the case for flag day activation of taproot

2021-03-04 Thread Russell O'Connor via bitcoin-dev
Appologies as I've rearranged your comments in my reply. On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo wrote: > > On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote: > > After a normal and successful Core update with LOT=false, we will have > more data showing broad co

Re: [bitcoin-dev] Making the case for flag day activation of taproot

2021-03-03 Thread Russell O'Connor via bitcoin-dev
While I support essentially any proposed taproot activation method, including a flag day activation, I think it is premature to call BIP8 dead. Even today, I still think that starting with BIP8 LOT=false is, generally speaking, considered a reasonably safe activation method in the sense that I

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-10-08 Thread Russell O'Connor via bitcoin-dev
On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Rather than go through that again, I'd prefer we use the > backwards compatible proposal from BIPs PR#945 and, if we want to > maximize safety, consensus restrict v1 witness program

[bitcoin-dev] On the compatibility of Bech32 and Shamir's Secret Sharing

2020-08-03 Thread Russell O'Connor via bitcoin-dev
With the help of Pieter I've recently made some interesting mathematical observations about Bech32 codewords and Shamir's secret sharing: (1) Affine combinations of two Bech32 codewords is again a valid Bech32 codeword. (2) Lagrange polynomials form a partition of unity. The consequences of

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

2020-07-15 Thread Russell O'Connor via bitcoin-dev
15, 2020 at 5:05 PM Greg Sanders wrote: > Can you make it clear what the bold vs not-bold numbers mean? > > On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Wed, Nov 13, 2019 at 1:31 AM Pi

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

2020-07-15 Thread Russell O'Connor via bitcoin-dev
On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > That brings me to Matt's point: there is no need to do this right now. We > can simply amend BIP173 to only permit length 20 and length 32 (and only > length 20 for v0, if you like;

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

2020-05-27 Thread Russell O'Connor via bitcoin-dev
I don't believe that 60 bytes is a problem here. SHA256 padding includes a length value of the original message data. Thus a padded non-64 byte transaction can never be the same as any padded 64-byte value, and therefore after applying the SHA256 compression function the resulting hashes cannot

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

2020-05-02 Thread Russell O'Connor via bitcoin-dev
On Sat, May 2, 2020 at 10:26 AM Anthony Towns wrote: > > except that we'd arguably still be missing: > > is this a coinbase output? (Coin.fCoinBase) > what was the height of the coin? (Coin.nHeight) > > Maybe committing to the coinbase flag would have some use, but committing > to the

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

2020-05-02 Thread Russell O'Connor via bitcoin-dev
> If you didn't verify the output scriptPubKeys, you would *only* be able > to care about fees since you couldn't verify where any of the funds went? > And you'd only be able to say fees are "at least x", since they could be > more if one of the scriptPubKeys turned out to be OP_TRUE eg. That

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

2020-05-01 Thread Russell O'Connor via bitcoin-dev
While I'm not entirely convinced yet that accertaining non-ownership of an input is a robust method of solving the problem here, I also see little reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is already indirectly covered through the outpoints, so it is just a matter of

Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques

2020-03-22 Thread Russell O'Connor via bitcoin-dev
On Sun, Mar 22, 2020 at 5:43 AM Tim Ruffing wrote: > On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote: > > Public keys are deterministic and can be spot checked. In fact, > > AFAIU if hardened HD key derivations are not used, then spot checking > > is very easy. > > > > While spot

Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques

2020-03-21 Thread Russell O'Connor via bitcoin-dev
On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Pieter, > > Let's take a step back first. If we believe that malicious hardware > wallets are big enough of a concern, then signing is only part of the > problem. The other issue is

Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage

2020-03-06 Thread Russell O'Connor via bitcoin-dev
On Wed, Feb 26, 2020 at 2:56 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > As a replacement for paper, something like this makes sense v.s. what you > do with a ledger presently. > > However, shamir's shares notoriously have the issue that the key does > exist

[bitcoin-dev] Fwd: BIP 340 updates: even pubkeys, more secure nonce generation

2020-02-25 Thread Russell O'Connor via bitcoin-dev
On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 2. Nonce generation > > All other semantical changes are around more secure nonce generation > in BIP 340, dealing with various failure cases: > > * To protect against fault

Re: [bitcoin-dev] Signing CHECKSIG position in Tapscript

2019-12-05 Thread Russell O'Connor via bitcoin-dev
After chatting with andytoshi and others, and some more thinking I've been convinced that my specific concern about other users masquerading other people pubkeys as their own in complex scripts is actually a non-issue. No matter what you write in Script (today), you are limited to expressing some

Re: [bitcoin-dev] Signing CHECKSIG position in Tapscript

2019-12-01 Thread Russell O'Connor via bitcoin-dev
On Thu, Nov 28, 2019 at 3:07 AM Anthony Towns wrote: > FWIW, there's discussion of this at > http://www.erisian.com.au/taproot-bip-review/log-2019-11-28.html#l-65 > I think variants like signing the position of the enclosing OP_IF/OP_NOTIF/OP_ELSE of the OP_IF/OP_NOTIF/OP_ELSE block that the

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

2019-11-27 Thread Russell O'Connor via bitcoin-dev
Thanks for this work Jeremy. I know we've discussed this before, but I'll restate my concerns with adding a new "global" state variable to the Script interpreter for tracking whether the previous opcode was a push-data operation or not. While it isn't so hard to implement this in Bitcoin Core's

[bitcoin-dev] Signing CHECKSIG position in Tapscript

2019-11-27 Thread Russell O'Connor via bitcoin-dev
Hi all, I'd like to revisit an old topic from last year about the data signed in tapscript signatures < https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016508.html >. The current tapscript proposal requires a signature on the last executed CODESEPRATOR position. I'd like

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

2019-11-08 Thread Russell O'Connor via bitcoin-dev
I do like the idea of length prefixing the witness program. I will note that the 1 byte witness version is really more like a 1 character witness version. There are 17 different segwit versions and there are 32 characters in the bech32 alphabet. That leaves 15 unused characters that we can use

Re: [bitcoin-dev] Taproot proposal

2019-06-28 Thread Russell O'Connor via bitcoin-dev
Hmm? If I'm following what you mean, that's not the P2P rules, it's the > Unserialize code, in particular: > > compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int > assumed"); > > serialize.h:289:uint64_t ReadCompactSize(Stream& is) > > serialize.h-679-template typename V> >

Re: [bitcoin-dev] Taproot proposal

2019-06-26 Thread Russell O'Connor via bitcoin-dev
I have a comment about the 'input_index' of the transaction digest for taproot signatures. It is currently listed as 2 bytes. I think it would be better to expand that to 4 bytes. The two byte limit is derived from the block size / weight limit, which limits the maximum size of a transaction,

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-06-25 Thread Russell O'Connor via bitcoin-dev
Bitcoin Core is somewhat outside my core competence, but the various OP_PUSHDATA are already multi-byte opcodes and GetOp already has a data return parameter that is suitable for returning the payload of an immediate 32-byte data variant of OP_SECURETHEBAG. All that I expect is needed is to

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-06-25 Thread Russell O'Connor via bitcoin-dev
I suspect that your conjecture is true. And given that it is plausible that we would want to add an opcode to tweak public keys, it seems like a reason design to avoid accidental covenants. (That said, I strongly prefer that the SECURETHEBAG data be the 32-bytes immediately following the opcode

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-06-25 Thread Russell O'Connor via bitcoin-dev
u clarify this comment? > > We do in fact commit to the script and scriptsig itself (not the witness > stack) in OP_SECURETHEBAG (unless I'm missing what you meant)? > > On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wr

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-06-20 Thread Russell O'Connor via bitcoin-dev
Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of covenants if it pulled data from the stack, the OP_SECURETHEBAG probably cannot create covenants even if it were to pull the data from the stack unless some OP_TWEEKPUBKEY operation is added to Script because the "commitment

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

2019-06-09 Thread Russell O'Connor via bitcoin-dev
On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell wrote: > "Russell O'Connor" writes: > > Hi Rusty, > > > > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > >> The new "emergency RBF" rule: > >> > >> 6. If the original

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

2019-06-03 Thread Russell O'Connor via bitcoin-dev
Hi Rusty, On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The new "emergency RBF" rule: > > 6. If the original transaction was not in the first 4,000,000 weight > units of the fee-ordered mempool and the replacement transaction

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-06-03 Thread Russell O'Connor via bitcoin-dev
On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi All, > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. > OP_SECURETHEBAG does more or less the same thing, but fixes malleability > issues and lifts the single output

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-30 Thread Russell O'Connor via bitcoin-dev
On Mon, May 27, 2019 at 3:21 AM Anthony Towns wrote: > On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev > wrote: > > Bitcoin Script appears designed to be a flexible programmable system that > > provides generic features to be composed to achiev

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-26 Thread Russell O'Connor via bitcoin-dev
Allowing multiple inputs is certainly better than the 1 restriction COSHV. However, I agree on your preference for a RISC+CISC approach. Which is why instead of COSHV or CHECK_TXID_TEMPLACE_DATA we should do the more RISC-y thing and begin adding transaction reflection primitives, starting with

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-25 Thread Russell O'Connor via bitcoin-dev
In order of escalating scope of amendments to OP_COSHV, I suggest 1) Peeking at surrounding data surrounding data should definitely be replaced by a pushdata-like op-code that uses the subsequent 32-bytes directly. The OP_SUCCESSx upgrade path specifically allows for this, and avoids

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
On Wed, May 22, 2019 at 5:01 PM Russell O'Connor wrote: > In concert, these two operations enable: > > * Oracle signature verification, including discrete log contracts. > Jonas informs me that I've misunderstood how discreet log contracts work. The DLC signatures are not directly checked by

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
Hello ZmnSCPxj, I agree that adding OP_CHECKSIGFROMSTACK doesn't preclude adding shortcuts such as `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`, and I agree we ought to support such operations directly, especially if we see widespread use of these constructions in practice. I think it is

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
> signatures for different parts of the transaction? Or is it something more > complicated like aggregating multiple signatures over different parts of > the transaction? > > Best, > > Jimmy > > On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev < > bitc

Re: [bitcoin-dev] Taproot proposal

2019-05-23 Thread Russell O'Connor via bitcoin-dev
On Wed, May 22, 2019 at 10:06 PM Pieter Wuille wrote: > On Tue, 21 May 2019 at 10:20, Russell O'Connor > wrote: > > > > Regarding Tapscript, the specification calls for the final value of the > stack being a single non-false value: > > > >> The tapscript is executed according to the rules in

[bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-23 Thread Russell O'Connor via bitcoin-dev
Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for Bitcoin via new Script operations. However, I think that these proposals miss the mark when it comes to how they approach Bitcoin Script and language

Re: [bitcoin-dev] Taproot proposal

2019-05-21 Thread Russell O'Connor via bitcoin-dev
Regarding Tapscript, the specification calls for the final value of the stack being a single non-false value: The tapscript is executed according to the rules in the following section, > with the initial stack as input > II. If the execution results in anything but exactly one element on >

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

2019-03-13 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-13 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

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

2019-03-13 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-11 Thread Russell O'Connor via bitcoin-dev
Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (overhead for varints) = 572ish bytes should be enough to completely eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transactions

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

2019-03-11 Thread Russell O'Connor via bitcoin-dev
Hi Jacob, > Huh?! The whole point of non-standardness in this context is to (a) make >>> soft-forking something out safer by derisking miners not upgrading right >>> away and (b) signal something that may be a candidate for soft-forking >>> out so that we get feedback. Who is getting things

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

2019-03-11 Thread Russell O'Connor via bitcoin-dev
I fear that we cannot simply wait 10 years to address the vulnerability that OP_CODESEPARATOR has in its current form. On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH < willt...@live.com.au> wrote: > Opinion: Lock in a blockheight to get rid of it 10 years in the future. > Use it

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

2019-03-09 Thread Russell O'Connor via bitcoin-dev
Hi Matt, On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo wrote: > Replies inline. > > On 3/8/19 3:57 PM, Russell O'Connor wrote: > > On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo > > wrote: > > It's very easy to construct a practical script using OP_CODESEPARATOR. >

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

2019-03-09 Thread Russell O'Connor via bitcoin-dev
Hi Sjors, On Fri, Mar 8, 2019 at 2:12 PM Sjors Provoost wrote: > Transaction weight currently doesn't consider OP codes, it only considers > if bytes are part of the witness. Changing that to something more akin to > Ethereums gas pricing sounds too complicated to even consider. > I did say

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

2019-03-08 Thread Russell O'Connor via bitcoin-dev
On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo wrote: > Replies inline. > > Matt > > On 3/7/19 3:03 PM, Russell O'Connor wrote: > > > > * OP_CODESEPARATOR in non-BIP 143 scripts fails the script > validation. > > This includes OP_CODESEPARATORs in unexecuted branches of if > >

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

2019-03-08 Thread Russell O'Connor via bitcoin-dev
On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo wrote: > I can't say I'm particularly married to this idea (hence the alternate > proposal in the original email), but at the same time the lack of > existing transactions using these bits (and the redundancy thereof - > they don't *do* anything

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

2019-03-07 Thread Russell O'Connor via bitcoin-dev
> * If the sighash type byte (ie last byte in a signature being evaluated > during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY]) > is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script > execution fails. This does not apply to 0-length signature stack elements. > The

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

2018-12-19 Thread Russell O'Connor via bitcoin-dev
On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau wrote: > > I proposed the same in BIP114. I wish Satoshi had designed that way. > Thanks. I probably read that and internalized it and forgot you wrote it. > But I’m not sure if that would do more harm than good. For example, people > might lose

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

2018-12-19 Thread Russell O'Connor via bitcoin-dev
On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 5. if there's exactly one, non-zero item on the stack; succeed > Unless it is too much bikeshedding, I'd like to propose that to succeed the stack must be exactly empty. Script

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-17 Thread Russell O'Connor via bitcoin-dev
On Wed, Dec 12, 2018 at 2:53 PM Johnson Lau wrote: > > I think the root cause of witness weight malleability is some opcodes > accept variable size input (without affecting the output), and that input > is provided by the puzzle solver. Going through the opcode list, I think > such opcodes

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-17 Thread Russell O'Connor via bitcoin-dev
On Wed, Dec 12, 2018 at 12:26 PM Gregory Maxwell wrote: > On Wed, Dec 12, 2018 at 5:15 PM Russell O'Connor via bitcoin-dev > wrote: > > I tend to think in opposite terms. Is there a proof that any script can > be transformed into an equivalent one that avoids witness weight

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-17 Thread Russell O'Connor via bitcoin-dev
On Wed, Dec 12, 2018 at 7:06 PM Anthony Towns wrote: > On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau wrote: > > The current proposal is that a 64-byte signature will be used for the > &

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-11 Thread Russell O'Connor via bitcoin-dev
at 10:00 AM David A. Harding wrote: > On Thu, Dec 06, 2018 at 11:57:09AM -0500, Russell O'Connor via bitcoin-dev > wrote: > > One more item to consider is "signature covers witness weight". > > > > While signing the witness weight doesn't completely elimina

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-09 Thread Russell O'Connor via bitcoin-dev
One more item to consider is "signature covers witness weight". While signing the witness weight doesn't completely eliminate witness malleability (of the kind that can cause grief for compact blocks), it does eliminate the worst kind of witness malleability from the user's perspective, the kind

Re: [bitcoin-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

2018-11-30 Thread Russell O'Connor via bitcoin-dev
On Fri, Nov 30, 2018 at 9:50 AM Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > To partially-address the CPFP security model considerations, a next step > might involve tweaking Lightning's commitment transaction to have two > small-value outputs which are

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-11-24 Thread Russell O'Connor via bitcoin-dev
On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns wrote: > On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > Given that we want to move away from OP_CODESEPARATOR, because each call > to > > this operation effectively takes O(scrip

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-11-23 Thread Russell O'Connor via bitcoin-dev
On Thu, Nov 22, 2018 at 3:53 PM Johnson Lau wrote: > Assuming a script size of 128 bytes (including SHA256 padding), 2^20 > scripts is 134MB. Double it to 268MB for the merkle branch hashes. With > roughly 100MB/s, this should take 2.5s (or 42min for 30 levels). However, > memory use is not

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-11-23 Thread Russell O'Connor via bitcoin-dev
rse > privacy. To maximise fungibility, we should encourage people to use MAST, > instead of improve the functionality of OP_IF and further complicate the > protocol. > > > On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> w

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-11-22 Thread Russell O'Connor via bitcoin-dev
On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So my question is whether anyone can see ways in which this introduces > redundant flexibility, or misses obvious use cases? > Hopefully my comment is on-topic for this thread: Given

Re: [bitcoin-dev] Schnorr signatures BIP

2018-09-21 Thread Russell O'Connor via bitcoin-dev
It would be helpful to add the intermediate 'e' values computed to the first four test vectors. On Fri, Jul 6, 2018 at 2:08 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello everyone, > > Here is a proposed BIP for 64-byte elliptic curve Schnorr

Re: [bitcoin-dev] Schnorr signatures BIP

2018-08-06 Thread Russell O'Connor via bitcoin-dev
On Mon, Aug 6, 2018 at 4:39 AM, Anthony Towns wrote: > On Sun, Aug 05, 2018 at 10:33:52AM -0400, Russell O'Connor via bitcoin-dev > wrote: > > In light of this, I revise my proposed change to make the verification > > equation > > > > R + sG + eP = 0. > > Is

Re: [bitcoin-dev] Schnorr signatures BIP

2018-08-05 Thread Russell O'Connor via bitcoin-dev
Over chat it has been pointed out to me that computing the non-quadratic residue is not the same cost as computing a quadratic residue. As pointed out in footnote 7 of the the proposed BIP, c^((p+1)/4) is always a quadratic residue and must be negated to find the non-quadratic residue. In light

Re: [bitcoin-dev] Schnorr signatures BIP

2018-08-04 Thread Russell O'Connor via bitcoin-dev
I propose changing the verification equation from "Let *R = sG - eP*" to Let *R = sG + eP* This allows faster verification by avoiding negating a point (or a coefficient). If, instead of directly following the literal verification specification, one is instead reconstructing R from r by

Re: [bitcoin-dev] A BIP proposal for segwit addresses

2018-07-26 Thread Russell O'Connor via bitcoin-dev
I think I phrased this badly. What I mean is that there should be a note that HRP should be specified in lowercase, or at least mention that uppercase and lowercase HRPs are considered equivalent and will be canonicalized to lowercase during validation. On Thu, Jul 26, 2018 at 9:43 AM, Russell

Re: [bitcoin-dev] A BIP proposal for segwit addresses

2018-07-26 Thread Russell O'Connor via bitcoin-dev
Hi Pieter, > The *human-readable part*, which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific

Re: [bitcoin-dev] Multiparty signatures

2018-07-19 Thread Russell O'Connor via bitcoin-dev
On Thu, Jul 19, 2018 at 8:16 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > you can't birthday attack something where there's only a single variable > that you can modify. > When engaging in a multiparty signature, the attacker can more than one variable to

Re: [bitcoin-dev] Schnorr signatures BIP

2018-07-08 Thread Russell O'Connor via bitcoin-dev
On Fri, Jul 6, 2018 at 6:00 PM, Gregory Maxwell wrote: > On Fri, Jul 6, 2018 at 9:05 PM, Russell O'Connor via bitcoin-dev > wrote: > > If the inputs to hash were reordered as hash(bytes(dG) || bytes(x(R)) || > m) > > then there is an opportunity for SHA256 expander to be

Re: [bitcoin-dev] Schnorr signatures BIP

2018-07-06 Thread Russell O'Connor via bitcoin-dev
Some quick comments: Signing > > To sign: > >- Let *k = int(hash(bytes(d) || m)) mod n*[8 > > >]. >- Let *R = kG*. >- If *jacobi(y(R)) ≠ 1*, let *k = n - k*. >- Let *e = int(hash(bytes(x(R))

Re: [bitcoin-dev] New serialization/encoding format for key material

2018-06-15 Thread Russell O'Connor via bitcoin-dev
> For codes designed for length 341 (the first length enough to support > 512 bits of data): > * correct 1 error = 3 checksum characters > * correct 2 errors = 7 checksum characters > * correct 3 errors = 11 checksum characters > * correct 4 errors = 15 checksum characters > * correct 5 errors =

Re: [bitcoin-dev] New serialization/encoding format for key material

2018-06-13 Thread Russell O'Connor via bitcoin-dev
On Tue, May 29, 2018 at 5:13 AM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi > > If 520 bits are present, first 256 bits are the BIP32 chain code, to > second 264 > bits (33 bytes) define the public key (according to BIP32) > In a 33 byte compressed public

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-06-01 Thread Russell O'Connor via bitcoin-dev
On Fri, Jun 1, 2018 at 1:03 PM, Johnson Lau wrote: > On 1 Jun 2018, at 11:03 PM, Russell O'Connor > wrote: > On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> Double SHA256 of the serialization of: >> > > Should we replace

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-06-01 Thread Russell O'Connor via bitcoin-dev
On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Double SHA256 of the serialization of: > Should we replace the Double SHA256 with a Single SHA256? There is no possible length extension attack here. Or are we speculating that

Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-21 Thread Russell O'Connor via bitcoin-dev
In the thread "Revisting BIP 125 RBF policy" @ https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015797.html I propose replacing rule 3 with a rule that instead demands that the replacement

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

2018-05-10 Thread Russell O'Connor via bitcoin-dev
Thanks for writing this up Anthony. Do you think that a CHECKSIGFROMSTACK proposal should be included within this discussion of signature soft-forks, or do you see it as an unrelated issue? CHECKSIGFROMSTACK enables some forms of (more) efficent MPC (See

Re: [bitcoin-dev] BIP sighash_noinput

2018-05-01 Thread Russell O'Connor via bitcoin-dev
At the risk of bikeshedding, shouldn't NOINPUT also zero out the hashSequence so that its behaviour is consistent with ANYONECANPAY? On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > I'd like to pick up the discussion

  1   2   >