Re: [bitcoin-dev] Bitcoin XT 0.11A

On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Sorry you feel that way. I devoted a big part of the article to trying to fairly represent the top 3 arguments made, but ultimately I can't link to a clear statement of what Bitcoin Core thinks

Re: [bitcoin-dev] Block size following technological growth

On Thu, Jul 30, 2015 at 12:20:30PM -0400, Gavin Andresen wrote: On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more accurate sigop checking after the

Re: [bitcoin-dev] Eli Dourado on governance

On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: And the preliminary results of using a prediction market to try to wrestle with the tough tradeoffs looks roughly correct to me, too: https://blocksizedebate.com/ ​The scicast

Re: [bitcoin-dev] Fees and the block-finding process

On 8 August 2015 at 00:57, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I answered: 1. If you are willing to wait an infinite amount of time, I think the minimum fee will always be zero or very close to zero, so I think it's a silly question. That's not

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

On 14 August 2015 at 16:48, Jakob Rönnbäck bitcoin-dev@lists.linuxfoundation.org wrote: 14 aug 2015 kl. 16:20 skrev Anthony Towns a...@erisian.com.au: On 14 August 2015 at 11:59, Jakob Rönnbäck bitcoin-dev@lists.linuxfoundation.org wrote: What if one were to adjust the difficulty (for

Re: [bitcoin-dev] Off-chain transactions and miner fees

On Mon, Aug 10, 2015 at 08:14:08PM +0100, Hector Chu wrote: On 10 August 2015 at 19:50, Anthony Towns via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: ...but I think at present the time value of bitcoin is effectively zero Since bitcoin is liquid you forget that one can just sell

Re: [bitcoin-dev] What Lightning Is

On Tue, Aug 11, 2015 at 05:02:40AM +0800, Anthony Towns wrote: On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote: I'd love to see somebody write up a higher-level description of what the user experience is like, what communication happens underneath, and what

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

On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev wrote: > First I think your unsaid assumption about the fragility of a soft > fork showing incorrect confirmations is dependent on the percentage > of hash power that didn't upgrade.  If using your same numbers this > was only 5%

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

On Tue, Sep 29, 2015 at 06:31:28PM +, Gregory Maxwell via bitcoin-dev wrote: > On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev > wrote: > > There is no consensus on using a soft fork to deploy this feature. It will > > result in the same

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

On Wed, Oct 07, 2015 at 08:46:08AM -0700, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote: > On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > *But* a soft fork that only forbids transactions that would previously

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

On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > So we need to make the case for two main things: > 1) We have applications that need a relative (instead of absolute CLTV) > 2) Additionally to RCLTV, we need to implement this via nSequence > However I don't think

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Tue, Dec 08, 2015 at 05:21:18AM +, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Dec 8, 2015 at 4:58 AM, Anthony Towns via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Having a cost function rather than separate limits does make it easier t

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 09, 2015 at 01:31:51AM +, Gregory Maxwell via bitcoin-dev wrote: > On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen > wrote: > > Create a 1-megabyte transaction, with all of it's inputs spending > > segwitness-spending SIGHASH_ALL inputs. > > Because the

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 10:36:09PM +0100, Pieter Wuille via bitcoin-dev wrote: > On Wed, Dec 16, 2015 at 10:27 PM, Jeff Garzik wrote: > >> Not correct. I propose defining the virtual_block_size as base_size + > >> witness_size * 0.25, and limiting virtual_block_size to 1M. This

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote: > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote: > > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already > > equivalent to the 2-4-8 "compromise" proposal [...] > isn't SegWit gain ~75%? hence 2mb x

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 21, 2015 at 05:21:55AM +, Btc Drak via bitcoin-dev wrote: > On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev < > > So I'd like to ask the community that we work towards this plan, as it > > allows to make progress without being forced to make a possibly divisive > >

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Thu, Dec 17, 2015 at 12:32:11AM -0500, jl2012 via bitcoin-dev wrote: > There are at least 2 proposals on the table: > 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately >equals to 2MB actual limit > 2. BIP102: 2MB actual limit I think there's a few variants of (2) --

Re: [bitcoin-dev] [BIP] OP_CHECKPRIVPUBPAIR

On Fri, Nov 27, 2015 at 09:02:37AM +0100, Mats Jerratsch via bitcoin-dev wrote: > OP_CHECKPRIVPUBPAIR > As there are requests for all sort of general crypto operations in > script, we can also introduce a new general OP_CRYPTO and prepend one > byte for the operation, so > 0x01 OP_CRYPTO =

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

On Fri, Jan 08, 2016 at 07:38:50AM -0500, Gavin Andresen via bitcoin-dev wrote: > Lets see if I've followed the specifics of the collision attack correctly, > Ethan (or somebody) please let me know if I'm missing something: > > So attacker is in the middle of establishing a payment channel with >

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2MB to 2.5MB/3MB. (To the best of my knowledge, anyway; if I've made a mistake in my maths or assumptions, corrections appreciated) On Tue, Dec 08, 2015 at 02:58:03PM +1000, Anthony Towns via bitcoin-dev wrote: > So from IRC, this doesn't seem quite right -- capacity is constrai

[bitcoin-dev] Making a 2MB blocksize hardfork safer

Hello world, The core roadmap calls for having patches at the ready for implementing hardforking blocksize increases [0]. However, at least to my understanding, is that the deployment of segregated witness has a significant impact on what a hardforking blocksize increase should look like -- with

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

On Mon, Feb 08, 2016 at 07:26:48PM +, Matt Corallo via bitcoin-dev wrote: > As what a hard fork should look like in the context of segwit has never > (!) been discussed in any serious sense, I'd like to kick off such a > discussion with a (somewhat) specific proposal. > Here is a proposed

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

On Tue, Feb 09, 2016 at 10:00:44PM +, Matt Corallo wrote: > Indeed, we could push for more place by just always having one 0-byte, > but I'm not sure the added complexity helps anything? ASICs can never be > designed which use more extra-nonce-space than what they can reasonably > assume will

Re: [bitcoin-dev] Hardfork bit BIP

On Sun, Feb 07, 2016 at 03:20:27PM -0500, Gavin via bitcoin-dev wrote: > > On Feb 7, 2016, at 2:27 PM, wrote: > > Normal version number only suggests softforks, which is usually not a > > concern for SPV clients. > Soft forks affect the security of low-confirmation

Re: [bitcoin-dev] Segwit Upgrade Procedures & Block Extension Data

On Thu, Jan 28, 2016 at 01:51:24PM -0500, Peter Todd via bitcoin-dev wrote: > While Pieter Wuille's segwit branch(1) doesn't yet implement a fix for > the above problem, the obvious thing to do is to add a new service bit > such as NODE_SEGWIT, and/or bump the protocol version, and for outgoing >

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell via bitcoin-dev wrote: > On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev > wrote: > > I'm interested in input and in the level of receptiveness to this. If > > there is interest, I'll

Re: [bitcoin-dev] how to disable segwit in my build?

On Tue, Jul 11, 2017 at 11:17:24PM -0700, Dan Libby via bitcoin-dev wrote: > At this time, I would like to have some of the more recent features, but > without the possibility that my node will activate segwit, until I > choose to. I think that terminology isn't quite precise. I think your

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Mon, Jul 10, 2017 at 12:50:21PM -0400, Paul Sztorc via bitcoin-dev wrote: > We should revise [the roadmap]: remove what has been accomplished, > introduce new innovations and approaches, and update deadlines > and projections. Timelines have good and bad points (in this context, I'd

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

On Sat, May 13, 2017 at 01:11:27PM -0400, Russell O'Connor via bitcoin-dev wrote: > 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] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

On Fri, May 26, 2017 at 11:02:27AM +0300, Cameron Garnham via bitcoin-dev wrote: > If one assumes that the 67% of the hash rate that refuse to signal > for SegWit are using ASICBOOST. The entire picture of this political > stalemate became much more understandable. A couple of bits of math that

Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

On Sat, May 27, 2017 at 01:07:58PM -0700, Eric Voskuil via bitcoin-dev wrote: > Anthony, > For the sake of argument: (That seems like the cue to move any further responses to bitcoin-discuss) > (1) What would the situation look like if there was no patent? If there were no patent, and it were

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

On Tue, Jun 06, 2017 at 03:39:28PM -0700, Tao Effect via bitcoin-dev wrote: > - Mixing with 148 coinbase txns destroys fungibility. CoinJoin works as a method of both improving fungibility and mixing with coinbase transactions. You probably don't need to do anything clever to split a coin

[bitcoin-dev] Replay protection via CHECKSIG

Hi, I thought of a possibly interesting way to prevent transaction replay in the event of a chain split, that seems better to the other approaches I've seen. Basically, update OP_CHECKSIG (and MULTISIG and the VERIFY variants, presumably via segwit versioning or using a NOP opcode) so that

Re: [bitcoin-dev] Responsible disclosure of bugs

On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote: > I don't think I know the right answer here, but I will point out two things > that make this a little more complicated. > 1 - There are lots of altcoin developers and while I'm sure the majority would > greatly appreciate the

Re: [bitcoin-dev] Responsible disclosure of bugs

On Mon, Sep 11, 2017 at 10:43:52AM -0700, Daniel Stadulis wrote: > I think it's relevant to treat different bug severity levels with different > response plans.  That makes sense. For comparison, Monero defines a response process that has three levels and varies the response for each: ] a.

Re: [bitcoin-dev] Responsible disclosure of bugs

On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote: > It would be a good starting point if the current policy could be > clarified, so everyone is on the same page, and there is no confusion. Collecting various commentary from here and reddit, I think current de facto policy is something

Re: [bitcoin-dev] Responsible disclosure of bugs

On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev wrote: > I believe there continues to be concern over a number of altcoins which > are running old, unpatched forks of Bitcoin Core, making it rather > difficult to disclose issues without putting people at risk (see, eg, >

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote: > Unlike other proposed fixes to the fee model, this is not trivially > broken by paying the miner out of band. I think CPFP allows this to break: a miner getting paid out of band would just make the block look

[bitcoin-dev] "Changes without unanimous consent" talk at Scaling Bitcoin

Hi, Paper (and slides) for my talk in the Consensus stream of Scaling Bitcoin this morning are at: https://github.com/ajtowns/sc-btc-2017/releases Some analysis for split-related consensus changes, and (code-less) proposals for generic replay protection (a la BIP 115) and providing a better

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

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

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

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] Should Graftroot be optional?

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] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 12:30:06AM +, Gregory Maxwell via bitcoin-dev wrote: > One point that comes up while talking about merkelized scripts is can > we go about making fancier contract use cases as indistinguishable as > possible from the most common and boring payments. > Now we tweak C to

Re: [bitcoin-dev] Schnorr signatures BIP

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

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] Taproot: Privacy preserving switchable scripting

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

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

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] Soft-forks and schnorr signature aggregation

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

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

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

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

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

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

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

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

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

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

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

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

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] Multi party Schnorr Rust implementation

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

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

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] Schnorr and taproot (etc) upgrade

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

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

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

[bitcoin-dev] More thoughts on NOINPUT safety

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] [Lightning-dev] More thoughts on NOINPUT safety

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

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

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

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

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

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] Safer NOINPUT with output tagging

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

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] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

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] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

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] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

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

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

[bitcoin-dev] SIGHASH_ANYPREVOUT proposal

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] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

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

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

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

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] Continuing the discussion about noinput / anyprevout

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

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] Signing CHECKSIG position in Tapscript

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

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

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] [Lightning-dev] Continuing the discussion about noinput / anyprevout

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

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] Taproot (and graftroot) complexity

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

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] Modern Soft Fork Activation

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

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] BIP-341: Committing to all scriptPubKeys in the signature message

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] Generalizing feature negotiation when new p2p connections are setup

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

[bitcoin-dev] Thoughts on soft-fork activation

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

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

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

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

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

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

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

  1   2   3   >