Re: [bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition

> On 8 Jun 2016, at 15:29, Luke Dashjr <l...@dashjr.org> wrote: > > On Wednesday, June 08, 2016 5:57:36 AM Johnson Lau via bitcoin-dev wrote: >> Why not make it even bigger, e.g. 75 bytes? > > I don't see a sufficient answer to this question. Pieter explained why >

[bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition

Please note that the segregated witness (BIP141) consensus rule is updated. Originally, a witness program is a scriptPubKey or redeemScript that consists of a 1-byte push opcode (OP_0 to OP_16) followed by a data push between 2 and 32 bytes. The definition is now extended to 2 to 40 bytes:

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

How is this compared to my earlier proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html ? In my proposal, only the (pruned) UTXO set, and 32 bytes per archived block,

[bitcoin-dev] BIP114 MAST updated

I have published a new version for BIP114 MAST. It's a bit more complicated with some new features: 1. It allows different parties in a contract not to expose their scripts to each other until redemption. 2. It includes a field to indicate the script language version so new opcodes could be

Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd

Thanks for Peter Todd’s detailed report: https://petertodd.org/2016/segwit-consensus-critical-code-review I have the following response. >Since the reserve value is only a single, 32-byte value, we’re setting >ourselves up for the same problem again7. Please note that unlimited space has been

Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd

> >>> the fact that we do this has a rather odd result: a transaction spending a >>> witness output with an unknown version is valid even if the transaction >>> doesn’t have any witnesses! >> >> I don’t see any reason to have such check. We simply leave unknown witness >> program as

Re: [bitcoin-dev] New BIP: Low S values signatures

> On August 16, 2016 at 6:20 AM Luke Dashjr <l...@dashjr.org> wrote: > > > On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote: > > Specification > > > > Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, >

[bitcoin-dev] New BIP: Low S values signatures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 As discussed in the 11 Aug 2016 IRC meeting (https://bitcoincore.org/en/meetings/2016/08/11/#softfork-to-make-low-s-required), a new BIP with implementation is prepared to make low S value signature as a consensus rule:

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

> On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev > wrote: > > Okay. > > I'm not really opposed to this BIP, but I am worried that fighting script > malleability is a battle that can never be won; even leaving one avenue of >

[bitcoin-dev] Spoonnet: another experimental hardfork

Finally got some time over the Chinese New Year holiday to code and write this up. This is not the same as my previous forcenet ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html ). It is much simpler. Trying to activate it on testnet will get you banned. Trying

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

What you describe is not a fix of replay attack. By confirming the same tx in both network, the tx has been already replayed. Their child txs do not matter. > On 25 Jan 2017, at 09:22, Natanael <natanae...@gmail.com> wrote: > > > > Den 24 jan. 2017 15:33 skrev "J

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> On 25 Jan 2017, at 15:29, Natanael wrote: > > > Den 25 jan. 2017 08:22 skrev "Johnson Lau" >: > Assuming Alice is paying Bob with an old style time-locked tx. Under your > proposal, after the hardfork, Bob is still able to

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Assuming Alice is paying Bob with an old style time-locked tx. Under your proposal, after the hardfork, Bob is still able to confirm the time-locked tx on both networks. To fulfil your new rules he just needs to send the outputs to himself again (with different tx format). But as Bob gets all

Re: [bitcoin-dev] Changing the transaction version number to be varint

> On 20 Jan 2017, at 22:02, Tom Zander via bitcoin-dev > wrote: > > The way to do this is that from a certain block-height the current > transaction format labels bytes 2, 3 & 4 to be unused. > From that same block height the interpretation of the first

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

t; >> To maximize fork divergence, it might make sense to require this. Any >> sensible proposal for a hard fork would include a change to the sighash >> anyway, so might as well make it required, no? >> >> Matt >> >> On 01/24/17 14:33, Johnson

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

(and not on the other), then holders >>> have an incentive to not let their chain die, and the networks will be >>> irreversibly split forever. The goal should be unity not permanent >>> division. >>> >>> On 1/25/17, Matt Corallo via bitcoin-d

[bitcoin-dev] Extension block softfork proposal

This is a pre-BIP which allows extra block space through a soft-fork. It is completely transparent to existing wallets (both send and receive), but new wallets taking advantage of the extra block space will have a very different user experience. I’m sure this is controversial but I think it’s

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

I can’t recommend your first 2 proposals. But I only have the time to talk about the first one for now. There are 2 different views on this topic: 1. “The block size is too small and people can’t buy a coffee with an on-chain transaction. Let’s just remove the limit” 2. “The block size is too

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

(but not that trivial if the hardfork is not based on segwit) > On 25 Jan 2017, at 02:52, Tom Harding <t...@thinlink.com> wrote: > > On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote: >> 9. If the network characteristic byte is non-zero, and the existing >> network characteristic bit

[bitcoin-dev] Consensus critical limits in Bitcoin protocol and proposed block resources limit accounting

There are many consensus critical limits scattered all over the Bitcoin protocol. The first part of this post is to analyse what the current limits are. These limits could be arranged into different categories: 1. Script level limit. Some limits are restricted to scripts, including size (1

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> On 26 Jan 2017, at 03:32, Tom Harding wrote: > > On 1/24/2017 8:03 PM, Johnson Lau wrote: >> it seems they are not the same: yours is opt-out, while mine is opt-in. > > I missed this. So in fact you propose a self-defeating requirement on the > new network, which would

Re: [bitcoin-dev] Attack by modifying non-segwit transactions after segwit is accepted ?

Thank you so much for taking time to actually review the codes. I hope you will keep raising questions when you feel something might be wrong. This is how things supposed to work and we should not be affected by some forum discussions. > On August 26, 2016 at 9:16 AM Sergio Demian Lerner >

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

uot; or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. > > On August 16, 2016 at 1:53 PM Johnson Lau via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > >

[bitcoin-dev] New BIP: Dealing with dummy stack element malleability

https://github.com/bitcoin/bips/pull/440 https://github.com/bitcoin/bitcoin/pull/8636 This document specifies proposed changes to the Bitcoin transaction validity rules to fix the malleability of extra stack element for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. The original plan was to do

Re: [bitcoin-dev] New BIP: Dealing with dummy stack element malleability

independently softforks would double the risks, and I believe NULLDUMMY alone is not worth the risks. > On September 2, 2016 at 1:10 PM Tom Harding via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On 9/1/2016 9:40 PM, Johnson Lau via bitcoin-de

[bitcoin-dev] Proposed segwit related consensus and policy rules in Bitcoin Core 0.13.1

There are several opening pull requests for segwit related consensus and policy rules. This email summarize and explain the rationale. As a general warning, people must not assume that a script spendable in pre-segwit system would also be spendable as a segwit script. They share much

Re: [bitcoin-dev] Completing the retirement of the alert system

Concept ACK. For the details of executing the plan, I think the following is less disruptive: 1. Send a message with (max sequence - 1), notifying all nodes that the key will be retired on or before a date. People with systems relying on this key should either upgrade or ignore the revocation

Re: [bitcoin-dev] Completing the retirement of the alert system

We need to make sure the revocation message is widely distributed before making the private key public On Sat, 10 Sep 2016 21:23:37 +0800 Andrew C <achow...@gmail.com> wrote > On 9/10/2016 5:41 AM, Johnson Lau via bitcoin-dev wrote: > > 3. After a few months

[bitcoin-dev] New BIP: Limiting excessive SignatureHash operation

A new BIP is proposed to prevent excessive O(n^2) SignatureHash operation. https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki https://github.com/bitcoin/bitcoin/pull/8755 (Tight estimation) https://github.com/bitcoin/bitcoin/pull/8756 (Loose estimation) Two methods of sighash

[bitcoin-dev] To-be-softfork policy in 0.13.1

Coupled with the release of segwit in 0.13.1, there are 3 default relay and mining policy rules that may become softfork proposals in the near future. Generally, users must not assume that a script spendable in pre-segregated witness system would also be spendable as a P2WPKH or P2WSH script.

Re: [bitcoin-dev] BIP draft: HTLC transactions

> On July 20, 2016 at 2:17 AM Luke Dashjr via bitcoin-dev > wrote: > > On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote: > > > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote: > > > > > I'm requesting

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

> 3. Instead of using a OP_NOPx, I suggest you using an unused code such as > 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that > does not write to the stack. > > Ok. I'm not sure, but if everyone agrees to it, I will. Also Segwit > versioning allows to create

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

Some comments and questions 1. In the BIP you mentioned scriptSig 3 times, but I don't think you are really talking about scriptSig. Especially, segwit has aborted the use of scriptSig to fix malleability. From the context I guess you mean redeemScript (see BIP141) 2. It seems that 51% of

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

In this case I don’t understand how your implementation won’t be DoS-ed. An attacker could keep sending you inv for the same block / transaction. Since you don’t assume the hash is unique, each time you have to download the block/tx again before you could tell if that is the same one you have

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

The fact that some implementations ban an invalid block hash and some do not, suggests that it’s not a pure p2p protocol issue. A pure p2p split should be unified by a bridge node. However, a bridge node is not helpful in this case. Banning an invalid block hash is an implicit “first seen”

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

I’m not sure if you really understand what you and I am talking. It has nothing to do with BIP30, 34, nor any other BIPs. Say tx1 is confirmed 3 years ago in block X. An attacker finds a valid tx2 which (tx1 != tx2) and (SHA256(tx1) == SHA256(tx2)). Now he could replace tx1 with tx2 in block X

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

> On 17 Nov 2016, at 20:22, Eric Voskuil via bitcoin-dev > wrote: > > > Given that hash collisions are unquestionably possible, Everything you said after this point is irrelevant. Having hash collision is **by definition** a consensus failure, or a

Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different way from the Elements. Instead of hashing the data on stack, I directly put the 32 byte hash to the stack. This should be more flexible as not every system are using double-SHA256

Re: [bitcoin-dev] Start time for BIP141 (segwit)

This is completely wrong. SPV wallets will work as normal without upgrade. Full nodes will only provide transactions to SPV in a format they understand, and SPV will accept the transaction since they are not doing any validation anyway. The only reason an end user may want to upgrade is for

Re: [bitcoin-dev] Start time for BIP141 (segwit)

On Mon, 17 Oct 2016 02:54:04 +0800 Tom Zander via bitcoin-dev wrote > Honestly, if the reason for the too-short-for-safety timespan is that you > want to use BIP9, then please take a step back and realize that SegWit is a >

Re: [bitcoin-dev] Start time for BIP141 (segwit)

On Mon, 17 Oct 2016 04:08:29 +0800 Tom Zander via bitcoin-dev wrote > On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote: > > > Honestly, if the reason for the too-short-for-safety timespan is that > > > you > > > want to use

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

I think the biggest problem of sum tree is the lack of flexibility to redefine the values with softforks. For example, in the future we may want to define a new CHECKSIG with witness script version 1. That would be counted as a SigOp. Without a sum tree design, that’d be easy as we could just

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

> On 5 Dec 2016, at 04:00, adiabat wrote: > > Interesting stuff! I have some comments, mostly about the header. > > The header of forcenet is mostly described in Luke’s BIP, but I have made > some amendments as I implemented it. The format is (size in parentheses; > little

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

> On 14 Dec 2016, at 19:07, Luke Dashjr <l...@dashjr.org> wrote: > > On Wednesday, December 14, 2016 11:01:58 AM Johnson Lau via bitcoin-dev wrote: >> There is no reason to use a timestamp beyond 4 bytes. > > Actually, there is: lock times... my overflow solution

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

There is no reason to use a timestamp beyond 4 bytes. Just let it overflow. If a blockchain is stopped for more than 2^31 seconds, it’s just dead. > On 5 Dec 2016, at 19:58, Tom Zander via bitcoin-dev > wrote: > > On Sunday, 4 December 2016 21:37:39 CET

[bitcoin-dev] New BIP: Hardfork warning system

This BIP defines a change in consensus rules regarding to block nVersion, and define a concept of generalized block header to implement a hardfork warning system for full nodes and light nodes. For better formatting, visit github

[bitcoin-dev] Forcenet: an experimental network with a new header format

Based on Luke Dashjr’s code and BIP: https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki , I created an experimental network to show how a new header format may be implemented. Basically, the header hash is calculated in a way that non-upgrading nodes would see it as a block with

Re: [bitcoin-dev] Script Abuse Potential?

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 if the returned item is within the 520 bytes limit. > On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev >

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> On 29 Mar 2017, at 14:24, Emin Gün Sirer via bitcoin-dev > wrote: > > >Even when several of the experts involved in the document you refer has my > >respect and admiration, I do not agree with some of their conclusions > > I'm one of the co-authors of

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> On 29 Mar 2017, at 04:50, Tom Zander <t...@freedommail.ch > <mailto:t...@freedommail.ch>> wrote: > > On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote: >> So if we really want to get prepared for a potential HF with unknown >> par

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

You are probably not the first one nor last one with such idea. Actually, Luke wrote up a BIP with similar idea in mind: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki Instead of just lifting the block

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

This is the first of a series of BIPs describing my “spoonnet” experimental hardfork. Recently many bitcoin businesses expressed their requirements for supporting a hardfork proposal. While it is proven to be extremely difficult to obtain community-wide consensus, spoonnet fulfills all the

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

> On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun wrote: > > > The concrete parameters chosen in the proposal are: each channel opening > transaction reserves 700-bytes within _each_ block in the chain until the > transaction has been closed. > > Why so? It seems you are

Re: [bitcoin-dev] Using a storage engine without UTXO-index

> On 8 Apr 2017, at 15:28, Tomas via bitcoin-dev > wrote: >> > > I think you are being a bit harsh here . I am also clearly explaining > the difference only applies to peak load, and just making a suggestion. > I simply want to stress the importance of

Re: [bitcoin-dev] Using a storage engine without UTXO-index

> On 9 Apr 2017, at 03:56, Tomas wrote: > > >> I don’t fully understand your storage engine. So the following deduction >> is just based on common sense. >> >> a) It is possible to make unlimited number of 1-in-100-out txs >> >> b) The maximum number of 100-in-1-out txs is

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

> On 3 Apr 2017, at 04:39, Russell O'Connor <rocon...@blockstream.io> wrote: > > On Sun, Apr 2, 2017 at 4:13 PM, Johnson Lau via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: >

[bitcoin-dev] A different approach to define and understand softforks and hardforks

Softforks and hardforks are usually defined in terms of block validity (BIP99): making valid blocks invalid is a softfork, making invalid blocks valid is a hardfork, and SFs are usually considered as less disruptive as it is considered to be “opt-in”. However, as shown below this technical

Re: [bitcoin-dev] Segwit v2

> On 27 Apr 2017, at 04:01, Luke Dashjr wrote: > > On Wednesday 26 April 2017 7:31:38 PM Johnson Lau wrote: >> I prefer not to do anything that requires pools software upgrade or wallet >> upgrade. So I prefer to keep the dummy marker, and not change the >> commitment structure

Re: [bitcoin-dev] Segwit v2

I prefer not to do anything that requires pools software upgrade or wallet upgrade. So I prefer to keep the dummy marker, and not change the commitment structure as suggested by another post. For your second suggestion, I think we should keep scriptSig empty as that should be obsoleted. If you

Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)

As other explained, your scheme is broken. Unless we have a softfork first (OP_CHECKBIP9VERIFY: payment is valid only if a BIP9 proposal is active), it is not possible to create a softfork bounty in a decentralised way On the other hand, hardfork bounty is very simple. You just need to make

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

To make it completely transparent to unupgraded wallets, the return outputs have to be sent to something that is non-standard today, i.e. not P2PK, P2PKH, P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH. Mainchain segwit is particularly important here, as that allows atomic swap

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

No, changing from 50% to 75% is a hardfork. (75 -> 50 is a softfork). Unless you make it pre-scheduled, or leave a special “backdoor” softfork to change the discount. And that would certainly reduce the max tx/s with 50% discount, also reduce the incentive to spend witness UTXO. > On 10 May

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

> On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev > wrote: > > > So it seems the 75% discount has been chosen with the idea that in the future > the current transaction pattern will shift towards multisigs. This is not a > bad idea, as

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

> On 19 Sep 2017, at 11:09 AM, Luke Dashjr via bitcoin-dev > wrote: > > On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev > wrote: >> After the main discussion session it was observed that tail-call semantics >> could still be

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

> On 21 Sep 2017, at 3:29 AM, Mark Friedenbach wrote: > > >> On Sep 19, 2017, at 10:13 PM, Johnson Lau wrote: >> >> If we don’t want this ugliness, we could use a new script version for every >> new op code we add. In the new BIP114 (see link above), I

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

> On 22 Sep 2017, at 12:33 AM, Luke Dashjr wrote: > > On Thursday 21 September 2017 8:02:42 AM Johnson Lau wrote: >> I think it’s possible only if you spend more witness space to store the >> (pubkey, message) pairs, so that old clients could understand the >> aggregation

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

> On 21 Sep 2017, at 12:11 PM, Luke Dashjr wrote: > > On Wednesday 20 September 2017 5:13:04 AM Johnson Lau wrote: >> 2. OP_RETURNTRUE does not work well with signature aggregation. Signature >> aggregation will collect (pubkey, message) pairs in a tx, combine them, >> and

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

Some comments with the tail-call execution semantics BIP: Tail-call execution semantics require “unclean stake”, i.e. final stake with more than one item. However, “unclean stake” is invalid (not just non-standard) in BIP141, so you could only use it with legacy P2SH (which is totally

[bitcoin-dev] BIP114 Merklized Script update and 5 BIPs for new script functions

I have rewritten and simplified BIP114, and renamed it to “Merklized Script”, as a more accurate description after consulting the original proposers of MAST. It could be considered as a special case of MAST, but has basically the same functions and scaling properties of MAST. Compared with

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

> On 12 Sep 2017, at 10:03 AM, Mark Friedenbach wrote: > > My apologies for a delay in responding to emails on this list; I have > been fighting a cold. > > (Also my apologies to Johnson Lau, as I forgot to forward this to the list.) > > On Sep 8, 2017, at 2:21 AM,

Re: [bitcoin-dev] Fast Merkle Trees

> On 8 Sep 2017, at 4:04 AM, Mark Friedenbach via bitcoin-dev > wrote: > > If I understand the revised attack description correctly, then there > is a small window in which the attacker can create a script less than > 55 bytes in length, where nearly all

Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

Yes it is allowed in TxOuts. And yes it is designed to save space. But the problem is Bob can’t assume Alice understands the new TxOuts format. If Bob really wants to save space this way, he should first ask for a new BIP173 address from Alice. Never try to convert a P2PKH address to a P2SH or

[bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard

In https://github.com/bitcoin/bitcoin/pull/11423 I propose to make OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard I think FindAndDelete() is one of the most useless and complicated functions in the script language. It is

Re: [bitcoin-dev] Why SegWit Anyway?

We can’t “just compute the Transaction ID the same way the hash for signing the transaction is computed” because with different SIGHASH flags, there are 6 (actually 256) ways to hash a transaction. Also, changing the definition of TxID is a hardfork change, i.e. everyone are required to

Re: [bitcoin-dev] Why SegWit Anyway?

Not really. BIP140 might be easier to implement, but in longterm the UTXO overhead is significant and unnecessary. There are also other benefits of segwit written in BIP141. Some of those are applicable even if you are making a new coin. > On 21 Nov 2017, at 2:07 AM, Praveen Baratam

Re: [bitcoin-dev] Making OP_TRUE standard?

You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The

Re: [bitcoin-dev] Making OP_TRUE standard?

> On 10 May 2018, at 3:27 AM, Peter Todd <p...@petertodd.org> wrote: > > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: >> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but >> nothing else. This makes sure CPF

Re: [bitcoin-dev] Should Graftroot be optional?

> On 24 May 2018, at 10:08 AM, Gregory Maxwell via bitcoin-dev > wrote: > > On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev > wrote: >> Thanks everyone who commented so far, but let me clarify the

Re: [bitcoin-dev] Should Graftroot be optional?

While you have rescind your concern, I’d like to point out that it’s strictly a problem of SIGHASH_NOINPUT, not graftroot (or script delegation in general). For example, we could modify graftroot. Instead of signing the (script), we require it to sign (outpoint | script). That means a graftroot

[bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE

I’ve made a PR to add a new policy to disallow using SIGHASH_SINGLE without matched output: https://github.com/bitcoin/bitcoin/pull/13360 Signature of this form is insecure, as it commits to no output while users might think it commits to one. It is even worse in non-segwit scripts, which is

[bitcoin-dev] SIGHASH2 for version 1 witness programme

Since 2016, I have made a number of proposals for the next generation of script. Since then, there has been a lot of exciting development on this topic. The most notable ones are Taproot and Graftroot proposed by Maxwell. It seems the most logical way is to implement MAST and other new script

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

> On 2 Jun 2018, at 2:15 AM, Russell O'Connor wrote: > > > I prefer a different opcode for CHECKSIGFROMSTACK because I dislike opcodes > that pop a non-static number of elements off the stack. Popping a dynamic > number of stack elements makes it more difficult to validate that a Script >

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

> 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 > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > Double SHA256 of the serialization of: > > Should we replace

[bitcoin-dev] Alternative way to count sigops

Short history Satoshi introduced sigops counting as a softfork to limit the number of signature operation in a block. He statically counted all OP_CHECK(MULTI)SIG(VERIFY) in both scriptSig and scriptPubKey, assumed a OP_CHECKMULTISIG is equivalent to 20 OP_CHECKSIG, and

Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

To determine the new difficulty, it is supposed to compare the timestamps of block (2016n - 1) with block (2016n - 2017). However, an off-by-one bug makes it compares with block (2016n - 2016) instead. A naive but perfect fix is to require every block (2016x) to have a timestamp not smaller

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

value. If in a multi-sig setup some signers are unable to accurately estimate the witness size, they should leave this responsibility to the last signer who should know the exact size. > On 1 Jun 2018, at 2:35 AM, Johnson Lau via bitcoin-dev > wrote: > > Since 2016, I

Re: [bitcoin-dev] Testnet3 Reest

A public testnet is still useful so in articles people could make references to these transactions. Maybe we could have 2 testnets at the same time, with one having a smaller block size? > On 31 Aug 2018, at 4:02 AM, Peter Todd via bitcoin-dev > wrote: > > Signed PGP part > On Thu, Aug 30,

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

on more >> difficult >> 4. Should we sign the exact witness size (as proposed), or an upper size >> limit? Signing an upper limit will take up more space, as the limit has to >> be explicitly shown in the witness. The overhead could be avoided by showing >> the l

Re: [bitcoin-dev] BIP 117 Feedback

Altstack in v0 P2WSH should be left untouched. If anyone is already using altstack, BIP117 would very likely confiscate those UTXOs because the altstack would unlikely be executable. Even in v1 witness, I think altstack should remain be a temporary data storage. The “(many scripts)

Re: [bitcoin-dev] BIP sighash_noinput

In BIP143, the nSequence of the same input is always signed, with any hashtype. Why do you need to sign the sequence of other inputs? > On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev > wrote: > >> At the risk of bikeshedding, shouldn't NOINPUT also zero out the >> hashSequence so that

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

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 makes witness weight estimation more difficult in

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 20 Dec 2018, at 6:09 AM, Christian Decker > wrote: > > Ruben Somsen via bitcoin-dev > > writes: > >> Hi Johnson, >> >> The design considerations here seem similar to the ML discussion of >> whether Graftroot should be optional [1]. >> >>>

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 21 Dec 2018, at 1:20 AM, Christian Decker > wrote: > > Johnson Lau writes: >> Correct me if I’m wrong. >> >> For the sake of simplicity, in the following I assume BIP118, 143, and >> 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible >> optimisations. >> >> 1. A

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

> On 17 Dec 2018, at 11:10 AM, Rusty Russell wrote: > > Johnson Lau writes: >> I don’t think this has been mentioned: without signing the script or masked >> script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT. >> >> In the new sighash proposal, we will sign the hash of the

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

> On 21 Dec 2018, at 7:17 AM, Rusty Russell wrote: > > Johnson Lau writes: > >>> But I don't see how OP_CODESEPARATOR changes anything here, wrt NOINPUT? >>> Remember, anyone can create an output which can be spent by any NOINPUT, >>> whether we go for OP_MASK or simply not commiting to the

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 21 Dec 2018, at 7:15 PM, Christian Decker > wrote: > > Johnson Lau writes: > >> I think the use of OP_CSV (BIP112) is not needed here (although it >> doesn’t really harm except taking a few more bytes). All you need is >> to sign the settlement tx with a BIP68 relative locktime. Since

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 21 Dec 2018, at 7:40 PM, ZmnSCPxj wrote: > > Good morning Johnson, > >> The proposed solution is that an output must be “tagged” for it to be >> spendable with NOINPUT, and the “tag” must be made explicitly by the payer. >> There are 2 possible ways to do the tagging: > > First off,

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

> On 12 Dec 2018, at 6:50 AM, Russell O'Connor 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 default > “signing all” sighash, and 65-byte for other sighash types. The space saved >

[bitcoin-dev] Safer NOINPUT with output tagging

NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 22 Dec 2018, at 10:25 PM, ZmnSCPxj wrote: > > Good morning Johnson, > >> Generally speaking, I think walletless protocol is needed only when you want >> to rely a third party to open a offchain smart contract. It could be >> coinswap, eltoo, or anything similar. > > I think a third

  1   2   >