Re: [bitcoin-dev] CTV BIP review

2022-01-20 Thread Anthony Towns via bitcoin-dev
On Tue, Jan 18, 2022 at 03:54:21PM -0800, Jeremy via bitcoin-dev wrote: > Some of it's kind of annoying because > the legal definition of covenant is [...] > so I do think things like CLTV/CSV are covenants I think that in the context of Bitcoin, the most useful definition of covenant is that

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-10-14 Thread Anthony Towns via bitcoin-dev
On Wed, Sep 15, 2021 at 08:24:43AM -0700, Matt Corallo via bitcoin-dev wrote: > > On Sep 13, 2021, at 21:56, Anthony Towns wrote: > > I'm not sure that's really the question you want answered? > Of course it is? I’d like to understand the initial thinking and design > analysis that went into

Re: [bitcoin-dev] Taproot testnet wallet

2021-10-14 Thread Anthony Towns via bitcoin-dev
On Sat, Oct 09, 2021 at 04:49:42PM +, Pieter Wuille via bitcoin-dev wrote: > You can construct a taproot-capable wallet in Bitcoin Core as follows: > * Have or create a descriptor wallet (createwallet RPC, with > descriptors=true). > * Import a taproot descriptor (of the form "tr(KEY)"), as

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-14 Thread Anthony Towns via bitcoin-dev
On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote: > > ... in this post I will argue against frequent soft forks with a single or > minimal > > set of features and instead argue for infrequent soft forks with batches > > of features. > I think this type of development has been

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-20 Thread Anthony Towns via bitcoin-dev
On Sat, Sep 18, 2021 at 10:11:10AM -0400, Antoine Riard wrote: > I think one design advantage of combining scope-minimal opcodes like MERKLESUB > with sighash malleability is the ability to update a subset of the off-chain > contract transactions fields after the funding phase. Note that it's not

Re: [bitcoin-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

2021-09-18 Thread Anthony Towns via bitcoin-dev
On Fri, Sep 17, 2021 at 09:58:45AM -0700, Jeremy via bitcoin-dev wrote, on behalf of John Law: > I'd like to propose an alternative to BIP-118 [1] that is both safer and more > powerful. The proposal is called Inherited IDs (IIDs) and is described in a > paper that can be found here [2]. [...]

Re: [bitcoin-dev] BIP extensions

2021-09-15 Thread Anthony Towns via bitcoin-dev
On Wed, Sep 15, 2021 at 03:14:31PM +0900, Karl-Johan Alm via bitcoin-dev wrote: > BIPs are proposals. > It is then organically incorporated into the various entities that > exist in the Bitcoin space. At this point, it is not merely a > proposal, but a standard. Thinking of BIPs that have reach

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-15 Thread Anthony Towns via bitcoin-dev
On Sun, Sep 12, 2021 at 07:37:56PM -0400, Antoine Riard via bitcoin-dev wrote: > While MERKLESUB is still WIP, here the semantic. [...] > I believe this is matching your description and the main difference compared > to > your TLUV proposal is the lack of merkle tree extension, where a new merkle

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-13 Thread Anthony Towns via bitcoin-dev
On Sun, Sep 12, 2021 at 10:33:24PM -0700, Matt Corallo via bitcoin-dev wrote: > > On Sep 12, 2021, at 00:53, Anthony Towns wrote: > >> Why bother with a version bit? This seems substantially more complicated > >> than the original proposal that surfaced many times before signet launched > >> to

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-12 Thread Anthony Towns via bitcoin-dev
On Thu, Sep 09, 2021 at 05:50:08PM -0700, Matt Corallo via bitcoin-dev wrote: > > AJ proposed to allow SigNet users to opt-out of reorgs in case they > > explicitly want to remain unaffected. This can be done by setting a > > to-be-reorged version bit [...] > Why bother with a version bit? This

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-10 Thread Anthony Towns via bitcoin-dev
On Fri, Sep 10, 2021 at 12:12:24AM -0400, Antoine Riard wrote: > "Talk is cheap. Show me the code" :p >     case OP_MERKLESUB: I'm not entirely clear on what your opcode there is trying to do. I think it's taking MERKLESUB and checking that output N has the same scripts as the current

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-10 Thread Anthony Towns via bitcoin-dev
On Thu, Sep 09, 2021 at 12:26:37PM -0700, Jeremy wrote: > I'm a bit skeptical of the safety of the control byte. Have you considered the > following issues? > If we used the script "0 F 0 TLUV" (H=F, C=0) then we keep the current > script, keep all the steps in the merkle path (AB and

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-09 Thread Anthony Towns via bitcoin-dev
On Thu, Sep 09, 2021 at 04:41:38PM +1000, Anthony Towns wrote: > I'll split this into two emails, this one's the handwavy overview, > the followup will go into some of the implementation complexities. (This is informed by discussions with Greg, Matt Corallo, David Harding and Jeremy Rubin;

[bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-09 Thread Anthony Towns via bitcoin-dev
Hello world, A couple of years ago I had a flight of fancy [0] imagining how it might be possible for everyone on the planet to use bitcoin in a mostly decentralised/untrusted way, without requiring a block size increase. It was a bit ridiculous and probably doesn't quite hold up, and beyond

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-08 Thread Anthony Towns via bitcoin-dev
On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote: > The reorg-interval X very much depends on the user's needs. One could > argue that there should be, for example, three reorgs per day, each 48 > blocks apart. Oh, wow, I think the last suggestion was every 100 blocks (every

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-12 Thread Anthony Towns via bitcoin-dev
On Tue, Aug 10, 2021 at 06:37:48PM -0400, Antoine Riard via bitcoin-dev wrote: > Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of > the HTLC. Right: but that just means it's not something you should determine once for the HTLC, but something you should determine each

Re: [bitcoin-dev] [Lightning-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-13 Thread Anthony Towns via bitcoin-dev
On Mon, Jul 12, 2021 at 03:07:29PM -0700, Jeremy wrote: > Perhaps there's a more general principle -- evaluating a script should > only return one bit of info: "bool tx_is_invalid_script_failed"; every > other bit of information -- how much is paid in fees (cf ethereum gas >

Re: [bitcoin-dev] [Lightning-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-11 Thread Anthony Towns via bitcoin-dev
On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote: > This would disallow using a relative locktime and an absolute locktime > for the same input. I don't think I've seen a use case for that so far, > but ruling it out seems suboptimal. > I think you meant disallowing a relative

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-07-09 Thread Anthony Towns via bitcoin-dev
On Fri, Jul 09, 2021 at 09:19:45AM -0400, Antoine Riard via bitcoin-dev wrote: > > The easy way to avoid O(n^2) behaviour in (3) is to disallow partial > > overlaps. So let's treat the tx as being distinct bundles of x-inputs > > and y-outputs, and we'll use the annex for grouping, since that is >

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-07-08 Thread Anthony Towns via bitcoin-dev
On Thu, May 27, 2021 at 04:14:13PM -0400, Antoine Riard via bitcoin-dev wrote: > This overhead could be smoothed even further in the future with more advanced > sighash malleability flags like SIGHASH_IOMAP, allowing transaction signers to > commit to a map of inputs/outputs [2]. In the context of

Re: [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-08 Thread Anthony Towns via bitcoin-dev
On Wed, Jul 07, 2021 at 06:00:20PM -0700, Jeremy via bitcoin-dev wrote: > This means that you're overloading the CLTV clause, which means it's > impossible > to use Eltoo and use a absolute lock time, It's already impossible to simultaneously spend two inputs if one requires a locktime specified

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread Anthony Towns via bitcoin-dev
On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via bitcoin-dev wrote: > Bear in mind that when people are talking about enabling covenants, we are > talking about whether OP_CAT should be allowed or not. In some sense multisig *alone* enables recursive covenants: a government that

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

2021-04-17 Thread Anthony Towns via bitcoin-dev
On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev wrote: > The transition *could* look like this: > - validating nodes begin to require proof-of-burn, in addition to > proof-of-work (soft fork) > - the extra expense makes it more expensive for miners, so POW slowly drops >

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

2021-04-08 Thread Anthony Towns via bitcoin-dev
On Wed, Apr 07, 2021 at 02:31:13PM +0930, Rusty Russell via bitcoin-dev wrote: > >> It's totally a political approach, to avoid facing the awkward question. > >> Since I believe that such prevaricating makes a future crisis less > >> predictable, I am forced to conclude that it makes bitcoin less

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Anthony Towns via bitcoin-dev
On Tue, Apr 06, 2021 at 01:17:58PM -0400, Russell O'Connor via bitcoin-dev wrote: > Not only that, but the "time_until_next_retargeting_period" is a variable > whose > distribution could straddle between 0 days and 14 days should the > MIN_LOCKIN_TIME end up close to a retargeting boundary. As

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-05 Thread Anthony Towns via bitcoin-dev
On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote: > As such, the main conversation in this agenda item is > around the pros/cons of height or MTP and determining if we can reach > consensus > on either approach. Here's some numbers. Given a desired signalling period of xxx

Re: [bitcoin-dev] Making the case for flag day activation of taproot

2021-03-29 Thread Anthony Towns via bitcoin-dev
On Wed, Mar 03, 2021 at 02:08:21PM -0500, Russell O'Connor via bitcoin-dev wrote: > While I support essentially any proposed taproot activation method, including > a > flag day activation, I think it is premature to call BIP8 dead. > > Even today, I still think that starting with BIP8 LOT=false

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

2021-03-25 Thread Anthony Towns via bitcoin-dev
On Tue, Mar 23, 2021 at 08:46:54PM -0700, Jeremy via bitcoin-dev wrote: > 3. Parameter Selection > - There is broad agreement that we should target something like a May 1st > release, with 1 week from rc1 starttime/startheight, > and 3 months + delta stoptime/stopheight (6 retargetting

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-03-15 Thread Anthony Towns via bitcoin-dev
On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev wrote: > It may initially take months to break a single key. >From what I understand, the constraint on using quantum techniques to break an ECC key is on the number of bits you can entangle and how long you can keep them

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

2021-03-06 Thread Anthony Towns via bitcoin-dev
On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote: > On 3/3/21 09:59, Anthony Towns wrote: > > A couple of days ago I would have disagreed with this; but with Luke > > now strongly pushing against implementing lot=false, I can at least see > > your point... > Right. It may be the case

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

2021-03-06 Thread Anthony Towns via bitcoin-dev
On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev wrote: > ## Example timeline > - T+0: release of one or more full nodes with activation code > - T+14: signal tracking begins > - T+28: earliest possible lock in > - T+104: locked in by this date or need to try a different

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

2021-03-03 Thread Anthony Towns via bitcoin-dev
On Sun, Feb 28, 2021 at 11:45:22AM -0500, Matt Corallo via bitcoin-dev wrote: > Given this, it seems one way to keep the network in consensus would be to > simply activate taproot through a traditional, no-frills, flag-day (or > -height) activation with a flag day of roughly August, 2022. Going

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

2021-03-02 Thread Anthony Towns via bitcoin-dev
On Mon, Mar 01, 2021 at 08:58:46PM +, John Newbery via bitcoin-dev wrote: > We can increase the permitted number of inbound block-relay-only peers > while minimizing resource requirement _and_ improving addr record > propagation, without any changes to the p2p protocol required. +1. I found

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

2021-03-01 Thread Anthony Towns via bitcoin-dev
On Sun, Feb 28, 2021 at 07:33:30PM +, Luke Dashjr via bitcoin-dev wrote: > As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, > despite its potential benefits, also leaves open the door to a miner veto. To the contrary, we saw in 2017 that miners could *not*

Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold

2021-03-01 Thread Anthony Towns via bitcoin-dev
On Sat, Feb 27, 2021 at 05:55:00PM +, Luke Dashjr via bitcoin-dev wrote: [on the topic of non-signalled activation; ie "it doesn't matter what miners do or signal, the rules are active as of height X"] > This has the same problems BIP149 did: since there is no signalling, it is > ambiguous

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-23 Thread Anthony Towns via bitcoin-dev
On Mon, Feb 22, 2021 at 06:10:34PM -0800, Jeremy via bitcoin-dev wrote: > Not responding to anyone in particular, but it strikes me that one can think > about the case where a small minority (let's say H = 20%?) of nodes I don't think that's a good way to try to look at things -- number of nodes

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-22 Thread Anthony Towns via bitcoin-dev
On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote: > I think it should be clear that a UASF-style command line option to allow > consensus rule changes in the node in the short term, immediately before a > fork > carries some risk of a fork, even if I agree it may not persist over

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-22 Thread Anthony Towns via bitcoin-dev
On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote: > A node feeding you invalid headers (used to be) cause for a ban [...] Headers that are invalid due to MUST_SIGNAL rules are marked as BLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're doing headers-first

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-21 Thread Anthony Towns via bitcoin-dev
On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote: > It was pointed out to me that this discussion is largely moot as the > software complexity for Bitcoin Core to ship an option like this is likely > not practical/what people would wish to see. > Bitcoin Core does not

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

2021-01-13 Thread Anthony Towns via bitcoin-dev
On Wed, Jan 06, 2021 at 11:35:11AM -0500, Suhas Daftuar via bitcoin-dev wrote: > I'm proposing the addition of a new, optional p2p message to allow peers to > communicate that they do not want to send or receive (loose) transactions for > the lifetime of a connection.  > > The goal of this

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

2021-01-13 Thread Anthony Towns via bitcoin-dev
On Wed, Jan 13, 2021 at 01:40:03AM -0500, Matt Corallo via bitcoin-dev wrote: > Out of curiosity, was the interaction between fRelay and bloom disabling ever > specified? ie if you aren’t allowed to enable bloom filters on a connection > due > to resource constraints/new limits, is it ever

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

2020-08-20 Thread Anthony Towns via bitcoin-dev
On Fri, Aug 14, 2020 at 03:28:41PM -0400, Suhas Daftuar via bitcoin-dev wrote: > In thinking about the mechanism used there, I thought it would be helpful to > codify in a BIP the idea that Bitcoin network clients should ignore unknown > messages received before a VERACK.  A draft of my proposal

Re: [bitcoin-dev] reviving op_difficulty

2020-08-16 Thread Anthony Towns via bitcoin-dev
On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote: > My understanding is that adding a single op_difficulty operation as > proposed would enable not true difficulty futures but binary options > on difficulty. An alternative approach for this might be to use taproot's

[bitcoin-dev] Thoughts on soft-fork activation

2020-07-14 Thread Anthony Towns via bitcoin-dev
Hi, I've been trying to figure out a good way to activate soft forks in future. I'd like to post some thoughts on that. So: I think there's two proposals that are roughly plausible. The first is Luke's recent update to BIP 8: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki

Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

2020-07-09 Thread Anthony Towns via bitcoin-dev
On Fri, Jul 10, 2020 at 07:40:48AM +1000, Anthony Towns via bitcoin-dev wrote: > After talking with Christina Christian. Dr Christian Decker, PhD. Dr Bitcoin. cdecker. Snyke. Cheers, aj, hoping he typed one of those right, at least... ___ bitcoin-

[bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

2020-07-09 Thread Anthony Towns via bitcoin-dev
Hello world, After talking with Christina ages ago, we came to the conclusion that it made more sense to update BIP 118 to the latest thinking than have a new BIP number, so I've (finally) opened a (draft) PR to update BIP 118 with the ANYPREVOUT bip I've passed around to a few people,

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

2020-05-02 Thread Anthony Towns via bitcoin-dev
On Fri, May 01, 2020 at 08:23:07AM -0400, Russell O'Connor wrote: > Regarding specifics, I personally think it would be better to keep the > hashes of the ScriptPubKeys separate from the hashes of the input values. I think Andrew's original suggestion achieves this: >> The obvious way to

Re: [bitcoin-dev] Taproot (and graftroot) complexity

2020-02-09 Thread Anthony Towns via bitcoin-dev
On Sun, Feb 09, 2020 at 02:19:55PM -0600, Bryan Bishop via bitcoin-dev wrote: > However, after > our review, we're left perplexed about the development of Taproot (and > Graftroot, to a lesser extent). I think the main cause of the perplexity is not seeing the benefit of taproot. For me, the

Re: [bitcoin-dev] Modern Soft Fork Activation

2020-01-15 Thread Anthony Towns via bitcoin-dev
On Tue, Jan 14, 2020 at 07:42:07PM +, Matt Corallo wrote: > Thus, part of the goal here is that we ensure we have that "out", and > can observe the response of the ecosystem once the change is "staring > them in the face", as it were. > A BIP 9 process is here not only to offer > a compelling

Re: [bitcoin-dev] Modern Soft Fork Activation

2020-01-13 Thread Anthony Towns via bitcoin-dev
On Mon, Jan 13, 2020 at 08:34:24AM +, Yosef via bitcoin-dev wrote: > tl;dr How about 80% ? The point of having hashpower upgraded is that it means that there's low liklihood of long chains of blocks that are invalid per the new rules, so that if you haven't upgraded your node but wait for a

Re: [bitcoin-dev] Modern Soft Fork Activation

2020-01-11 Thread Anthony Towns via bitcoin-dev
On Fri, Jan 10, 2020 at 09:30:09PM +, Matt Corallo via bitcoin-dev wrote: > 1) a standard BIP 9 deployment with a one-year time horizon for > activation with 95% miner readiness, > 2) in the case that no activation occurs within a year, a six month > quieting period during which the community

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

2019-12-05 Thread Anthony Towns via bitcoin-dev
On Thu, Dec 05, 2019 at 03:24:46PM -0500, Russell O'Connor wrote: Thanks for the careful write up! That matches what I was thinking. > This analysis suggests that we should amend CODESEPARATORs behaviour to update > an accumulator (presumably a running hash value), so that all executed >

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

2019-12-03 Thread Anthony Towns via bitcoin-dev
On Sun, Dec 01, 2019 at 11:09:54AM -0500, Russell O'Connor wrote: > On Thu, Nov 28, 2019 at 3:07 AM Anthony Towns wrote: > First, it seems like a bad idea for Alice to have put funds behind a > script she doesn't understand in the first place. There's plenty of > scripts that are

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

2019-11-28 Thread Anthony Towns via bitcoin-dev
On Wed, Nov 27, 2019 at 04:29:32PM -0500, Russell O'Connor via bitcoin-dev wrote: > The current tapscript proposal requires a signature on the last executed > CODESEPRATOR position.  I'd like to propose an amendment whereby instead of > signing the last executed CODESEPRATOR position, we simply

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-05 Thread Anthony Towns via bitcoin-dev
On Thu, Oct 03, 2019 at 01:08:29PM +0200, Christian Decker wrote: > > * anyprevout signatures make the address you're signing for less safe, > >which may cause you to lose funds when additional coins are sent to > >the same address; this can be avoided if handled with care (or if you > >

Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout

2019-10-02 Thread Anthony Towns via bitcoin-dev
On Wed, Oct 02, 2019 at 02:03:43AM +, ZmnSCPxj via Lightning-dev wrote: > So let me propose the more radical excision, starting with SegWit v1: > * Remove `SIGHASH` from signatures. > * Put `SIGHASH` on public keys. > OP_SETPUBKEYSIGHASH I don't think you could reasonably do this for

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread Anthony Towns via bitcoin-dev
On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev wrote: > With the recently renewed interest in eltoo, a proof-of-concept implementation > [1], and the discussions regarding clean abstractions for off-chain protocols > [2,3], I thought it might be time to revisit the

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread Anthony Towns via bitcoin-dev
On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote: > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > `OP_CHECKSIG_WITHOUT_INPUT`. I don't think there's any meaningful difference between making a new opcode and making a new tapscript public key type; the

Re: [bitcoin-dev] Taproot proposal

2019-06-28 Thread Anthony Towns via bitcoin-dev
On Wed, Jun 26, 2019 at 08:08:01PM -0400, Russell O'Connor via bitcoin-dev wrote: > I have a comment about the 'input_index' of the transaction digest for taproot > signatures.  It is currently listed as 2 bytes.  I think it would be better to > expand that to 4 bytes. FWIW, I think this would

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

2019-06-21 Thread Anthony Towns via bitcoin-dev
On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: > So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason to > complicate the spec to ensure the digest is precommitted as part of the > opcode." Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT

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

2019-06-05 Thread Anthony Towns via bitcoin-dev
On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote: > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. I think you could generalise that slightly and make it fit in with the existing opcode naming by calling it something like "OP_CHECKTXDIGESTVERIFY" and

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

2019-05-27 Thread Anthony Towns via bitcoin-dev
On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev wrote: > Bitcoin Script appears designed to be a flexible programmable system that > provides generic features to be composed to achieve various purposes. Counterpoint: haven't the flexibly designed parts of script mostly

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

2019-05-23 Thread Anthony Towns via bitcoin-dev
On Wed, May 22, 2019 at 06:04:27AM +, ZmnSCPxj via bitcoin-dev wrote: > * I do not think CoinJoin is much improved by this opcode. I think (especially with cross-input sig aggregation) it makes it easier to do a coinjoin during a high fee period -- if you're willing to wait 'til fees are

Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal

2019-05-23 Thread Anthony Towns via bitcoin-dev
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 is a new power in bitcoin, and

[bitcoin-dev] SIGHASH_ANYPREVOUT proposal

2019-05-11 Thread Anthony Towns via bitcoin-dev
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 don't think we are (or should be) as confident that ANYPREVOUT is ready for implementation and deployment as we are

Re: [bitcoin-dev] Taproot proposal

2019-05-09 Thread Anthony Towns via bitcoin-dev
On Mon, May 06, 2019 at 08:17:09PM +, Luke Dashjr via bitcoin-dev wrote: > Some way to sign an additional script (not committed to by the witness > program) seems like it could be a trivial addition. Aside: if you want to commit to something extra *with* the witness program, you could use

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

2019-03-22 Thread Anthony Towns via bitcoin-dev
On Fri, Mar 22, 2019 at 01:59:14AM +, ZmnSCPxj wrote: > > If codeseparator is too scary, you could probably also just always > > require the locktime (ie for settlmenet txs as well as update txs), ie: > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > OP_CHECKDLSVERIFY OP_CHECKDLS > > and have update

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

2019-03-21 Thread Anthony Towns via bitcoin-dev
On Thu, Mar 21, 2019 at 10:05:09AM +, ZmnSCPxj wrote: > > IF OP_CODESEPARATOR OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF > > OP_CHECKDLSVERIFY OP_CHECKDLS > > Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV > > and allows binding to any prior update tx -- so works for an update

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

2019-03-21 Thread Anthony Towns via bitcoin-dev
On Wed, Mar 20, 2019 at 08:07:00AM +, ZmnSCPxj via Lightning-dev wrote: > Re-reading again, I think perhaps I was massively confused by this: > > that commits to the input. In that case, you could do eltoo with a > > script like either: > > CHECKSIGVERIFY CHECKSIG > > or CHECKSIGVERIFY

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

2019-03-14 Thread Anthony Towns via bitcoin-dev
On Thu, Mar 14, 2019 at 05:22:59AM +, ZmnSCPxj via Lightning-dev wrote: > When reading through your original post I saw you mentioned something about > output tagging somehow conflicting with Taproot, so I assumed Taproot is not > useable in this case. I'm thinking of tagged outputs as

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

2019-03-13 Thread Anthony Towns via bitcoin-dev
On Wed, Mar 13, 2019 at 06:41:47AM +, ZmnSCPxj via Lightning-dev wrote: > > - alternatively, we could require every script to have a valid signature > > that commits to the input. In that case, you could do eltoo with a > > script like either: > > CHECKSIGVERIFY CHECKSIG > >

Re: [bitcoin-dev] Signet

2019-03-13 Thread Anthony Towns via bitcoin-dev
On Fri, Mar 08, 2019 at 03:20:49PM -0500, Matt Corallo via bitcoin-dev wrote: > To make testing easier, it may make sense to keep the existing block header > format (and PoW) and instead apply the signature rules to some field in the > coinbase transaction. Maybe make the signature be an optional

[bitcoin-dev] More thoughts on NOINPUT safety

2019-03-13 Thread Anthony Towns via bitcoin-dev
Hi all, The following has some more thoughts on trying to make a NOINPUT implementation as safe as possible for the Bitcoin ecosystem. One interesting property of NOINPUT usage like in eltoo is that it actually reintroduces the possibility of third-party malleability to transactions -- ie, you

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

2019-02-12 Thread Anthony Towns via bitcoin-dev
On Sun, Feb 10, 2019 at 12:48:40AM +0800, Johnson Lau wrote: > In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC > respectively, there are few ways they could make the settlement tx. The way I look at this is: * you can have a "channel factory" of 3 or more members

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

2019-01-31 Thread Anthony Towns via bitcoin-dev
On Mon, Dec 24, 2018 at 11:47:38AM +, ZmnSCPxj via bitcoin-dev wrote: > A boutique protocol would reduce the number of existing onchain wallets that > could be integrated in such UI. Seems like PSBT would be a sufficient protocol: 0) lightning node generates a PSBT for a new channel,

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

2018-12-23 Thread Anthony Towns via bitcoin-dev
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), and conditional opcodes are mostly replaced by merklized >

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

2018-12-19 Thread Anthony Towns via bitcoin-dev
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 existing script template. But they might > also lose

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

2018-12-18 Thread Anthony Towns via bitcoin-dev
Hi *, (All the following is heavily informed by talking with other smart people, and while probably all the clever ideas are theirs, any nonsense and mistakes are certainly my own. I guess I'll pretend there were Chatham House rules or something to avoid any blame/responsibility accidently

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

2018-12-18 Thread Anthony Towns via bitcoin-dev
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 what scripts we can sign, but is it? If it's not safer in practice,

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

2018-12-18 Thread Anthony Towns via bitcoin-dev
On Thu, Dec 13, 2018 at 11:21:10AM -0500, Russell O'Connor wrote: > On Wed, Dec 12, 2018 at 7:06 PM Anthony Towns wrote: > On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau wrote: > >     The current

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

2018-12-17 Thread Anthony Towns via bitcoin-dev
On Wed, Dec 12, 2018 at 08:12:10PM +1030, 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, > > and SIGHASH_SCRIPTMASK. > > * A new opcode OP_MASK is added, which

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

2018-12-17 Thread Anthony Towns via bitcoin-dev
On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev wrote: > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau wrote: > The current proposal is that a 64-byte signature will be used for the > default “signing all” sighash, and 65-byte for other sighash types. The >

Re: [bitcoin-dev] Multi party Schnorr Rust implementation

2018-11-28 Thread Anthony Towns via bitcoin-dev
On Tue, Nov 27, 2018 at 10:33:30PM -0800, Devrandom via bitcoin-dev wrote: > Are there any candidates for non-interactive threshold signatures?  > Interactive > signatures are not very suitable for air-gapped use cases. I think you can work around this to some extent by "batching" signing

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

2018-11-24 Thread Anthony Towns via bitcoin-dev
On Wed, Nov 21, 2018 at 12:15:44PM +0100, Christian Decker via bitcoin-dev wrote: > One minor thing that I noticed a while ago and that I meant > to fix on BIP118 is that `hashSequence` does not need to be blanked for > eltoo to work (since where it is needed we also use `sighash_single`), > so

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

2018-11-23 Thread Anthony Towns via bitcoin-dev
On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev wrote: > Given that we want to move away from OP_CODESEPARATOR, because each call to > this operation effectively takes O(script-size) time, we need a replacement > for > the functionality it currently provides.  While

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

2018-11-20 Thread Anthony Towns via bitcoin-dev
On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote: > 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

Re: [bitcoin-dev] Schnorr signatures BIP

2018-08-06 Thread Anthony Towns via bitcoin-dev
On Sun, Aug 05, 2018 at 10:33:52AM -0400, Russell O'Connor via bitcoin-dev wrote: > In light of this, I revise my proposed change to make the verification > equation > > R + sG + eP = 0. Isn't the verification equation "R + s(-G) + eP = 0" equally good, then, since -G is a constant? (ie, at

[bitcoin-dev] Generalised taproot

2018-07-12 Thread Anthony Towns via bitcoin-dev
On Fri, Jan 26, 2018 at 09:34:39PM +, Gregory Maxwell via bitcoin-dev wrote: > I ask because recursive taproot by itself isn't very interesting, > since (other than accountability) there is no gain to not just merging > the alternative, but if there are additional conditions then it can be >

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

2018-06-27 Thread Anthony Towns via bitcoin-dev
On Thu, May 31, 2018 at 05:25:04PM -0700, Pieter Wuille via bitcoin-dev wrote: > The best argument for why Graftroot does not need to be optional I > think was how Greg put it: "since the signer(s) could have signed an > arbitrary transaction instead, being able to delegate is strictly less >

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

2018-05-14 Thread Anthony Towns via bitcoin-dev
On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote: > > The big concern I have with _NOINPUT is that it has a huge failure > > case: if you use the same key for multiple inputs and sign one of them > > with _NOINPUT, you've spent all of them. The current proposal kind-of > > limits the

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

2018-05-10 Thread Anthony Towns via bitcoin-dev
Hello world, After the core dev meetup in March I wrote up some notes of where I think things stand for signing stuff post-Schnorr. It was mostly for my own benefit but maybe it's helpful for others too, so... They're just notes, so may assume a fair bit of background to be able to understand

Re: [bitcoin-dev] BIP sighash_noinput

2018-05-08 Thread Anthony Towns via bitcoin-dev
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 if I'm actually criticising or playing devil's advocate here, but either way I think

Re: [bitcoin-dev] Signature bundles

2018-04-02 Thread Anthony Towns via bitcoin-dev
On Tue, Apr 03, 2018 at 09:16:45AM +0930, Rusty Russell via bitcoin-dev wrote: > Proposal: Two bits: SIGHASH_BUNDLESTART/SIGHASH_INBUNDLE > > > A signature needs to indicate that signs only part of a transaction's > inputs and outputs (a.k.a. a "bundle"). Bundles can be combined >

Re: [bitcoin-dev] Optimized Header Sync

2018-03-30 Thread Anthony Towns via bitcoin-dev
On Thu, Mar 29, 2018 at 05:50:30PM -0700, Jim Posen via bitcoin-dev wrote: > Taken a step further though, I'm really interested in treating the checkpoints > as commitments to chain work [...] In that case, shouldn't the checkpoints just be every 2016 blocks and include the corresponding bits

Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

2018-03-27 Thread Anthony Towns via bitcoin-dev
On Wed, Mar 21, 2018 at 05:47:01PM -0700, Bram Cohen via bitcoin-dev wrote: > [...] Most unused opcodes should be reclaimed as RETURN_VALID, > but there should still be one OP_NOP and there should be a 'real' > RETURN_VALID, > which (a) is guaranteed to not be soft forked into something else in

Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

2018-03-21 Thread Anthony Towns via bitcoin-dev
On Wed, Mar 21, 2018 at 03:53:59AM -0400, ZmnSCPxj wrote: > Good morning aj, Good evening Zeeman! [pulled from the bottom of your mail] > This way, rather than gathering signatures, we gather public keys for > aggregate signature checking. Sorry, I probably didn't explain it well (or at

[bitcoin-dev] Soft-forks and schnorr signature aggregation

2018-03-20 Thread Anthony Towns via bitcoin-dev
Hello world, There was a lot of discussion on Schnorr sigs and key and signature aggregation at the recent core-dev-tech meeting (one relevant conversation is transcribed at [0]). Quick summary, with more background detail in the corresponding footnotes: signature aggregation is awesome [1], and

Re: [bitcoin-dev] {sign|verify}message replacement

2018-03-14 Thread Anthony Towns via bitcoin-dev
On 14 March 2018 5:46:55 AM GMT-04:00, Kalle Rosenbaum via bitcoin-dev wrote: >Thank you. > >I can't really see from your proposal if you had thought of this: A >soft >fork can make old nodes accept invalid message signatures as valid. For >example, a

Re: [bitcoin-dev] Simple lock/unlock mechanism

2018-02-28 Thread Anthony Towns via bitcoin-dev
On Wed, Feb 28, 2018 at 04:34:18AM +, アルム カールヨハン via bitcoin-dev wrote: > 1. Graftroot probably breaks this (someone could just sign the > time-locked output with a script that has no time-lock). Making the graftroot key be a 2-of-2 muSig with an independent third party that commits to only

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

2018-01-23 Thread Anthony Towns via bitcoin-dev
On Tue, Jan 23, 2018 at 01:15:38PM +, Gregory Maxwell wrote: > On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns wrote: > > Is this really intended as paying directly to a pubkey, instead of a > > pubkey hash? > > If so, isn't that a step backwards with regard to resistance

  1   2   >