Re: [bitcoin-dev] Making AsicBoost irrelevant

Is the design and manufacturing processes for the most power efficient ASICs otherwise patent unencumbered? If not, why do we care so much about this one patent over all the others that stand on the road between pen and paper computation and thermodynamically ideal computation? On Wed, May 11, 20

Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

On Wed, Jun 15, 2016 at 7:00 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: Indeed, and you can go even further. When there are multiple "sending" > outputs, pick one at random, and mimic it for the change output. This means > that if you have a P2PKH and 3 P2SH

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

On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 16, 2016 at 07:37:19PM +, Luke Dashjr via bitcoin-dev > wrote: > > On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote: > > > A new BIP is prepared to

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

On Tue, Aug 16, 2016 at 6:30 PM, Pieter Wuille wrote: > On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > If one's goal is to mess with an transaction to prevent it from being > mined

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

I see. But is it really necessary to soft fork over this issue? Why not just make it a relay rule? Miners are already incentivized to modify transactions to drop excess witness data and/or prioritize (versions of) transactions based on their cost. If a miner wants to mine a block with excess wi

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

ue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell wrote: > On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev > wrote: > > I see. > > > > But is it really necessary to soft fork over this issue? Why not just > make > > it a relay rule? Miners are

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

For sake of example, suppose we have a marginal fee rate of 50 satoshis per byte. At that rate reducing the size of the witness data by 1 byte is approximately equivalent from a miner and relayer's perspective as a replace by fee that increases the fee by 50 satoshis. In both cases miners get an

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

I believe Bitcoin currently enjoys the property that during an "innocent" re-org, i.e. a reorg in which no affected transactions are being double spent, all affected transactions can always eventually get replayed, so long as the re-org depth is less than 100. My concern with this proposed operati

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

If I understand this BIP correctly, the values pushed onto the stack by the OP_COUNT_ACKS operation depends on the ack and nack counts relative to the block that this happens to be included in. This isn't going to be acceptable. The validity of a transaction should always be monotone in the sense

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

> But I would argue that in this scenario, the only way it > would become invalid is the equivalent of a double-spend... and therefore > it > may be acceptable in relation to this argument. > The values returned by OP_COUNT_ACKS vary in their exact value depending on which block this transaction e

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

> I don't know if it's possible to implement decentralised sidechains without > "breaking" this rule. > I haven't really been following the sidechain developements, but my understanding was that redemption from a side chain would be two phase. The person unpegging the funds provides a proof that t

[bitcoin-dev] Fwd: Re: Drivechain proposal using OP_COUNT_ACKS

; This affects fungabity of coins generated from these transactions. > > > On Oct 2, 2016 18:37, "Sergio Demian Lerner" wrote: >> >> >> >> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: &

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

bity of coins generated from these transactions. >> >> On Oct 2, 2016 18:37, "Sergio Demian Lerner" >> wrote: >> >>> >>> >>> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev < >>> bitcoin-dev@lists.linuxfou

[bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

Hi all, It is possible to implement covenants using two script extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already available in the Elements Alpha sidechain, so it is possible to construct covenants in Elements Alpha today. I have detailed how the construction w

Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

-SHA256 > > https://github.com/jl2012/bitcoin/commits/mast_v3_master > > > On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi all, > > It is possible to implement covenants using two script extensions:

Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

;to the end of the signature"? > Probably should reed "Notice that we have appended 0x8300 to the end of the transaction data". I'll make an update. > > On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev < > bitcoin-de

[bitcoin-dev] Flexible Transactions.

Hi Tom, On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev wrote: > > The OP_CHECKSIG is the most well known and, as its name implies, it > validates a signature. > In the new version of 'script' (version 2) the data that is signed is > changed to be equivalent to the transaction-id. This is a

Re: [bitcoin-dev] Flexible Transactions.

On Mon, Nov 21, 2016 at 3:28 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks for your email, Russell. > > Unfortunately you waited 6 weeks with writing this and the problem you are > seeing has been fixed quite some time ago. > Oh, that is good news! I loo

Re: [bitcoin-dev] Script Abuse Potential?

OP_2DUP? Why not OP_3DUP? On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > No, there could only have not more than 201 opcodes in a script. So you > may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB > > For OP_CAT, just check i

Re: [bitcoin-dev] Script Abuse Potential?

For the record, the OP_CAT limit of 520 bytes was added by Satoshi on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT was disabled. The previous limi

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

On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" wrote: Other researchers have come to the conservative conclusion that we could handle 4MB blocks today. I believe this is a mischaracterization of the research conclusions. The actual conclusion was that the maximum value for the blocksi

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev > wrote: > > >SHA1 is insecure because the SHA1 algorithm is insecure, not because > > 160bits isn't enough. > > > >

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

On Sun, Apr 2, 2017 at 4:13 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > • the witness of the first input of the coinbase transaction MUST > have exactly one stack item (the "extended header"), with the following > data: > • bytes 0 to 3

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

Hi Jonathan, The proposal raised here does not deny miners the ability to use ASICBOOST. Miners can still use overt ASICBOOST by version bit fiddling and get the same power savings. In fact, overt ASICBOOST is much easier to implement than covert ASICBOOST, so I don't really understand what the o

Re: [bitcoin-dev] Segwit v2

On Wed, Apr 26, 2017 at 4:01 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There are things scriptSig can do that witness cannot today - specifically > add > additional conditions under the signature. We can always obsolete scriptSig > later, after segwit has pr

[bitcoin-dev] Quadratic Hashing in BIP 134

I noticed that the the latest BIP 134 now supports SIGHASH_SINGLE and friends. However, this support seems to reintroduce some quadratic hashing behavior because it calls

Re: [bitcoin-dev] Per-block non-interactive Schnorr signature aggregation

I'm a bit amateur at this sort of thing, but let me try to argue that this proposal is in fact horribly broken ;) Suppose Alice has some UTXO with some money Bob wants to steal. Grant me that the public key P0 protecting Alice's UTXO is public (say because the public key has been reused elsewhere

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

I recall chatting about this idea recently and my conclusion was the same as Peter Todd's conclusion: this will just encourage miners to false signal readiness with undermines both BIP 9 and BIP 8. I felt that rather than using script system for this construction, it would be better to use the tra

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

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 skipped when that > occurs. > To add a timeout a user can optionally bundle a pair of similar transactions.

[bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

## Introduction This document aims to specify and justify a method for computing Merkle roots for tree structures whose nodes are annotated with other data. While this proposal could be used to replace Bitcoin's Merkle root calculation, it is primarily aimed at new applications such as MAST, (U)TX

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On May 22, 2017 23:05, "Peter Todd" wrote: On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev wrote: > MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) > sha256Compress : Word256 × Word512 -> Word256 To be clear, what math operation

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On May 28, 2017 06:09, "Russell O'Connor" wrote: On May 28, 2017 03:16, "Peter Todd" wrote: On Mon, May 22, 2017 at 06:32:38PM -0400, Russell O'Connor wrote: > On May 22, 2017 23:05, "Peter Todd" wrote: > > On Mon, May 22, 2017 at 03:05:49A

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Sun, May 28, 2017 at 4:26 AM, Peter Todd wrote: > On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev > wrote: > > Not all of the inputs to the SHA256 compression function are created > > equal. Only the second argument, the chunk data, is

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Mon, May 29, 2017 at 12:10 PM, Peter Todd wrote: > On Mon, May 29, 2017 at 10:55:37AM -0400, Russell O'Connor wrote: > > Some of this proposal can be salvaged, I think, by putting the hash of > the > > tags into Sha256Compress's first argument: > > > > merkleRoot : Tree BitString -> Word25

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

While I'm not entirely convinced yet that accertaining non-ownership of an input is a robust method of solving the problem here, I also see little reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is already indirectly covered through the outpoints, so it is just a matter of op

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

> If you didn't verify the output scriptPubKeys, you would *only* be able > to care about fees since you couldn't verify where any of the funds went? > And you'd only be able to say fees are "at least x", since they could be > more if one of the scriptPubKeys turned out to be OP_TRUE eg. That might

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

On Sat, May 2, 2020 at 10:26 AM Anthony Towns wrote: > > except that we'd arguably still be missing: > > is this a coinbase output? (Coin.fCoinBase) > what was the height of the coin? (Coin.nHeight) > > Maybe committing to the coinbase flag would have some use, but committing > to the hei

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

I don't believe that 60 bytes is a problem here. SHA256 padding includes a length value of the original message data. Thus a padded non-64 byte transaction can never be the same as any padded 64-byte value, and therefore after applying the SHA256 compression function the resulting hashes cannot be

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > That brings me to Matt's point: there is no need to do this right now. We > can simply amend BIP173 to only permit length 20 and length 32 (and only > length 20 for v0, if you like; bu

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

15, 2020 at 5:05 PM Greg Sanders wrote: > Can you make it clear what the bold vs not-bold numbers mean? > > On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Wed, Nov 13, 2019 at 1:31

[bitcoin-dev] On the compatibility of Bech32 and Shamir's Secret Sharing

With the help of Pieter I've recently made some interesting mathematical observations about Bech32 codewords and Shamir's secret sharing: (1) Affine combinations of two Bech32 codewords is again a valid Bech32 codeword. (2) Lagrange polynomials form a partition of unity. The consequences of these

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

On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Rather than go through that again, I'd prefer we use the > backwards compatible proposal from BIPs PR#945 and, if we want to > maximize safety, consensus restrict v1 witness program s

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

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 is, generally speaking, considered a reasonably safe activation method in the sense that I thi

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

Appologies as I've rearranged your comments in my reply. On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo wrote: > > On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote: > > After a normal and successful Core update with LOT=false, we will have > more data showing broad

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

Hi Andrew, This is a slight misunderstanding of the proposal. Rather than an extended lockin period (a term I've erroneously used in the past) it is really a minimum activation height. Thus using your figures it would instead be: * start height = 681408 /* about May 1st */ * timeout height = 69

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

I'm pretty sure that the question of "is signalling still possible by the time enough miners have upgraded and are ready to start signalling?" Strongly benefits from a guaranteed number of signaling periods that height based activation offers. Especially for the short activation period of Speedy T

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

On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote: > > You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" ) > > Ten minute estimators can say: > > You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016)) > minutes" ) > > And nine minute estimators can say: > > Y

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

On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor wrote: > On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote: > >> >> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" ) >> >> Ten minute estimators can say: >> >> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 *

Re: [bitcoin-dev] maximum block height on transaction

>From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119: We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg > after a segmentation, transactions need to be able to get into the chain in > a later block. The OP_BLOCKNUMBER transaction and all its dependants would

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

Firstly, a minor point is that your proposal is a soft-fork, not a hard-fork. But more importantly, adding limitations on OP_RETURN transactions is not helpful. Users who want to embed arbitrary data in their transactions can always do so by encoding their data inside the values of legacy multi-s

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

This is a continuation of the thread at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html on this topic. I still remain unconvinced that we ought to give up on the "reorg safety" property that is explicitly part of Bitcoin's design. On Thu, Jun 10, 2021 at 1:56 PM Bil

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

As it stands today, in order to double spend a transaction during a reorg, one must take an active role of recognizing that a reorg has happened, hope that the new branch has completely omitted your spending transaction, and then quickly broadcast a replacement transaction with a higher fee to outb

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte wrote: > @Billy I like the idea. It is very obvious how useful an opcode like this > would be! (My background is in wallet implementation) > > @Russell I do understand your concerns of monotonism, however I'm having a > hard time really coming up wit

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud wrote: > > taproot annex > > From what I can tell, the annex is basically additional inputs to a script > that might have additional constraints put on it. Is that right? I don't > quite follow how moving the max height to the annex helps script cachi

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

Hi Jermy, As you are aware, we, and by we I mean mostly Sanket, are developing an updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements. The plan here would be to effectively support the an interface to the variable-length extension of BIP-0340 schnorr signatures. BIP-0340 would

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

There is one line written at https://github.com/ElementsProject/elements/pull/949/files#r660130155. I suppose we need to decide on which variants of *VERIFY and *ADD we want to include (presumably all of them) and choose which opcodes they will be assigned to. And I guess for CHECKSIGFROMSTACKADD

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

On Sun, Jul 4, 2021 at 1:30 PM Jeremy wrote: > I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound > to the txdata? When might you use this? > I don't feel strongly about *ADD. I just figured it might be useful to do a 2-of-3 between Alice, Bob and an Oracle signed value.

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

Bear in mind that when people are talking about enabling covenants, we are talking about whether OP_CAT should be allowed or not. That said, recursive covenants, the type that are most worrying, seems to require some kind of OP_TWEAK operation, and I haven't yet seen any evidence that this can be

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

On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor wrote: > Bear in mind that when people are talking about enabling covenants, we are > talking about whether OP_CAT should be allowed or not. > > That said, recursive covenants, the type that are most worrying, seems to > require some kind of OP_TWEA

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

Hi ZmnSCPxj, I don't believe we need to ban Turing completeness for the sake of banning Turing completeness. My concerns have always been around ensuring that transaction and block validation is not unduly burdensome for nodes. So for Bitcoin Script, we want to bound the amount of resources need

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

On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud wrote: > > when people are talking about enabling covenants, we are talking about > whether OP_CAT should be allowed or not > > Are they? Are you implying that anything that enables covenants is > equivalent to enabling OP_CAT? Generally when I think a

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

If the main outstanding issue is whether to split R or S, I think as far as Elements goes, I am inclined to go with the CAT option regardless of whether Bitcoin chooses to split R/S or not (not that I'm necessarily a decision maker here). The issue here is that (a) Elements already has CAT, and (b

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

On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj wrote: > Good morning Russell, > > > Hi ZmnSCPxj, > > > > I don't believe we need to ban Turing completeness for the sake of > banning Turing completeness. > > Well I believe we should ban partial Turing-completeness, but allow total > Turing-completeness.

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

On Wed, Jul 7, 2021 at 9:12 AM Russell O'Connor wrote: > > On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj wrote: > >> Good morning Russell, >> >> > Hi ZmnSCPxj, >> > >> > I don't believe we need to ban Turing completeness for the sake of >> banning Turing completeness. >> >> Well I believe we should b

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

Recapping the relationship between CTV and ANYPREVOUT:: It is known that there is a significant amount of overlap in the applications that are enabled by the CTV and ANYPREVOUT proposals despite the fact that their primary applications (congestion control for CTV and eltoo lightning channels for A

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

The > aforementioned properties may be difficult to reclaim once given away (with > the exception of perhaps scalability). > - Bringing CTV to an implemented state of near-unanimous "we could do > this, technically" is good for concretely driving the process of review for > an

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

On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns wrote: > > An Alternative Proposal:: > > ... > > > For similar reasons, TXHASH is not amenable to extending the set of > txflags > > at a later date. > > > I believe the difficulties with upgrading TXHASH can be mitigated by > > designing a robust se

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

On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne wrote: > > I don't think implementing a CTV opcode that we expect to largely be > obsoleted by a TXHASH at a later date is yielding good value from a soft > fork process. > > This presumes the eventual adoption of TXHASH (or something like it). > You

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

On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne wrote: > > Technical debt isn't a measure of weight of transactions. > > Sorry, my original sentence was a little unclear. I meant to say that the > notion that CTV is just a subpar waypoint en route to a more general > covenant system may not be ac

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

The hash would normally also cover the hash flags in use, and would be different in those two cases. But yes, it seems at the last minute I did include a suggestion to disable covering the flag themselves in the hash and appear to have accidentally allowed for recursive covenants (a common occurre

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

On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns wrote: > On Fri, Jan 28, 2022 at 08:56:25AM -0500, Russell O'Connor via bitcoin-dev > wrote: > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html > > For more complex interactions, I

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

On Tue, Feb 15, 2022 at 1:57 PM Jeremy Rubin wrote: > 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 CT

Re: [bitcoin-dev] Thoughts on fee bumping

> >> 2. (from Suhas) "once a valid transaction is created, it should not > become invalid later on unless the inputs are double-spent." > > This doesn't seem like a huge concern to me > > I agree that this shouldn't be a concern. In fact, I've asked numerous > people in numerous places what practic

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

On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell wrote: > 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 un

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

On Thu, Feb 17, 2022 at 9:27 AM Anthony Towns wrote: > > I guess that's all partly dependent on thinking that, TXHASH isn't > great for tx introspection (especially without CAT) and, (without tx > introspection and decent math opcodes), DLCs already provide all the > interesting oracle behaviour

Re: [bitcoin-dev] bitcoin scripting and lisp

On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It seems like a decent concept for exploration. > > AJ, I'd be interested to know what you've been able to build with Chia > Lisp and what your experience has been... e.g. what does the Li

Re: [bitcoin-dev] bitcoin scripting and lisp

The circuit generated from Simplicity was larger than the hand made one. On Sat, Mar 5, 2022 at 6:20 PM ZmnSCPxj wrote: > Good morning Russell, > > > On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > It seems like a decent con

[bitcoin-dev] Speedy Trial

On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > You're right, we shouldn't get personal. We shouldn't ignore feedback from > me, mark friedenbach or luke just because of who it comes from. > For goodness sake Jorge, enough with the

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón wrote: > I talked about this. But the "no-divergent-rules" faction doesn't like it, > so we can pretend we have listened to this "faction" and addressed all its > concerns, I guess. > Or perhaps it's just "prosectution complex", but, hey, what do I know

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón wrote: > > A major contender to the Speedy Trial design at the time was to mandate >> eventual forced signalling, championed by luke-jr. It turns out that, at >> the time of that proposal, a large amount of hash power simply did not have >> the firmwar

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

Setting aside my thoughts that something like Simplicity would make a better platform than Bitcoin Script (due to expression operating on a more narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there is an issue with namespace management. If I understand correctly, your implic

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

Thanks for the clarification. You don't think referring to the microcode via its hash, effectively using 32-byte encoding of opcodes, is still rather long winded? On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj wrote: > Good morning Russell, > > > Setting aside my thoughts that something like Simplic

Re: [bitcoin-dev] CTV Signet Parameters

On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > - is there really any benefit to doing it as a NOP vs a taproot-only >opcode like TXHASH? Theoretically, sure, that saves some bytes; but as >was pointed out on #bitcoin-wizar

[bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This vault design (https://github.com/jamesob/simple-ctv-vault) > is a good benchmark for evaluating covenant proposals because it's (i) > simple and (ii) has high utility for many use

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud wrote: > > If an attacker steals the hot key, then they have the option to simply > wait for the user to unvault their funds > > This is definitely true. Its kind of a problem with most vault proposals. > Its one of the primary reasons I designed an a

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

t me know if I get > this all wrong. > > On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote: > > It's not the attackers *only choice to succeed*. If an attacker steals > the hot key, then they have > > the option to simply wait for the user to unvault their

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud wrote: > @Russel > > the original MES vault .. commits to the destination address during > unvaulting > > I see. Looking at the MES16 paper, OP_COV isn't described clearly enough > for me to understand that it does that. However, I can imagine how it >

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Russell O'Connor wrote the definitive explanation for how ST arose in >> the consensus process and how it was designed to make everyone >> unhappy. It's a great explanation of what we we

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

Hi alicexbt, As far as I understand things, I believe the whole notion of a MUST_SIGNAL state is misguided today. Please correct me if I'm misunderstanding something here. Back when BIP8 was first proposed by Shaolin Fry, we were in a situation where many existing clients waiting for segwit signa

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE > OR NOT. > I think the state of the art has advanced to the point where we can say "OP_CAT in tapscript enables non

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj wrote: > Good morning Russell, > > > On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER > RECURSIVE OR NOT. > > > > > > I thi

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

On Fri, May 13, 2022 at 5:43 PM Anthony Towns wrote: > For any specific opcode proposal, I think you still want to consider > > 1) how much you can do with it > 2) how efficient it is to validate (and thus how cheap it is to use) > 3) how easy it is to make it do what you want > 4) how helpfu

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If transaction fees came in at an even rate over time all at the exact > same level then they work fine for security, acting similarly to fixed > block rewards. Unfortunately that isn't how

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

n the mempool. Also your point about centralization pressure is well taken. On Mon, Jul 11, 2022 at 5:56 PM Peter Todd wrote: > On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote: > > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via > bitcoin-d

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

>From my limited academic interactions, people generally take the "honest" to mean following the rules (regardless of how bad it is for you to follow those rules). This has in turn led to some blockchain designs based on their own absurd set of rules, and simply waiving away their issues by stipul

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > However, what *is* important about what Satoshi wrote is that it is sort > of the "social contract" of what Bitcoin is that we can all sort of > minimally agree to. This makes it clear,

Re: [bitcoin-dev] Validity Rollups on Bitcoin

On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Instead of that approach, I assume we have fairly granular transaction > introspection opcodes from a list in Elements [2] (which seem like they > aren't actually used in mainnet Liqui

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

Since bytes in the witness are cheaper than bytes in the script pubkey, there is a crossover point in data size where it will simply be cheaper to use witness data. Where that crossover point is depends on the finer details of the overhead of the two methods, but you could make some reasonable ass

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

On Sat., Feb. 4, 2023, 21:01 Peter Todd, wrote: > > > On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev > wrote: > >Since bytes in the witness are cheaper than bytes in the script pubkey, > >there is a crossover point in data size where

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates. The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend. On Tue, Fe

<    1   2   3   >