Re: [bitcoin-dev] Memory leaks?

2015-10-23 Thread Rusty Russell via bitcoin-dev
Btc Drak via bitcoin-dev writes: > I think this thread has gotten to the stage where it should be moved > to an issue on Github and not continue to CC the bitcoin-dev list (or > any other list tbh). Agreed. I couldn't see an issue, so I've opened one.

Re: [bitcoin-dev] Compatibility requirements for hard or soft forks

2015-10-31 Thread Rusty Russell via bitcoin-dev
Gavin Andresen via bitcoin-dev writes: > Should it be a requirement that ANY one-megabyte transaction that is valid > under the existing rules also be valid under new rules? > > Pro: There could be expensive-to-validate transactions created and given a >

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

2015-10-15 Thread Rusty Russell via bitcoin-dev
Btc Drak writes: > Alex, > > I am sorry for not communicating more clearly. Mark and I discussed your > concerns from the last meeting and he made the change. The BIP text still > needs to be updated, but the discussed change was added to the PR, albeit > squashed making it

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

2015-10-15 Thread Rusty Russell via bitcoin-dev
Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: >>From a practical perspective: yuck. There's currently no way to play > with bitcoind's perception of time, so that's a very long sleep to > blackbox test (which is what my lightning test script does

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

2015-08-30 Thread Rusty Russell via bitcoin-dev
jl2...@xbt.hk writes: Rusty Russell 於 2015-08-26 23:08 寫到: - We should immediately deploy an IsStandard() rule which insists that nSequence is 0x or 0, so nobody screws themselves when we soft fork and they had random junk in there. This is not needed because BIP68 is not active

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

2015-08-26 Thread Rusty Russell via bitcoin-dev
Btc Drak via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org writes: This BIP has been assigned BIP112 by the BIP repository maintainer. I have updated the pull request accordingly. Regarding the suggestion to cannibalise version, by your own disadvantage list, we would lose fine grained

[bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-13 Thread Rusty Russell via bitcoin-dev
Hi all, Those who've seen the original versionbits bip, this adds: 1) Percentage checking only on retarget period boundaries. 2) 1 retarget period between 95% and activation. 3) A stronger suggestion for timeout value selection. https://gist.github.com/rustyrussell/47eb08093373f71f87de

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-16 Thread Rusty Russell via bitcoin-dev
Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> '''States''' >> With every softfork proposal we associate a state BSt

[bitcoin-dev] Versionbits BIP (009) minor revision proposal.

2015-09-29 Thread Rusty Russell via bitcoin-dev
Hi all, Pieter and Eric pointed out that the current BIP has miners turning off the bit as soon as it's locked in (75% testnet / 95% mainnet). It's better for them to keep setting the bit until activation (2016 blocks later), so network adoption is visible. I'm not proposing another

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-29 Thread Rusty Russell via bitcoin-dev
Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: >> '''Success: Activation Delay''' >> The consensus rules related to ''locked-in'' soft fork will be enforced in >> the

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

2015-09-29 Thread Rusty Russell via bitcoin-dev
"Wladimir J. van der Laan via bitcoin-dev" writes: > On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote: > >> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY. > > There appears to be common agreement on that. > > The only source of some

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

2015-09-30 Thread Rusty Russell via bitcoin-dev
Adam Back writes: > I think from discussion with Gavin sometime during the montreal > scaling bitcoin workshop, XT maybe willing to make things easy and > adapt what it's doing. For example in relation to versionBits Gavin > said he'd be willing to update XT with an

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

2015-09-30 Thread Rusty Russell via bitcoin-dev
Gregory Maxwell writes: > I can, however, argue it the other way (and probably have in the > past): The bit is easily checked by thin clients, so thin clients > could use it to reject potentially ill-fated blocks from non-upgraded > miners post switch (which otherwise they

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

2015-10-01 Thread Rusty Russell via bitcoin-dev
Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > Gregory Maxwell <gmaxw...@gmail.com> writes: >> I can, however, argue it the other way (and probably have in the >> past): The bit is easily checked by thin clients, so thin client

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

2015-10-05 Thread Rusty Russell via bitcoin-dev
Peter Todd via bitcoin-dev writes: > However I don't think we've done a good job showing why we need to > implement this feature via nSequence. It could be implemented in other ways, but nSequence is the neatest and most straightforward I've seen. - I'm

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

2015-09-18 Thread Rusty Russell via bitcoin-dev
Mark Friedenbach via bitcoin-dev writes: > Eric, that would be, I think, my sequencenumbers2 branch in which nSequence > is an explicit relative lock-time field (unless the most significant bit is > set). That has absolutely clear semantics. You should

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-20 Thread Rusty Russell via bitcoin-dev
Jorge Timón writes: > I disagree with the importance of this concern and old soft/hardforks will > replace this activation mechanism with height, so that's an argument in > favor of using the height from the start. This is "being discussed" in a > thread branched from bip99's

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-18 Thread Rusty Russell via bitcoin-dev
Tier Nolan via bitcoin-dev writes: > The advantage of enforcing the rule when 75% is reached (but only for > blocks with the bit set) is that miners get early notification that they > have implemented the rule incorrectly.They might produce blocks that >

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-18 Thread Rusty Russell via bitcoin-dev
Jorge Timón via bitcoin-dev writes: > I agree on using height vs time. Rusty, what do you mean by being easier > for bip writers? How is writing "block x" any harder than writing "date y". Three years from drafting is reasonable. How many blocks is that?

Re: [bitcoin-dev] Weak block thoughts...

2015-09-23 Thread Rusty Russell via bitcoin-dev
Gavin Andresen via bitcoin-dev writes: > I don't see any incentive problems, either. Worst case is more miners > decide to skip validation and just mine a variation of the > highest-fee-paying weak block they've seen, but that's not a disaster-- > invalid

Re: [bitcoin-dev] [BIP Draft] Datastream compression of Blocks and Transactions

2015-12-03 Thread Rusty Russell via bitcoin-dev
Gavin Andresen via bitcoin-dev writes: > On Wed, Dec 2, 2015 at 1:57 PM, Emin Gün Sirer < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> How to Do It >> >> If we want to compress Bitcoin, a programming challenge/contest would be >> one of the best ways

Re: [bitcoin-dev] Segregated Witness features wish list

2015-12-13 Thread Rusty Russell via bitcoin-dev
Jannes Faber via bitcoin-dev writes: > Segregated IBLT > > I was just wondering if it would make sense when we have SW to also make > Segregated IBLT? Segregating transactions from signatures and then tune the > parameters such that transactions have a

Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals

2016-01-03 Thread Rusty Russell via bitcoin-dev
Luke Dashjr via bitcoin-dev writes: > On Wednesday, December 30, 2015 6:22:59 PM Tomas wrote: >> > The specification itself looks like an inefficient and bloaty reinvention >> > of version bits. >> >> The actual assignment of version bits isn't clear from

Re: [bitcoin-dev] On the security of softforks

2015-12-20 Thread Rusty Russell via bitcoin-dev
Jonathan Toomim via bitcoin-dev writes: > On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev > wrote: > >> 1) The risk of an old full node wallet accepting a transaction that is >> invalid to the new rules.

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

2015-11-26 Thread Rusty Russell via bitcoin-dev
Eric Lombrozo via bitcoin-dev writes: >>From an app developer's perspective, I think it is pretty blatantly > clear that relative timelock is *the* critical exposed functionality > intended here. As someone who actually developed scripts using CSV, I

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

2016-01-08 Thread Rusty Russell via bitcoin-dev
Matt Corallo writes: > Indeed, anything which uses P2SH is obviously vulnerable if there is > an attack on RIPEMD160 which reduces it's security only marginally. I don't think this is true? Even if you can generate a collision in RIPEMD160, that doesn't help you since

[bitcoin-dev] BIP 151 use of HMAC_SHA512

2016-06-27 Thread Rusty Russell via bitcoin-dev
To quote: > HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). > > K_1 must be the left 32bytes of the HMAC_SHA512 hash. > K_2 must be the right 32bytes of the HMAC_SHA512 hash. This seems a weak reason to introduce SHA512 to the mix. Can we just make: K_1 =

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

2016-01-20 Thread Rusty Russell via bitcoin-dev
xor--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > On Thursday, January 21, 2016 11:20:46 AM Rusty Russell via bitcoin-dev wrote: >> So, what should moderation look like from now on? > > The original mail which announced moderation contains this

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

2016-01-20 Thread Rusty Russell via bitcoin-dev
Dave Scotese via bitcoin-dev writes: > It is a shame that the moderated messages require so many steps to > retrieve. Is it possible to have the "downloadable version" from > https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ for each month >

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

2016-02-29 Thread Rusty Russell via bitcoin-dev
Joseph Poon via bitcoin-dev writes: > Ideally, a 3rd-party can be handed a transaction which can encompass all > prior states in a compact way. For currently-designed Segregated Witness > transactions, this requires storing all previous signatures, which can

Re: [bitcoin-dev] Compact Block Relay BIP

2016-05-10 Thread Rusty Russell via bitcoin-dev
Gregory Maxwell <g...@xiph.org> writes: > On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> I used variable-length bit encodings, and used the shortest encoding >> which is unique to you (including memp

Re: [bitcoin-dev] Simple Bitcoin Payment Channel Protocol v0.1 draft (request for comments)

2016-05-01 Thread Rusty Russell via bitcoin-dev
Rune Kjær Svendsen via bitcoin-dev writes: > Dear list > > I've spent the past couple of months developing a simple protocol for > working with payment channels. I've written up a specification of how > it operates, in an attempt to standardize the

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

2016-06-28 Thread Rusty Russell via bitcoin-dev
Jonas Schnelli writes: >> To quote: >> >>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). >>> >>> K_1 must be the left 32bytes of the HMAC_SHA512 hash. >>> K_2 must be the right 32bytes of the HMAC_SHA512 hash. >> >> This seems a weak reason to introduce

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

2016-06-30 Thread Rusty Russell via bitcoin-dev
Ethan Heilman writes: >>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). >> But that's probably just my crypto ignorance... > > SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of > the length extension property of SHA256. > > If I

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

2016-09-05 Thread Rusty Russell via bitcoin-dev
Johnson Lau via bitcoin-dev writes: > Restriction for segwit OP_IF argument as a policy has got a few concept ACK. > I would like to have more people to ACK or NACK, especially the real users of > OP_IF. I think Lightning network would use that at lot. My

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

2016-09-30 Thread Rusty Russell via bitcoin-dev
Luke Dashjr via bitcoin-dev writes: > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin > scripting system to address reissuing bitcoin transactions when the coins > they > spend have been conflicted/double-spent. > >

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

2017-05-14 Thread Rusty Russell via bitcoin-dev
Russell O'Connor via bitcoin-dev writes: > 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

Re: [bitcoin-dev] Rolling UTXO set hashes

2017-05-22 Thread Rusty Russell via bitcoin-dev
Gregory Maxwell via bitcoin-dev writes: > On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille > wrote: >> just the first - and one that has very low costs and no normative >> datastructures at all. > > The serialization of the txout

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

2017-05-27 Thread Rusty Russell via bitcoin-dev
Matt Corallo writes: > A more important consideration than segwit's timeout is when code can be > released, which will no doubt be several months after SegWit's current > timeout. I was assuming it would be included in the next point release. Cheers, Rusty.

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

2017-05-23 Thread Rusty Russell via bitcoin-dev
Gregory Maxwell via bitcoin-dev writes: > Based on how fast we saw segwit adoption, why is the BIP149 timeout so > far in the future? > > It seems to me that it could be six months after release and hit the > kind of density required to make a stable

[bitcoin-dev] Covenants through merkelized txids.

2017-11-09 Thread Rusty Russell via bitcoin-dev
Hi all, This is an alternative to jl2012's BIPZZZ (OP_PUSHTXDATA[1]). It riffs on the (ab)use of OP_CHECKSIGFROMSTACK that Russell[2] used to implement covenants[3]. I've been talking about it to random people for a while, but haven't taken time to write it up. The idea is to provide a

[bitcoin-dev] Making OP_TRUE standard?

2018-05-08 Thread Rusty Russell via bitcoin-dev
Hi all, The largest problem we are having today with the lightning protocol is trying to predict future fees. Eltoo solves this elegantly, but meanwhile we would like to include a 546 satoshi OP_TRUE output in commitment transactions so that we use minimal fees and then use CPFP (which

Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Rusty Russell via bitcoin-dev
Johnson Lau writes: > 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 That won't propagate :( > Instead, would you consider to use

Re: [bitcoin-dev] BIP sighash_noinput

2018-05-09 Thread Rusty Russell via bitcoin-dev
Anthony Towns via bitcoin-dev writes: > On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev > wrote: >> Given the general enthusiasm, and lack of major criticism, for the >> `SIGHASH_NOINPUT` proposal, [...] > > So first, I'm not sure

Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Rusty Russell via bitcoin-dev
Olaoluwa Osuntokun writes: > What are the downsides of just using p2wsh? This route can be rolled out > immediately, while policy changes are pretty "fuzzy" and would require a > near uniform rollout in order to ensure wide propagation of the commitment > transactions. I

Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-20 Thread Rusty Russell via bitcoin-dev
Jim Posen writes: > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF > on the spending tx? Marco points out that if the parent is RBF, this child inherits it, so we're actually good here. However, Matt Corallo points out that you can block RBF

Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-29 Thread Rusty Russell via bitcoin-dev
Peter Todd writes: > On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote: >> Jim Posen writes: >> > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF >> > on the spending tx? >> >> Marco points ou

Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-31 Thread Rusty Russell via bitcoin-dev
Rusty Russell writes: > AFAICT the optimal DoS is where: > > 1. Attacker sends a 100,000 vbyte tx @1sat/vbyte. > 2. Replaces it with a 108 vbyte tx @2sat/vbyte which spends one of > those inputs. > 3. Replaces that spent input in the 100k tx and does it again. > > It takes 3.5 seconds to

Re: [bitcoin-dev] BIP sighash_noinput

2018-07-02 Thread Rusty Russell via bitcoin-dev
Gregory Maxwell via bitcoin-dev writes: > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > wrote: >> Hi all, >> >> I'd like to pick up the discussion from a few months ago, and propose a new >> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous > > I

[bitcoin-dev] BIP 117 Feedback

2018-01-09 Thread Rusty Russell via bitcoin-dev
I've just re-read BIP 117, and I'm concerned about its flexibility. It seems to be doing too much. The use of altstack is awkward, and makes me query this entire approach. I understand that CLEANSTACK painted us into a corner here :( The simplest implementation of tail recursion would be a

Re: [bitcoin-dev] BIP 117 Feedback

2018-01-15 Thread Rusty Russell via bitcoin-dev
"Russell O'Connor" writes: > However, if I understand correctly, the situation for BIP 117 is entirely > different. As far as I understand there is currently no restrictions about > terminating a v0 witness program with a non-empty alt-stack, and there are > no

Re: [bitcoin-dev] [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

2018-06-21 Thread Rusty Russell via bitcoin-dev
"David A. Harding" writes: > On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote: >> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual >> transaction containing the settlement is expected to have (at least) two >> inputs, with the second one originating the fees.

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

2018-07-12 Thread Rusty Russell via bitcoin-dev
DING FENG writes: > Hi, > > I'm a junior developer and a bitcoin user. > And I have read this thread carefully. > > I'm very worried about "SIGHASH_NOINPUT". > > Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse > address more dangerous. No. A wallet should *never* create

Re: [bitcoin-dev] Signature bundles

2018-04-02 Thread Rusty Russell via bitcoin-dev
Anthony Towns via bitcoin-dev writes: > If you've got one bundle that overpays fees and another that underpays, > you can safely combine the two only if you can put a SIGHASH_ALL sig in > the one that overpays (otherwise miners could just make their own tx

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

2018-12-20 Thread Rusty Russell via bitcoin-dev
Johnson Lau writes: >> On 17 Dec 2018, at 11:10 AM, Rusty Russell wrote: >> My anti-complexity argument leads me to ask why we'd support >> OP_CODESEPARATOR at all? Though my argument is weaker here: no wallet >> need support it. > > Because it could make scripts more compact in some cases? >

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

2018-12-14 Thread Rusty Russell via bitcoin-dev
Pieter Wuille via bitcoin-dev writes: > Here is a combined proposal: > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, > and SIGHASH_SCRIPTMASK. > * A new opcode OP_MASK is added, which acts as a NOP during execution. > * The sighash is computed like in BIP143, but: > * If

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

2018-12-17 Thread Rusty Russell via bitcoin-dev
Johnson Lau writes: >> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev >> wrote: >> >> Pieter Wuille via bitcoin-dev writes: >>> Here is a combined proposal: >>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, >

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

2018-12-17 Thread Rusty Russell via bitcoin-dev
Rusty Russell writes: >> However, I’m not sure if there is any useful NOINPUT case with unmasked >> script. > > This is *not* true of Eltoo; the script itself need not change for the > rebinding (Christian, did something change?). This is wrong, sorry. I re-checked the paper, and the constant

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

2018-12-19 Thread Rusty Russell via bitcoin-dev
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 commitment to script with NOINPUT? It *feels* safer to >> restrict wha

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

2018-12-04 Thread Rusty Russell via bitcoin-dev
Matt Corallo writes: > As an alternative proposal, at various points there have been > discussions around solving the "RBF-pinning" problem by allowing > transactors to mark their transactions as "likely-to-be-RBF'ed", which > could enable a relay policy where children of such transactions

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

2019-01-08 Thread Rusty Russell via bitcoin-dev
Matt Corallo writes: > Ultimately, defining a "near the top of the mempool" criteria is fraught > with issues. While it's probably OK for the original problem (large > batched transactions where you don't want a single counterparty to > prevent confirmation), lightning's requirements are very

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

2018-12-19 Thread Rusty Russell via bitcoin-dev
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 full script (or > masked script), without any truncation. To make

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

2018-12-19 Thread Rusty Russell via bitcoin-dev
Johnson Lau writes: >> 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

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

2019-03-19 Thread Rusty Russell via bitcoin-dev
Anthony Towns writes: > If you publish to the blockchain: ... > 4 can be dropped, state 5 and finish can be altered). Since the CSV delay > is chosen by the participants, the above is still a possible scenario > in eltoo, though, and it means there's some risk for someone accepting > bitcoins

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

2019-03-20 Thread Rusty Russell via bitcoin-dev
Sorry AJ, my prior email was not constructive :( I consider the "my software reused my keys" the most reasonable attack scenario, though still small compared to other lightning attack surfaces. But I understand the general wariness of third-parties reusing SIGHASH_NOINPUT signatures. Since

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

2019-02-13 Thread Rusty Russell via bitcoin-dev
Matt Corallo writes: >>> Thus, even if you imagine a steady-state mempool growth, unless the >>> "near the top of the mempool" criteria is "near the top of the next >>> block" (which is obviously *not* incentive-compatible) >> >> I was defining "top of mempool" as "in the first 4 MSipa", ie.

Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal

2019-05-27 Thread Rusty Russell via bitcoin-dev
Anthony Towns writes: > On Wed, May 22, 2019 at 12:17:31PM +0930, Rusty Russell wrote: >>I prefer to >>change the bip introduction to expliclty shout "THESE SIGNATURE >>HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it >>SIGHASH_UNSAFE_ANYPREVOUT. > >> 4. "Rebinding

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

2019-06-02 Thread Rusty Russell via bitcoin-dev
Hi all, I want to propose a modification to rules 3, 4 and 5 of BIP 125: To remind you of BIP 125: 3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions. 4. The replacement transaction must also pay for its own bandwidth at

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

2019-06-09 Thread Rusty Russell via bitcoin-dev
Matt Corallo writes: > I think this needs significantly improved motivation/description. A few areas > I'd like to see calculated out: > > 1) wrt rule 3, for this to be > obviously-incentive-compatible-for-the-next-miner, I'd think no evicted > transactions would be allowed to be in the next

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

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

Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal

2019-05-22 Thread Rusty Russell via bitcoin-dev
Anthony Towns via bitcoin-dev writes: > Hi everybody! > > Here is a followup BIP draft that enables SIGHASH_ANYPREVOUT and > SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. (This is NOINPUT, > despite the name change) I really like this proposal, and am impressed with how cleanly it

Re: [bitcoin-dev] New BIP for p2p messages/state enabling reconciliation-based protocols (Erlay)

2019-09-27 Thread Rusty Russell via bitcoin-dev
Hi Gleb, Minor feedback on reading the draft: > sendrecon: > uint32version Must be exactly 1 currently. At risk of quoting myself[1]: data doesn't have requirements. Actors do. In this case, I assume you mean "writers must set this to 1". What do readers do if it's

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

2019-06-14 Thread Rusty Russell via bitcoin-dev
"David A. Harding" writes: > On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote: >> If that's true, I don't think this proposal makes it worse. > > Here's a scenario that I think shows it being at least 20x worse. [ Snip ] Indeed

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-28 Thread Rusty Russell via bitcoin-dev
"David A. Harding via bitcoin-dev" writes: > To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults > require each replacement pay a feerate of 10 nBTC/vbyte over an existing > transaction or package, and the defaults also allow transactions or > packages up to 100,000 vbytes in

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

2020-10-14 Thread Rusty Russell via bitcoin-dev
"David A. Harding" writes: > On Thu, Oct 08, 2020 at 10:51:10AM +1030, Rusty Russell via bitcoin-dev wrote: >> Hi all, >> >> I propose an alternative to length restrictions suggested by >> Russell in https://github.com/bitcoin/bips/pull/945 : us

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

2020-10-18 Thread Rusty Russell via bitcoin-dev
Pieter Wuille writes: > Today, no witness v1 receivers exist. So it seems to me the only question > is what software/infrastructure exist that supports sending to witness v1, > and whether they (and their userbase) are more or less likely to upgrade > before receivers appear than those that

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

2020-10-07 Thread Rusty Russell via bitcoin-dev
Hi all, I propose an alternative to length restrictions suggested by Russell in https://github.com/bitcoin/bips/pull/945: use the https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant, unless the first byte is 0. Here's a summary of each proposal: Length restrictions

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

2020-10-19 Thread Rusty Russell via bitcoin-dev
Rusty Russell writes: > Accepts > --- > Green: ef1662fd2eb736612afb1b60e3efabfdf700b1c4822733d9dbe1bfee607a5b9b > blockchain.info: > 64b0fcb22d57b3c920fee1a97b9facec5b128d9c895a49c7d321292fb4156c21 PEBKAC. Pasted wrong address. Here are correct results: Rejects --- c-lightning:

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

2020-10-19 Thread Rusty Russell via bitcoin-dev
Pieter Wuille writes: > Here is a BIP341 witness v1 address, corresponding to just the generator as > inner public key (using TapTweak(pubkey) as tweak, as suggested by the BIP): > > bc1pmfr3p9 YOU j00pfxjh WILL 0zmgp99y8zf LOSE tmd3s5pmedqhy MONEY > ptwy6lm87hf5ss52r5n8 Here are my initial

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

2020-10-21 Thread Rusty Russell via bitcoin-dev
Mike Schmidt via bitcoin-dev writes: > I am happy to re-test the services Harding listed previously for v1 send > support next week. > > Suggestions of additional services that would be valuable to test are > welcome as well. Thanks! I am a little disappointed that I won't get to ask Bitcoin

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

2020-10-21 Thread Rusty Russell via bitcoin-dev
ZmnSCPxj writes: > I believe this is actually my code, which was later refactored by John > Barboza when we were standardizing the `param` system. Ah, sorry! > This was intended only as a simple precaution against creating non-standard > transaction, and not an assumption that future versions

Re: [bitcoin-dev] New PSBT version proposal

2021-01-06 Thread Rusty Russell via bitcoin-dev
Hi Andrew et al, Very excited to see this progress; thanks for doing all the work! Sorry for the delayed feedback, I didn't get to this before the break. > Additionally, I would like to add a new global field: > * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05 >   * Key: empty >   * Value: A

Re: [bitcoin-dev] New PSBT version proposal

2021-01-07 Thread Rusty Russell via bitcoin-dev
Andrew Chow writes: > Hi Rusty, > > On 1/6/21 6:26 PM, Rusty Russell wrote: >> Hi Andrew et al, >> >> Very excited to see this progress; thanks for doing all the >> work! Sorry for the delayed feedback, I didn't get to this before the >> break. >> >>> Additionally, I would like to add a

Re: [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address

2021-01-08 Thread Rusty Russell via bitcoin-dev
Perhaps title 'Bech32m address format for native v0-16 segregated witness outputs' should probably be v1-16? This is a thorough and clear write up; a superb read. Side note: I am deeply impressed with your mathematical jujitsu that no bech32 string is also a valid bech32m string *even with three

Re: [bitcoin-dev] Response to Rusty Russell from Github

2021-04-06 Thread Rusty Russell via bitcoin-dev
Jeremy via bitcoin-dev writes: > Where I disagree is that I do not believe that BIP8 with LOT configuration > is the improved long term option we should ossify around either. I > understand the triumvirate model you desire to achieve, but BIP8 with an > individually set LOT configuration does not

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-04-06 Thread Rusty Russell via bitcoin-dev
Jeremy via bitcoin-dev writes: > We had a very productive meeting today. Here is a summary of the meeting -- > I've done my best to > summarize in an unbiased way. Thank you to everyone who attended. > > 1. On the use of a speedy trial variant: > > - There are no new objections to speedy trial

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-04-06 Thread Rusty Russell via bitcoin-dev
Ryan Grant writes: > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev > wrote: >> The core question always was: what do we do if miners fail to activate? >> >> [...] Speedy Trial takes the approach that "let's pretend we didn't >> *actually* a

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

2022-02-15 Thread Rusty Russell via bitcoin-dev
Jeremy Rubin writes: > Rusty, > > Note that this sort of design introduces recursive covenants similarly to > how I described above. > > Whether that is an issue or not precluding this sort of design or not, I > defer to others. Good point! But I think it's a distinction without meaning: AFAICT

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

2022-02-15 Thread Rusty Russell via bitcoin-dev
Jeremy Rubin writes: > Hi Rusty, > > Please see my post in the other email thread > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html > > The differences in this regard are several, and worth understanding beyond > "you can iterate CTV". I'd note a few clear

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

2022-02-07 Thread Rusty Russell via bitcoin-dev
Russell O'Connor via bitcoin-dev writes: > Given the overlap in functionality between CTV and ANYPREVOUT, I think it > makes sense to decompose their operations into their constituent pieces and > reassemble their behaviour programmatically. To this end, I'd like to > instead propose OP_TXHASH

[bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY

2022-05-10 Thread Rusty Russell via bitcoin-dev
Hi all, TL;DR: a v1 tapscript opcode for generic covenants, but OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an obvious use case, with clean future expansion. OP_NOP4 can be repurposed in future as a shortcut, if experience shows that to be a useful optimization.