Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

On Wed, Jun 15, 2016 at 7:00 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: Indeed, and you can go even further. When there are multiple "sending" > outputs, pick one at random, and mimic it for the change output. This means > that if you have a P2PKH and 3 P2SH

Re: [bitcoin-dev] Making AsicBoost irrelevant

Is the design and manufacturing processes for the most power efficient ASICs otherwise patent unencumbered? If not, why do we care so much about this one patent over all the others that stand on the road between pen and paper computation and thermodynamically ideal computation? On Wed, May 11,

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 16, 2016 at 07:37:19PM +, Luke Dashjr via bitcoin-dev > wrote: > > On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote: > > > A new BIP is prepared to

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

On Tue, Aug 16, 2016 at 6:30 PM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > If one's goal is to mess with an transaction to prevent it fro

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

I see. But is it really necessary to soft fork over this issue? Why not just make it a relay rule? Miners are already incentivized to modify transactions to drop excess witness data and/or prioritize (versions of) transactions based on their cost. If a miner wants to mine a block with excess

Re: [bitcoin-dev] Three hardfork-related BIPs

On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" wrote: Other researchers have come to the conservative conclusion that we could handle 4MB blocks today. I believe this is a mischaracterization of the research conclusions. The actual conclusion

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

For sake of example, suppose we have a marginal fee rate of 50 satoshis per byte. At that rate reducing the size of the witness data by 1 byte is approximately equivalent from a miner and relayer's perspective as a replace by fee that increases the fee by 50 satoshis. In both cases miners get an

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

I believe Bitcoin currently enjoys the property that during an "innocent" re-org, i.e. a reorg in which no affected transactions are being double spent, all affected transactions can always eventually get replayed, so long as the re-org depth is less than 100. My concern with this proposed

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

If I understand this BIP correctly, the values pushed onto the stack by the OP_COUNT_ACKS operation depends on the ack and nack counts relative to the block that this happens to be included in. This isn't going to be acceptable. The validity of a transaction should always be monotone in the

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

> I don't know if it's possible to implement decentralised sidechains without > "breaking" this rule. > I haven't really been following the sidechain developements, but my understanding was that redemption from a side chain would be two phase. The person unpegging the funds provides a proof that

[bitcoin-dev] Fwd: Re: Drivechain proposal using OP_COUNT_ACKS

s affects fungabity of coins generated from these transactions. > > > On Oct 2, 2016 18:37, "Sergio Demian Lerner" <sergio.d.ler...@gmail.com> wrote: >> >> >> >> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev < bitcoin-dev@lis

Re: [bitcoin-dev] Flexible Transactions.

On Mon, Nov 21, 2016 at 3:28 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks for your email, Russell. > > Unfortunately you waited 6 weeks with writing this and the problem you are > seeing has been fixed quite some time ago. > Oh, that is good news! I

[bitcoin-dev] Flexible Transactions.

Hi Tom, On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev wrote: > > The OP_CHECKSIG is the most well known and, as its name implies, it > validates a signature. > In the new version of 'script' (version 2) the data that is signed is > changed to be

Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

uot;—should this say "to the end of the signature"? > Probably should reed "Notice that we have appended 0x8300 to the end of the transaction data". I'll make an update. > > On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.lin

Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

sing double-SHA256 > > https://github.com/jl2012/bitcoin/commits/mast_v3_master > > > On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi all, > > It is possible to implement covenants using two scri

[bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

Hi all, It is possible to implement covenants using two script extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already available in the Elements Alpha sidechain, so it is possible to construct covenants in Elements Alpha today. I have detailed how the construction

Re: [bitcoin-dev] Script Abuse Potential?

For the record, the OP_CAT limit of 520 bytes was added by Satoshi on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT was disabled. The previous

Re: [bitcoin-dev] Script Abuse Potential?

OP_2DUP? Why not OP_3DUP? On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > No, there could only have not more than 201 opcodes in a script. So you > may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB > > For OP_CAT, just check

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

On Sun, Apr 2, 2017 at 4:13 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > • the witness of the first input of the coinbase transaction MUST > have exactly one stack item (the "extended header"), with the following > data: > • bytes 0 to

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

Hi Jonathan, The proposal raised here does not deny miners the ability to use ASICBOOST. Miners can still use overt ASICBOOST by version bit fiddling and get the same power savings. In fact, overt ASICBOOST is much easier to implement than covert ASICBOOST, so I don't really understand what the

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

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

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

Re: [bitcoin-dev] Segwit v2

On Wed, Apr 26, 2017 at 4:01 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There are things scriptSig can do that witness cannot today - specifically > add > additional conditions under the signature. We can always obsolete scriptSig > later, after segwit has

[bitcoin-dev] Quadratic Hashing in BIP 134

I noticed that the the latest BIP 134 now supports SIGHASH_SINGLE and friends. However, this support seems to reintroduce some quadratic hashing behavior because it calls

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

I recall chatting about this idea recently and my conclusion was the same as Peter Todd's conclusion: this will just encourage miners to false signal readiness with undermines both BIP 9 and BIP 8. I felt that rather than using script system for this construction, it would be better to use the

Re: [bitcoin-dev] Per-block non-interactive Schnorr signature aggregation

I'm a bit amateur at this sort of thing, but let me try to argue that this proposal is in fact horribly broken ;) Suppose Alice has some UTXO with some money Bob wants to steal. Grant me that the public key P0 protecting Alice's UTXO is public (say because the public key has been reused

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr wrote: > Versionbits change/lose their meaning after the deployment timeout. For > this > reason, the timeout must be specified so the check is skipped when that > occurs. > To add a timeout a user can optionally bundle a pair of

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On May 22, 2017 23:05, "Peter Todd" <p...@petertodd.org> wrote: On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev wrote: > MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) > sha256Compress : Word256 × Word512 -> Word256 To be clear, wh

[bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

## Introduction This document aims to specify and justify a method for computing Merkle roots for tree structures whose nodes are annotated with other data. While this proposal could be used to replace Bitcoin's Merkle root calculation, it is primarily aimed at new applications such as MAST,

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

lt;p...@petertodd.org> wrote: > > On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev > wrote: > > MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) > > sha256Compress : Word256 × Word512 -> Word256 > > To be clear, what math operations

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Sun, May 28, 2017 at 4:26 AM, Peter Todd <p...@petertodd.org> wrote: > On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev > wrote: > > Not all of the inputs to the SHA256 compression function are created > > equal. Only the second argument, th

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Mon, May 29, 2017 at 12:10 PM, Peter Todd wrote: > On Mon, May 29, 2017 at 10:55:37AM -0400, Russell O'Connor wrote: > > Some of this proposal can be salvaged, I think, by putting the hash of > the > > tags into Sha256Compress's first argument: > > > > merkleRoot :

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,

Re: [bitcoin-dev] Fast Merkle Trees

On Thu, Sep 7, 2017 at 1:55 AM, Peter Todd <p...@petertodd.org> 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 us

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

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

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

[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

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

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

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.

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

[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

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

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'Connor via bitcoin-dev

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

atever condition they 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 <bitcoin-dev@lists.linuxfoundation.org&

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

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

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 =

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

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

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

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

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

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

[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

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

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

[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

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

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,

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

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

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

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

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

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. > > Is

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

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 to be

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

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.

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

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

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

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

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 weight

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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] 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

  1   2   3   >