Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

I haven't really been following the drivechain discussion; I have found the documentation about how drivechains are supposed to work scattered and difficult to follow. So, without advocating for or against this proposal, I'd also suggest that adding an opcode is not the best way to implement this b

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

HI Chris, My proposal isn't intended to assume that the bitcoin miner is also following the sidechain. In line with my understanding of your proposal, I'm only proposing to bribe miners to put particular data into the coinbase output regardless of any semantics that doing so may entail. By my pro

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: In any case, let me propose actual improvements to the OP_BRIBEVERIFY > proposal: > > 1. Remove the necessity of coinbase commitments. The miner commits to > the sidechain_id and h* in the t

Re: [bitcoin-dev] Fast Merkle Trees

The fast hash for internal nodes needs to use an IV that is not the standard SHA-256 IV. Instead needs to use some other fixed value, which should itself be the SHA-256 hash of some fixed string (e.g. the string "BIP ???" or "Fash SHA-256"). As it stands, I believe someone can claim a leaf node as

Re: [bitcoin-dev] Fast Merkle Trees

In that case, you may as well remove all references to leaves and double SHA-256 from your BIP since your design has no method for distinguishing between internal nodes and leaves. I think that if this design stands, it will play a role in some future CVEs. The BIP itself is too abstract about it

Re: [bitcoin-dev] Fast Merkle Trees

On Thu, Sep 7, 2017 at 1:55 AM, Peter Todd wrote: > On Wed, Sep 06, 2017 at 09:59:54PM -0400, Russell O'Connor via bitcoin-dev > wrote: > > The fast hash for internal nodes needs to use an IV that is not the > > standard SHA-256 IV. Instead needs to use some other fixed

Re: [bitcoin-dev] Fast Merkle Trees

On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach wrote: > I've been puzzling over your email since receiving it. I'm not sure it > is possible to perform the attack you describe with the tree structure > specified in the BIP. If I may rephrase your attack, I believe you are > seeking a solution t

[bitcoin-dev] SigOps limit.

On Tue, Sep 12, 2017 at 3:57 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 4MB of secp256k1 signatures takes 10s to validate on my 5 year old > laptop (125,000 signatures, ignoring public keys and other things that > would consume space). That's much less

Re: [bitcoin-dev] Version 1 witness programs (first draft)

Given the proposed fixed signature size, It seems better to me that we create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH. Mark, you seem to be arguing that in general we still want weight malleability even with witness depth fixed, but I don't understand in what scenario we

Re: [bitcoin-dev] Version 1 witness programs (first draft)

On Sun, Oct 1, 2017 at 3:27 PM, Mark Friedenbach wrote: > > On Oct 1, 2017, at 12:05 PM, Russell O'Connor > wrote: > > > > Given the proposed fixed signature size, It seems better to me that we > create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH. > > For what benefit? If y

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

(Subject was: [bitcoin-dev] Version 1 witness programs (first draft)), but I'm moving part of that conversation to this thread. On Sun, Oct 1, 2017 at 5:32 PM, Johnson Lau wrote: > 3. Do we want to allow static analysis of sigop? > BIP114 and the related proposals are specifically designed to al

Re: [bitcoin-dev] Version 1 witness programs (first draft)

On Sun, Oct 1, 2017 at 4:39 PM, Mark Friedenbach wrote: > > > On Oct 1, 2017, at 12:41 PM, Russell O'Connor > wrote: > > > > Creating a Bitcoin script that does not allow malleability is difficult > and requires wasting a lot of bytes to do so, typically when handling > issues around non-0-or-1

Re: [bitcoin-dev] Version 1 witness programs (first draft)

On Thu, Oct 5, 2017 at 4:33 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Here’s an additional (uncontroversial?) idea due to Russell O’Connor: > For the record, it's Johnson Lau's proposal where I read this idea. __

[bitcoin-dev] Simplicity: An alternative to Script

I've been working on the design and implementation of an alternative to Bitcoin Script, which I call Simplicity. Today, I am presenting my design at the PLAS 2017 Workshop on Programming Languages and Analysis for Security. You find a copy of my Simplicity paper

Re: [bitcoin-dev] Simplicity: An alternative to Script

ptimized drop-ins, > which I imagine would be required to do any new cryptographic algorithms > due to the significant fee cost of interpreting such things. > > Is there some insight I'm missing here? > > Matt > > > On October 30, 2017 11:22:20 AM EDT, Russell O'Conno

Re: [bitcoin-dev] Simplicity: An alternative to Script

care about holds on reaching that part of the contract. E.g. maybe their signature is needed at the top level, and then they don't care what further restrictions are placed. On Tue, Oct 31, 2017 at 1:38 PM, Russell O'Connor via bitcoin-dev wrote: > (sorry, I forgot to reply-all earl

Re: [bitcoin-dev] Simplicity proposal - Jets?

Hi Jose, Jets are briefly discussed in section 3.4 of https://blockstream.com/simplicity.pdf The idea is that we can recognize some set of popular Simplicity expressions, and when the Simplicity interpreter encounters one of these expressions it can skip over the Simplicity interpreter and instea

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 8, 2018 at 7:39 AM, Pavol Rusnak via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 08/01/18 05:22, Gregory Maxwell wrote: > >> https://github.com/satoshilabs/slips/blob/master/slip-0039.md > > > > The 16-bit "checksum" based on sha2 seems pretty poor since basing > >

Re: [bitcoin-dev] BIP 117 Feedback

Putting aside for the moment the concerns that Pieter and Rusty have raised about BIP 117 (concerns which I agree with), is BIP 117 even a viable soft fork to begin with? When it comes to soft forks of Script, in the past there have been two kinds. The first kind is soft-forking new script semant

Re: [bitcoin-dev] BIP 117 Feedback

On Mon, Jan 15, 2018 at 11:15 PM, Luke Dashjr wrote: > On Tuesday 16 January 2018 1:06:14 AM Rusty Russell via bitcoin-dev wrote: > > The rule AFAICT is "standard transactions must still work". This was > > violated with low-S, but the transformation was arguably trivial. > > > > OTOH, use of al

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

Hi Ondřej, 1. There is no similarity between SSS and RSA or any other public-key or symmetric crypto. SSS is effectively a one-time pad and is information-theoretically secure. 2. Even if there were a problem (which there cannot be, due to (1)), using error correcting codes and truncated hash fu

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Thu, Jan 18, 2018 at 1:58 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Jan 18, 2018 at 4:59 PM, Ondřej Vejpustek > wrote: > >> If being secure against partial share leakage is really part of your > >> threat model the current proposal is gratuit

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 1:44 AM, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Jan 23, 2018 at 12:30:06AM +, Gregory Maxwell via bitcoin-dev > wrote: > > One point that comes up while talking about merkelized scripts is can > > we go about making fanci

[bitcoin-dev] Design approaches for Signature Aggregation

On Sat, Jan 27, 2018 at 12:23 PM, Matt Corallo wrote: > Gah, please no. I see no material reason why cross-input signature > aggregation shouldn't have the signatures in the first n-1 inputs replaced > with something like a single-byte push where a signature is required to > indicate aggregation,

Re: [bitcoin-dev] Design approaches for Signature Aggregation

On Tue, Jan 30, 2018 at 2:12 PM, Russell O'Connor wrote: > > and there are probably other designs for signature aggregation beyond the > two designs I'm discussing here. > For example, in private communication Pieter suggested putting the aggregate signature data into the top of the first segwit

[bitcoin-dev] Revisiting BIP 125 RBF policy.

I think it is worth revisiting BIP 125's replace-by-fee policy for when to replace transactions. The current policy can be problematic. As noted earlier by Rhavar, sometimes one's transaction becomes pinned making it infeasible to fee bump with RBF. This happens when one makes a normal payment to

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > I don't actually see where the problem is here. First of all, suppose we > have a > transaction T_a that already pays Alice with a feerate sufficiently high > that > we expect it to get mined in the near future. If we want to pay Bob, we > ca

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > > > > > > > I don't actually see where the problem is here. First of all, suppose > we > > > have a > > > transaction

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > > Surely CPFP is already computing the package-fee rates of mempool > > transactions. That is the value we need to compute. > > True, maybe we can just reuse the CPFP calculat

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > > Ah ok, I misunderstood and didn't realise you were talking about the case > where > Alice re-spends her unconfirmed payment. Unfortunately I don't think that > case > is possible to solve without putting some kind of restriction on spending >

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd wrote: > On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote: > > When you say that you don't think it is possible to solve, do you mean > that > > there is a specific problem with this proposal of replacing transactions > > when offered a

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd wrote: > On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote: > > On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd wrote: > > > I mean, I think in general solving this problem is probably not > possible. > > > Basically, the fundamental problem

Re: [bitcoin-dev] BIP sighash_noinput

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

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

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 http://people.csail.mit.edu/ranjit/papers/

Re: [bitcoin-dev] Making OP_TRUE standard?

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 packag

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

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 the

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

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 th

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

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] New serialization/encoding format for key material

> 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 = 19

Re: [bitcoin-dev] Schnorr signatures BIP

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] Schnorr signatures BIP

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 t

Re: [bitcoin-dev] Multiparty signatures

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 m

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

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 ap

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

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 O'

Re: [bitcoin-dev] Schnorr signatures BIP

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 fin

Re: [bitcoin-dev] Schnorr signatures BIP

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 o

Re: [bitcoin-dev] Schnorr signatures BIP

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. > &g

Re: [bitcoin-dev] Schnorr signatures BIP

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 signatures,

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

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] Safer sighashes and more granular SIGHASH_NOINPUT

undant, with worse > 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.linuxfou

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

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 consi

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

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(sc

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

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 immediatel

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

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 w

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

c 10, 2018 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 com

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

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 > default “signing all” sighash, and 65-byte for other sighash types. The > space saved will allow a few more txs in a block, so I think it worths > doing. However, this also

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

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

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 w

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

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 includ

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

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 i

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

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 mon

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

> * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation. > This includes OP_CODESEPARATORs in unexecuted branches of if statements, > similar to other disabled opcodes, but unlike OP_RETURN. > OP_CODESEPARATOR is the only mechanism available that allows users to sign which particul

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

> * 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] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

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 special

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

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 > > statements

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

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 per

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

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

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 as

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

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 disab

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

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 wi

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

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

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] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

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] Taproot proposal

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 > the

[bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

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 f

Re: [bitcoin-dev] Taproot proposal

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 the

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

eparate > 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

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

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

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 Scr

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

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 complicating

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

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 O

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

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 a

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

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] [PROPOSAL] Emergency RBF (BIP 125)

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 i

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

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 transactio

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

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] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

gt; Can you 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.l

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

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 ra

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

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 ensure

Re: [bitcoin-dev] Taproot proposal

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, whi

Re: [bitcoin-dev] Taproot proposal

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] Bech32 weakness and impact on bip-taproot addresses

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 f

[bitcoin-dev] Signing CHECKSIG position in Tapscript

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 to

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

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 S

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

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 che

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

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

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

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 injection

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

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 plainte

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

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 ke

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

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 check

  1   2   3   >