Re: [bitcoin-dev] Two questions about segwit implementation

Empty scriptSig doesn’t imply segwit input: if the previous scriptPubKey is OP_1 (which does not allow witness), it could still be spent with an empty scriptSig Similarly, a scriptSig looking like a spend of P2SH-segwit doesn’t imply segwit input: if the previous scriptPubKey is empty, it

Re: [bitcoin-dev] Two questions about segwit implementation

This is not how it works. While the transaction creator may know which inputs are segwit, the validators have no way to tell until they look up the UTXO set. In a transaction, all information about an input the validators have is the 36-byte outpoint (txid + index). Just by looking at the

Re: [bitcoin-dev] Two questions about segwit implementation

> On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev > wrote: > > I realized recently that my segwit implementation was not correct, > basically some time ago, wrongly reading the specs (and misleaded by > what follows), I thought that scriptsig would go into witness data as it > was,

Re: [bitcoin-dev] Safety of committing only to transaction outputs

> On 25 May 2019, at 4:59 AM, Jeremy wrote: > > Hi Johnson, > > As noted on the other thread, witness replay-ability can be helped by salting > the taproot key or the taproot leaf script at the last stage of a congestion > control tree. > The salt will be published when it is first spent.

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

Functionally, COHV is a proper subset of ANYPREVOUT (NOINPUT). The only justification to do both is better space efficiency when making covenant. With eltoo as a clear usecase of ANYPREVOUT, I’m not sure if we really want a very restricted opcode like COHV. But these are my comments, anyway:

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

A gamble like this, decentralised or not, is easy to manipulate since difficulty is determined entirely by the last block in a cycle > On 24 May 2019, at 1:42 AM, Tamas Blummer via bitcoin-dev > wrote: > > Difficulty change has profound impact on miner’s production thereby introduce > the

[bitcoin-dev] Safety of committing only to transaction outputs

This is a meta-discussion for any approach that allows the witness committing to only transaction outputs, but not inputs. We can already do the following things with the existing bitcoin script system: * commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with optional

Re: [bitcoin-dev] Taproot proposal

> >> >> Some way to sign an additional script (not committed to by the witness >> program) seems like it could be a trivial addition. > > It seems to me the annex can be used for this, by having it contain both the > script and the signature somehow concatenated. This is not possible since

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

> On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev > wrote: > > Good morning aj, >> >> If you are committing to the script code, though, then each settlement >> sig is already only usable with the corresponding update tx, so you >> don't need to roll the keys. But you do need to make it

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

> On 20 Mar 2019, at 4:07 PM, ZmnSCPxj via bitcoin-dev > wrote: > > Hi aj, > > Re-reading again, I think perhaps I was massively confused by this: > >> - alternatively, we could require every script to have a valid signature >> that commits to the input. In that case, you could do eltoo

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

the coin is lost due to previous NOINPUT use. A much stronger >> way is to publish the key after a coin is well confirmed. >> >>> On 20 Feb 2019, at 3:04 AM, Luke Dashjr wrote: >>> >>> On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-de

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

is well confirmed. > On 20 Feb 2019, at 3:04 AM, Luke Dashjr wrote: > > On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote: >> While this seems fully compatible with eltoo, is there any other proposals >> require NOINPUT, and is adversely affected by

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

;>> settlement outputs update output >>> [ A & B & C ] -> ... -> [ (A & B & C & state CLTV) | (As & Bs & Cs) ] -> [ >>> NOINPUT tagged: (A' & B'), -> ... >>>

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

e CLTV) | (As & Bs & Cs) ] -> [ >> NOINPUT tagged: (A' & B'), -> ... >> >> C' ] >> If the expectation is that the unresponsive party returns, fungibility is >> not reduced due to output ta

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

due to output tagging because the above scheme can be used > off-chain until the original channel can be continued. > > Side note: I was not able to come up with an similar, eltoo-like protocol > that works > if you can't predict in advance who will become absent. > > On 12/13

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

I find another proposed use of CODESEPARATOR here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000455.html OP_CHECKSIG OP_IF OP_ELSE OP_CSV OP_DROP OP_CODESEPARATOR OP_ENDIF

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

> On 23 Dec 2018, at 12:26 PM, Anthony Towns wrote: > > On Sat, Dec 22, 2018 at 02:54:42AM +0800, Johnson Lau wrote: >> The question I would like to ask is: is OP_CODESEPARATOR useful under >> taproot? Generally speaking, CODESEPARATOR is useful only with conditional >> opcodes (OP_IF etc),

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

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 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 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 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 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev > wrote: > > > >> On 17 Dec 2018, at 11:48 PM, Ruben Somsen > <mailto:rsom...@gmail.com>> wrote: >> >> Hi Johnson, >> >> The design considerations here seem similar to the ML

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

> On 18 Dec 2018, at 12:58 PM, Anthony Towns wrote: > > On Mon, Dec 17, 2018 at 10:18:40PM -0500, Russell O'Connor wrote: >> On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau wrote: >>But I’m not sure if that would do more harm than good. For example, people >>might lose money by copying an

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

> On 16 Dec 2018, at 7:38 AM, Russell O'Connor via bitcoin-dev > wrote: > > On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev > > wrote: > 5. if there's exactly one, non-zero item on the stack; succeed > > Unless it is too

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

is truly unavoidable" > > Cheers, > Ruben Somsen > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006.html > [2] > https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_statechains_offchain_transfer_of/ > > On Mon

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

> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev > wrote: > > Anthony Towns via bitcoin-dev writes: >> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev >> wrote: >>> And is it worthwhile doing the mask complexity, rather than just >>> removing the

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

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 full script (or masked script), without any truncation. To make OP_CODESEPARATOR works like

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

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

This is incompatible with bip-schnorr, which intentionally disallow such use by always committing to the public key: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki With the recent fake Satoshi signature drama, and other potential ways to misuse and abuse, I think this is a

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

> On 28 Nov 2018, at 11:41 AM, Pieter Wuille via bitcoin-dev > wrote: > > So a combined proposal: > * All existing sighash flags, plus NOINPUT and MASK > (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits). > * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is > failing if not

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

> On 23 Nov 2018, at 5:40 PM, Christian Decker via bitcoin-dev > wrote: > > Anthony Towns writes: >> Commiting to just the sequence numbers seems really weird to me; it >> only really prevents you from adding inputs, since you could still >> replace any input that was meant to be there by

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

>Even still, each call to OP_CODESEPARATOR / OP_CHECKSIG pair requires >recomputing a new #5. scriptCode from BIP 143, and hence computes a new >transaction digest. In the existing sighash (i.e. legacy and BIP143), there are 6 canonical SIGHASH types: 1, 2, 3, 0x81, 0x82, 0x83. In consensus,

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

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 considered. >each call to this operation effectively takes

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

With MAST in taproot, OP_IF etc become mostly redundant, 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 >

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

If we sign the txids of all inputs, we should also explicitly commit to their values. Only this could fully eliminate any possible way to lie about input value to hardware wallets > Does it make sense to keep SIGHASH_NONE? SIGHASH_NONE should be kept. ANYONECANPAY|NONE allows donation of dust

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

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

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

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

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

[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

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

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

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

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

> 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

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

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

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

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

(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

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

> 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

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

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

[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

  1   2   >