From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 16755C002F; Wed, 19 Jan 2022 04:53:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id F2E6581BF4; Wed, 19 Jan 2022 04:53:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLj6F6Ic0iuX; Wed, 19 Jan 2022 04:53:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by smtp1.osuosl.org (Postfix) with ESMTPS id D966B813CE; Wed, 19 Jan 2022 04:53:39 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id z22so5291462edd.12; Tue, 18 Jan 2022 20:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=csFFlrx4Xz+THuakPWAaUmAMg1qRFDpBeGEaZhog+Zk=; b=D7FgLN0daVFTB/ZhsppF6pQRSFrRAMk3EcorGQAXO4nYWWgtCZq9tjKYttRSDRls/Z c5n3k/gsBGm/Z29Qk4VFnGo3DV0wRShqdr3xcS8W0xSFHDWfHV+tmB1fGqHdYlqnp+kg 5V/IS3+lza2DACU8q5cdzg6qWYLjjldtM3AaC/ARog183sdeNdeVNQRQBxo7BZdorWCB ql8CFpLYpLJ5UQnup5XbaXj9fqysIxolCyBMVBPVZeWVQ8teVWCMvLna2j3Qw2E2F4Hu zb68JZAqGWkLM6meidEdzweCjyR1LijZR30Zi7vmi1DI80ddYm8zs4jeiiHSzvH4NviF DedQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=csFFlrx4Xz+THuakPWAaUmAMg1qRFDpBeGEaZhog+Zk=; b=gDbFadpiYcaOTdVfirY+iaUKGW8/Ca+Wf117JQLIUHzoK3ArL1R7J1YFc+8A4NLoh8 7fipKaJ06PpNi7hUMX0qXBn0796cM4Z3c+Z/+NbsD9HK+hj+kQKyqIIfvjFh9D0Li+A3 fYCWDE4RUmq5WnkMGRst9jlfTIw0gmGQWA/xJnD1hkZJY2JGC658G95rS/RxM9KUgTvB 35kay+biI0Hv+SPxcTNmB/t0z9uq5gCWZMvNEYnVLx6/02zsZs8qYmt/GhdZF/c0isaC 9S73Y2OCJ7d6XsXLPVbJpM/xpqA3kcYftlhIR2bj9bjWhKR9Qj3DSKX5qhu4jqaEM8Rx oPtQ== X-Gm-Message-State: AOAM531y9K2TeW1pn9FXYhnpB1n5Tl8ElqhHhrp4+ioN7tEnXElIphnf IGs8NFLcvvm0Bwo9vjiPKV3rrm3LXAoItn23XyE= X-Google-Smtp-Source: ABdhPJyyGd5mkZUGWI5XiHvUXnWHp9BDzS+hkNGoLcXIwGWDfi+nJFxu6cj1+dyRHZNE/fQZnRoPdMpUYZ3h+HnnyLs= X-Received: by 2002:a17:907:9802:: with SMTP id ji2mr22741191ejc.207.1642568017625; Tue, 18 Jan 2022 20:53:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Tue, 18 Jan 2022 22:53:21 -0600 Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000362ac305d5e82b90" X-Mailman-Approved-At: Wed, 19 Jan 2022 09:11:26 +0000 Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 04:53:42 -0000 --000000000000362ac305d5e82b90 Content-Type: text/plain; charset="UTF-8" > because you make transactions third party malleable it becomes possible to bundle and unbundle transactions. What I was suggesting doesn't make it possible to malleate someone else's transaction. I guess maybe my proposal of using a sighash flag might have been unclear. Imagine it as a script opcode that just says "this transaction must be mined with this other transaction" - the only difference being that you can use any output with any encumberance as an input for fee bumping. It doesn't prevent the original transaction from being mined on its own. So adding junk inputs would be no more of a problem than dust attacks already are. It would be used exactly like cpfp, except it doesn't spend the parent. I don't think what I was suggesting is as different from your proposal. All the problems of fee revenue optimization and feerate rules that you mentioned seem like they'd also exist for your proposal, or for cpfp. Let me know if I should clarify further. On Tue, Jan 18, 2022 at 8:51 PM Jeremy wrote: > The issue with sighash flags is that because you make transactions third > party malleable it becomes possible to bundle and unbundle transactions. > > This means there are circumstances where an attacker could e.g. see your > txn, and then add a lot of junk change/inputs + 25 descendants and strongly > anchor your transaction to the bottom of the mempool. > > because of rbf rules requiring more fee and feerate, this means you have > to bump across the whole package and that can get really messy. > > more generally speaking, you could imagine a future where mempools track > many alternative things that might want to be in a transaction. > > suppose there are N inputs each with a weight and an amount of fee being > added and the sighash flags let me pick any subset of them. However, for a > txn to be standard it must be < 100k bytes and for it to be consensus < > 1mb. Now it is possible you have to solve a knapsack problem in order to > rationally bundle this transaction out of all possibilities. > > This problem can get even thornier, suppose that the inputs I'm adding > themselves are the outputs of another txn in the mempool, now i have to > track and propagate the feerates of that child back up to the parent txn > and track all these dependencies. > > perhaps with very careful engineering these issues can be tamed. however > it seems with sponsors or fee accounts, by separating the pays-for from the > participates-in concerns we can greatly simplify it to something like: > compute effective feerate for a txn, including all sponsors that pay more > than the feerate of the base txn. Mine that txn and it's subsidies using > the normal algo. If you run out of space, all subsidies are same-sized so > just take the ones that pay the highest amount up until the added marginal > feerate is less than the next eligible txn. > > > -- > @JeremyRubin > > > > On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud > wrote: > >> I see, its not primarily to make it cheaper to append fees, but also >> allows appending fees in cases that aren't possible now. Is that right? I >> can certainly see the benefit of a more general way to add a fee to any >> transaction, regardless of whether you're related to that transaction or >> not. >> >> How would you compare the pros and cons of your account-based approach to >> something like a new sighash flag? Eg a sighash flag that says "I'm signing >> this transaction, but the signature is only valid if mined in the same >> block as transaction X (or maybe transactions LIST)". This could be named >> SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin >> transactions, and no special account would need to be created. Any >> transaction could specify this. At least that's the first thought I would >> have in designing a way to arbitrarily bump fees. Have you compared your >> solution to something more familiar like that? >> >> On Tue, Jan 18, 2022 at 11:43 AM Jeremy wrote: >> >>> Can you clarify what you mean by "improve the situation"? >>> >>> There's a potential mild bytes savings, but the bigger deal is that the >>> API should be much less vulnerable to pinning issues, fix dust leakage for >>> eltoo like protocols, and just generally allow protocol designs to be fully >>> abstracted from paying fees. You can't easily mathematically quantify API >>> improvements like that. >>> -- >>> @JeremyRubin >>> >>> >>> >>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud >>> wrote: >>> >>>> Do you have any back-of-the-napkin math on quantifying how much this >>>> would improve the situation vs existing methods (eg cpfp)? >>>> >>>> >>>> >>>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>>> Happy new years devs, >>>>> >>>>> I figured I would share some thoughts for conceptual review that have >>>>> been bouncing around my head as an opportunity to clean up the fee paying >>>>> semantics in bitcoin "for good". The design space is very wide on the >>>>> approach I'll share, so below is just a sketch of how it could work which >>>>> I'm sure could be improved greatly. >>>>> >>>>> Transaction fees are an integral part of bitcoin. >>>>> >>>>> However, due to quirks of Bitcoin's transaction design, fees are a >>>>> part of the transactions that they occur in. >>>>> >>>>> While this works in a "Bitcoin 1.0" world, where all transactions are >>>>> simple on-chain transfers, real world use of Bitcoin requires support for >>>>> things like Fee Bumping stuck transactions, DoS resistant Payment Channels, >>>>> and other long lived Smart Contracts that can't predict future fee rates. >>>>> Having the fees paid in band makes writing these contracts much more >>>>> difficult as you can't merely express the logic you want for the >>>>> transaction, but also the fees. >>>>> >>>>> Previously, I proposed a special type of transaction called a >>>>> "Sponsor" which has some special consensus + mempool rules to allow >>>>> arbitrarily appending fees to a transaction to bump it up in the mempool. >>>>> >>>>> As an alternative, we could establish an account system in Bitcoin as >>>>> an "extension block". >>>>> >>>>> *Here's how it might work:* >>>>> >>>>> 1. Define a special anyone can spend output type that is a "fee >>>>> account" (e.g. segwit V2). Such outputs have a redeeming key and an amount >>>>> associated with them, but are overall anyone can spend. >>>>> 2. All deposits to these outputs get stored in a separate UTXO >>>>> database for fee accounts >>>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee >>>>> amount and a TXID (or Outpoint?); B: a withdraw amount, a fee, and >>>>> an address >>>>> 4. These transactions are committed in an extension block merkle tree. >>>>> While the actual signature must cover the TXID/Outpoint, the committed data >>>>> need only cover the index in the block of the transaction. The public key >>>>> for account lookup can be recovered from the message + signature. >>>>> 5. In any block, any of the fee account deposits can be: released into >>>>> fees if there is a corresponding tx; consolidated together to reduce the >>>>> number of utxos (this can be just an OP_TRUE no metadata needed); or >>>>> released into fees *and paid back* into the requested withdrawal key >>>>> (encumbering a 100 block timeout). Signatures must be unique in a block. >>>>> 6. Mempool logic is updated to allow attaching of account fee spends >>>>> to transactions, the mempool can restrict that an account is not allowed >>>>> more spend more than it's balance. >>>>> >>>>> *But aren't accounts "bad"?* >>>>> >>>>> Yes, accounts are bad. But these accounts are not bad, because any >>>>> funds withdrawn from the fee extension are fundamentally locked for 100 >>>>> blocks as a coinbase output, so there should be no issues with any series >>>>> of reorgs. Further, since there is no "rich state" for these accounts, the >>>>> state updates can always be applied in a conflict-free way in any order. >>>>> >>>>> >>>>> *Improving the privacy of this design:* >>>>> >>>>> This design could likely be modified to implement something like >>>>> Tornado.cash or something else so that the fee account paying can be >>>>> unlinked from the transaction being paid for, improving privacy at the >>>>> expense of being a bit more expensive. >>>>> >>>>> Other operations could be added to allow a trustless mixing to be done >>>>> by miners automatically where groups of accounts with similar values are >>>>> trustlessly split into a common denominator and change, and keys are >>>>> derived via a verifiable stealth address like protocol (so fee balances can >>>>> be discovered by tracing the updates posted). These updates could also be >>>>> produced by individuals rather than miners, and miners could simply honor >>>>> them with better privacy. While a miner generating an update would be able >>>>> to deanonymize their mixes, if you have your account mixed several times by >>>>> independent miners that could potentially add sufficient privacy. >>>>> >>>>> The LN can also be used with PTLCs to, in theory, have another >>>>> individual paid to sponsor a transaction on your behalf only if they reveal >>>>> a valid sig from their fee paying account, although under this model it's >>>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by >>>>> withdrawing the rest. However, this could be partly solved by using >>>>> reputable fee accounts (reputation could be measured somewhat >>>>> decentralized-ly by longevity of the account and transactions paid for >>>>> historically). >>>>> >>>>> *Scalability* >>>>> >>>>> This design is fundamentally 'decent' for scalability because adding >>>>> fees to a transaction does not require adding inputs or outputs and does >>>>> not require tracking substantial amounts of new state. >>>>> >>>>> Paying someone else to pay for you via the LN also helps make this >>>>> more efficient if the withdrawal issues can be fixed. >>>>> >>>>> *Lightning:* >>>>> >>>>> This type of design works really well for channels because the >>>>> addition of fees to e.g. a channel state does not require any sort of >>>>> pre-planning (e.g. anchors) or transaction flexibility (SIGHASH flags). >>>>> This sort of design is naturally immune to pinning issues since you could >>>>> offer to pay a fee for any TXID and the number of fee adding offers does >>>>> not need to be restricted in the same way the descendant transactions would >>>>> need to be. >>>>> >>>>> *Without a fork?* >>>>> >>>>> This type of design could be done as a federated network that bribes >>>>> miners -- potentially even retroactively after a block is formed. That >>>>> might be sufficient to prove the concept works before a consensus upgrade >>>>> is deployed, but such an approach does mean there is a centralizing layer >>>>> interfering with normal mining. >>>>> >>>>> >>>>> Happy new year!! >>>>> >>>>> Jeremy >>>>> >>>>> -- >>>>> @JeremyRubin >>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>> --000000000000362ac305d5e82b90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 bec= ause you make transactions third party malleable it becomes possible to bun= dle and unbundle transactions.

What I was sugges= ting doesn't make it possible to malleate someone else's transactio= n.=C2=A0I guess maybe my proposal of using a sighash flag might have be= en unclear. Imagine it as a script opcode that just says "this transac= tion=C2=A0must be mined with this other transaction" - the only differ= ence being that you can use any output with any encumberance=C2=A0as an inp= ut for fee=C2=A0bumping. It doesn't prevent the original transaction fr= om being mined on its own. So adding junk inputs would be no more of a prob= lem than dust attacks already are. It would be used exactly like cpfp, exce= pt it doesn't spend the parent.=C2=A0

= I don't think what I was suggesting is as different from your proposal.= All the problems of fee revenue optimization and feerate rules that you me= ntioned seem like they'd also exist for your proposal, or for cpfp. Let= me know if I should clarify further.=C2=A0

On Tue, Jan 18, 202= 2 at 8:51 PM Jeremy <jlrubin@mit.edu<= /a>> wrote:
<= div dir=3D"ltr">
The issue with sighash = flags is that because you make transactions third party malleable it become= s possible to bundle and unbundle transactions.

This means ther= e are circumstances where an attacker could e.g. see your txn, and then add= a lot of junk change/inputs=C2=A0+ 25 descendants and strongly anchor your= transaction to the bottom of the mempool.

because of rbf rules= requiring more fee and feerate, this means you have to bump across the who= le package and that can get really messy.

more generally speaki= ng, you could imagine a future where mempools track many alternative things= that might want to be in a transaction.

suppose there are N in= puts each with a weight and an amount of fee being added and the sighash fl= ags let me pick any subset of them. However, for a txn to be standard it mu= st be < 100k bytes and for it to be consensus < 1mb. Now it is possib= le you have to solve a knapsack problem in order to rationally bundle this = transaction out of all possibilities.

This problem can get even= thornier, suppose that the inputs I'm adding themselves are the output= s of another txn in the mempool, now i have to track and propagate the feer= ates of that child back up to the parent txn and track all these dependenci= es.

perhaps with very careful engineering these issues can be t= amed. however it seems with sponsors or fee accounts, by separating the pay= s-for from the participates-in concerns we can greatly simplify it to somet= hing like: compute effective feerate for a txn, including all sponsors that= pay more than the feerate of the base txn. Mine that txn and it's subs= idies using the normal algo. If you run out of space, all subsidies are sam= e-sized so just take the ones that pay the highest amount up until the adde= d marginal feerate is less than the next eligible txn.




On Tue, Jan = 18, 2022 at 6:38 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:
I see, its not= primarily to make it cheaper to append fees, but also allows appending fee= s in cases that aren't possible now. Is that right? I can certainly see= the benefit of a more general way to add a fee to any transaction, regardl= ess of whether you're related to that transaction or not.=C2=A0
How would you compare the pros and cons of your account-based a= pproach to something like a new sighash flag? Eg a sighash flag that says &= quot;I'm signing this transaction, but the signature is only valid if m= ined in the same block as transaction=C2=A0X (or maybe transactions LIST)&q= uot;. This could be named SIGHASH_EXTERNAL. Doing this would be a lot more = similar to other bitcoin transactions, and no special account would need to= be created. Any transaction could specify this. At least that's the fi= rst thought I would have in designing a way to arbitrarily bump fees. Have = you compared your solution to something more familiar like that?

On Tu= e, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin@mit.edu> wrote:
Can you clarify what you mean by "improve the situation&quo= t;?

There's a potential mild bytes savings, but the bigger = deal is that the API should be much less vulnerable to pinning issues, fix = dust leakage for eltoo like protocols, and just generally allow protocol de= signs to be fully abstracted from paying fees. You can't easily mathema= tically quantify=C2=A0API improvements=C2=A0like that.


On Tue, Jan 18, 2022 at 8:1= 3 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:
Do you have any back-of-= the-napkin math on quantifying=C2=A0how much this would improve the situati= on vs existing methods (eg cpfp)?

<= span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">
=

On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
Happy new years devs,
<= br>
I figured I would share some t= houghts for conceptual review that have been bouncing around my head as an = opportunity to clean up the fee paying semantics in bitcoin "for good&= quot;. The design space is very wide on the approach I'll share, so bel= ow is just a sketch of how it could work which I'm sure could be improv= ed greatly.

Transaction fees are an integral part of bitcoin.=

However, due to quirks of Bitcoin's transaction design, fe= es are a part of the transactions that they occur in.

While thi= s works in a "Bitcoin 1.0" world, where all transactions are simp= le on-chain transfers, real world use of Bitcoin requires support for thing= s like Fee Bumping stuck transactions, DoS resistant Payment Channels, and = other long lived Smart Contracts that can't predict future fee rates. H= aving the fees paid in band makes writing these contracts much more difficu= lt as you can't merely express the logic you want for the transaction, = but also the fees.

Previously, I proposed a special type of tra= nsaction called a "Sponsor" which has some special consensus=C2= =A0+ mempool rules to allow arbitrarily appending fees to a transaction to = bump it up in the mempool.

As an alternative, we could establis= h an account system in Bitcoin as an "extension block".

Here's how it might work:

1. Define a special any= one can spend output type that is a "fee account" (e.g. segwit V2= ). Such outputs have a redeeming key and an amount associated with them, bu= t are overall anyone can spend.
2.= All deposits to these outputs get stored in a separate UTXO database for f= ee accounts
3. Fee accounts can si= gn only two kinds of transaction: A: a fee amount and a TXID (or Outpoint?)= ; B: a withdraw amount, a fee, and an=C2=A0address
4. These transactions are committed in an extension block = merkle tree. While the actual signature must cover the TXID/Outpoint, the c= ommitted data need only cover the index in the block of the transaction. Th= e public key for account lookup can be recovered from the message=C2=A0+ si= gnature.
5. In any block, any of t= he fee account deposits can be: released into fees if there is a correspond= ing tx; consolidated together to reduce the number of utxos (this can be ju= st an OP_TRUE no metadata needed); or released into fees *and paid back* in= to the requested withdrawal key (encumbering a 100 block timeout). Signatur= es must be unique in a block.
6. M= empool logic is updated to allow attaching of account fee spends to transac= tions, the mempool can restrict that an account is not allowed more spend m= ore than it's balance.

But aren't accounts "bad= "?

Yes, accounts are bad. But these accounts are not= bad, because any funds withdrawn from the fee extension are fundamentally = locked for 100 blocks as a coinbase output, so there should be no issues wi= th any series of reorgs. Further, since there is no "rich state" = for these accounts, the state updates can always be applied in a conflict-f= ree way in any order.


Improving the privacy of this design:

This design c= ould likely be modified to implement something like Tornado.cash or somethi= ng else so that the fee account paying can be unlinked from the transaction= being paid for, improving privacy at the expense of being a bit more expen= sive.

Other operations could be added to allow a trustless mixi= ng to be done by miners automatically where groups of accounts with similar= values are trustlessly =C2=A0split into a common denominator and change, a= nd keys are derived via a verifiable stealth address like protocol (so fee = balances can be discovered by tracing the updates posted). These updates co= uld also be produced by individuals rather than miners, and miners could si= mply honor them with better privacy. While a miner generating an update wou= ld be able to deanonymize their mixes, if you have your account mixed sever= al times by independent miners that could potentially add sufficient privac= y.

The LN can also be used with PTLCs to, in theory, have anoth= er individual paid to sponsor a transaction on your behalf only if they rev= eal a valid sig from their fee paying account, although under this model it= 's hard to ensure that the owner doesn't pay a fee and then 'ca= ncel' by withdrawing the rest. However, this could be partly solved by = using reputable fee accounts (reputation could be measured somewhat decentr= alized-ly by longevity of the account and transactions paid for historicall= y).

Scalability

This design is funda= mentally 'decent' for scalability because adding fees to a transact= ion does not require adding inputs or outputs and does not require tracking= substantial amounts of new state.

Paying someone else to pay = for you via the LN also helps make this more efficient if the withdrawal is= sues can be fixed.

Lightning:

This ty= pe of design works really well for channels because the addition of fees to= e.g. a channel state does not require any sort of pre-planning (e.g. ancho= rs) or transaction flexibility (SIGHASH flags). This sort of design is natu= rally immune to pinning issues since you could offer to pay a fee for any T= XID and the number of fee adding offers does not need to be restricted in t= he same way the descendant transactions would need to be.

= Without a fork?

This type of design could be done as a fede= rated network that bribes miners -- potentially even retroactively after a = block is formed. That might be sufficient to prove the concept works before= a consensus upgrade is deployed, but such an approach does mean there is a= centralizing layer interfering with normal mining.


<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">Happy new year!!

Jeremy
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000362ac305d5e82b90--