Luke Dashjr [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-30 to 2023-05-08
💬 Posted a total of 376 messages
📚 Participated in the following categories: Bitcoin-development, BIP draft, SPAM, Libbitcoin, BIP, bitcoin-dev, xxxx, BIP/Draft, patch, BIP Draft, BIP Proposal, Meta, Pre-BIP, Lightning-dev, Opt-in full-RBF, Mempool spam
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n

Profile Code

nprofile1qqs95mglg3yzkea4krfses0g9xmx5fglphyegjph0klrchs04akrsqcgqqxzh

Author Public Key

npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n

Show more details

Last Notes

2023-08-03 17:31:03

- reply

📅 Original date posted:2023-08-02
🗒️ Summary of this message: Storage is not the issue with block sizes, and there are efforts to optimize how much space is needed by individual nodes.
📝 Original message:
Storage is not and never has been the trouble with block sizes. Please,
before participating in discussions of this topic, at least get a basic
understanding of it. Here's a talk I did a few years ago to get you
started: https://www.youtube.com/watch?v=CqNEQS80-h4&t=7s
Luke
On 8/2/23 07:07, GamedevAlice via bitcoin-dev wrote:
> > If the rate of growth of the blockchain is too high, Ordinals aren't the
> > cause, it's rather that the theoretical limit of the amount of
> storage that
> > can be added per block isn't sufficiently limited. (Whether they are
> used
> > to produce Ordinals or something else)
>
>
> True, the real question is whether the storage is in fact sufficiently
> limited. And I believe the answer to be 'yes'.
>
> Why? Consider a worst case scenario using the maximum block size of
> 4MB and a block time of 10min, that's a growth of 210.24GB per year.
> Some of that can be pruned, but let's just assume that you don't want
> to. And currently the entire blockchain is roughly 500GB.
>
> Now that looks like a lot of growth potential based on where we are at
> now. However, with the current cost of hardware, you can get a 5 TB
> hard drive for less than $150. That will last you 21 years before you
> run out of space. That's less than $0.02 per day.
>
> That is a worst case scenario.
>
> Consider that since cost of hardware drops over time, it will become
> less of a burden over time.
>
> Also, keep in mind there are efforts to optimize how much of that
> actually needs to be stored by nodes. For example, the aforementioned
> topic announcing Floresta which seems to be a node implementation that
> uses utreexo to allow nodes to run without needing to maintain the
> full UTXO set. Other initiatives exist as well.
>
> There is definitely a lot of optimization potential for drastically
> reducing how much space is actually needed by individual nodes.
>
>
>
> On Wed, Aug 2, 2023, 5:40 AM ,
> <bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Pull-req to enable Full-RBF by default (Peter Todd)
> 2. Re: Concern about "Inscriptions". (ashneverdawn)
> (Keagan McClelland)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Aug 2023 01:28:06 +0000
> From: Peter Todd <pete at petertodd.org>
> To: Daniel Lipshitz <daniel at gap600.com>
> Cc: Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default
> Message-ID: <ZMmxJoL1ZH4//8Fg at petertodd.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
> > Your research is not thorough and reaches an incorrect conclusion.
> >
> > As stated many times - we service payment processors and some
> merchants
> > directly - Coinspaid services multiple merchants and process a
> > significant amount of BTC they are a well known and active in
> the space -
> > as I provided back in December 2022 a email from Max the CEO of
> Coinspaid
> > confirming their use of 0-conf as well as providing there
> cluster addresses
> > to validate there deposit flows see here again -
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> > - if this is not sufficient then please email
> support at coinspaid.com and ask
> > to be connected to Max or someone from the team who can confirm
> Conspaid is
> > clients of GAP600. Max also at the time was open to do a call, I
> can check
> > again now and see if this is still the case and connect you.
> >
> > That on its own is enough of a sample to validate our statistics.
>
> Why don't you just give me an example of some merchants using
> Coinspaid, and
> another example using Coinpayments, who rely on unconfirmed
> transactions? If
> those merchants actually exist it should be very easy to give me
> some names of
> them.
>
> Without actual concrete examples for everyone to see for
> themselves, why should
> we believe you?
>
> > I have also spoken to Changelly earlier today and they offered
> to email pro
> > @ changelly.com <http://changelly.com> and they will be able to
> confirm GAP600 as a service
>
> Emailed; waiting on a reply.
>
> > provider. Also please send me the 1 trx hash you tested and I
> can see if it
> > was queried to our system and if so offer some info as to why it
> wasnt
> > approved. Also if you can elaborate how you integrated with
> Changelly - I
> > can check with them if that area is not integrated with GAP600.
>
> Why don't you just tell me exactly what service Changelly offers
> that relies on
> unconfirmed transactions, and what characteristics would meet
> GAP600's risk
> criteria? I and others on this mailing list could easily do test
> transactions
> if you told us what we can actually test. If your service actually
> works, then
> you can safely provide that information.
>
> I'm not going to give you any exact tx hashes of transactions I've
> already
> done, as I don't want to cause any problems for the owners of the
> accounts I
> borrowed for testing. Given your lack of honesty so far I have
> every reason to
> believe they might be retalliated against in some way.
>
> > As the architect of such a major change to the status of 0-conf
> > transactions I would think you would welcome the opportunity to
> speak to
> > business and users who actual activities will be impacted by
> full RBF
> > becoming dominant.
>
> Funny how you say this, without actually giving any concrete
> examples of
> businesses that will be affected. Who exactly are these
> businesses? Payment
> processors obviously don't count.
>
> > Are you able to provide the same i.e emails and contacts of
> people at
> > the mining pools who can confirm they have adopted FULL RBF ?
>
> I've already had multiple mining pools complain to me that they
> and their
> employees have been harassed over full-rbf, so obviously I'm not
> going to
> provide you with any private contact information I have. There's
> no need to
> expose them to further harassment.
>
> If you actually offered an unconfirmed transaction guarantee
> service, with real
> customers getting an actual benefit, you'd be doing test transactions
> frequently and would already have a very good idea of what pools
> do full-rbf.
> Why don't you already have this data?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> <http://petertodd.org>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL:
> <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment-0001.sig>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 1 Aug 2023 22:58:53 -0700
> From: Keagan McClelland <keagan.mcclelland at gmail.com>
> To: Hugo L <ashneverdawn at gmail.com>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
> (ashneverdawn)
> Message-ID:
>
> <CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L+14d3w at mail.gmail.com
> <mailto:CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L%2B14d3w at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> There is an open question as to whether or not we should figure
> out a way
> to price space in the UTXO set. I think it is fair to say that
> given the
> fact that the UTXO set space remains unpriced that we actually
> have no way
> to determine whether some of these transactions are spam or not.
> The UTXO
> set must be maintained by all nodes including pruned nodes,
> whereas main
> block and witness data do not have the same type of indefinite
> footprint,
> so in some sense it is an even more significant resource than
> chain space.
> We may very well discover that if we price UTXOs in a way that
> reflect the
> resource costs that usage of inscriptions would vanish. The
> trouble though
> is that such a mechanism would imply having to pay "rent" for an
> "account"
> with Bitcoin, a proposition that would likely be offensive to a
> significant
> portion of the Bitcoin user base.
>
> Cheers,
> Keags
>
> On Mon, Jul 31, 2023 at 4:55?AM Hugo L via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > I don't think it's anyone's place to judge which types of
> transactions
> > should be allowed or not on the network, in fact, when it comes
> to privacy
> > and censorship resistance, it would be better if we were not
> even able to
> > distinguish different types of transactions from one another in
> the first
> > place.
> >
> > We have limited resources on the blockchain and so they should
> go to the
> > highest bidder. This is already how the network functions and how it
> > ensures it's security.
> >
> > Rather than thinking about this as "spam", I think it's useful to
> > objectively think about it in terms of value to the marketplace
> (fees
> > they're willing to pay) against cost to the network (storage
> consumed). It
> > comes down to supply and demand.
> >
> > If the rate of growth of the blockchain is too high, Ordinals
> aren't the
> > cause, it's rather that the theoretical limit of the amount of
> storage that
> > can be added per block isn't sufficiently limited. (Whether they
> are used
> > to produce Ordinals or something else)
> >
> >
> >
> > On Sun, Jul 30, 2023, 5:51 PM , <
> > bitcoin-dev-request at lists.linuxfoundation.org> wrote:
> >
> >> Send bitcoin-dev mailing list submissions to
> >> bitcoin-dev at lists.linuxfoundation.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> or, via email, send a message with subject or body 'help' to
> >> bitcoin-dev-request at lists.linuxfoundation.org
> >>
> >> You can reach the person managing the list at
> >> bitcoin-dev-owner at lists.linuxfoundation.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of bitcoin-dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Re: Concern about "Inscriptions". (rot13maxi)
> >>
> >>
> >>
> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Sun, 30 Jul 2023 18:34:12 +0000
> >> From: rot13maxi <rot13maxi at protonmail.com>
> >> To: L?o Haf <leohaf at orangepill.ovh>, "vjudeu at gazeta.pl"
> >> <vjudeu at gazeta.pl>
> >> Cc: Bitcoin Protocol Discussion
> >> <bitcoin-dev at lists.linuxfoundation.org>
> >> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
> >> Message-ID:
> >>
> >>
> <RIqguuebFmAhEDqCY_0T8KRqHBXEfcvPw6-MbDIyWsAWpLenFFeOVx88-068QFZr7xowg-6Zg988HsRCKdswtZC6QUKPXnrTyTAc_l5jphg=@
> >> protonmail.com <http://protonmail.com>>
> >>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hello,
> >>
> >> > This cat and mouse game can be won by bitcoin defenders. Why
> ? Because
> >> it is easier to detect these transactions and make them a
> standardization
> >> rule than to create new types of spam transactions.
> >>
> >> One of the things discussed during the mempoolfullrbf
> discussion is that
> >> a small (~10%) of nodes willing to relay a class of transaction
> is enough
> >> for that class of transaction to consistently reach miners.
> That means you
> >> would need to get nearly the entire network to run updated
> relay policy to
> >> prevent inscriptions from trivially reaching miners and being
> included in
> >> blocks. Inscription users have shown that they are willing and
> able to send
> >> non-standard transactions to miners out of band (
> >>
> https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
> >> so even if you managed to get enough of the network running the
> new rule to
> >> prevent propagation to miners, those users can just go out of
> band. Or,
> >> they can simply change the script that is used to embed an
> inscription in
> >> the transaction witness. For example, instead of 0 OP_IF?,
> maybe they do 0
> >> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect
> this, they
> >> have to update the rule and wait for 90%
> >> + of the network to upgrade. When the pro-inscription people
> see this,
> >> they only have to convince other inscription enthusiasts and
> businesses to
> >> update.
> >>
> >> The anti-inscription patch has to be run by many more
> participants (most
> >> of whom don?t care), while the pro-inscription update has to be
> run by a
> >> small number of people who care a lot. It?s a losing battle for the
> >> anti-inscription people.
> >>
> >> If you want to prevent inscriptions, the best answer we know of
> today is
> >> economic: the cost of the blockspace needs to be more expensive
> than
> >> inscribers are willing to pay, either because its too expensive
> or because
> >> there?s no market demand for inscriptions. The former relies on
> Bitcoin
> >> becoming more useful to more people, the latter is the natural
> course of
> >> collectibles.
> >>
> >> > Finally, I would like to quote satoshi himself who wrote
> about spam
> >> here is the link:
> >> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
> >>
> >> Appeals to Satoshi are not compelling arguments.
> >>
> >> Cheers,
> >> Rijndael
> >>
> >> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via bitcoin-dev <[
> >> bitcoin-dev at lists.linuxfoundation.org](mailto:On Sun, Jul 30,
> 2023 at
> >> 2:04 PM, L?o Haf via bitcoin-dev <<a href=)> wrote:
> >>
> >> > ?According to you, the rules of standardization are useless
> but in this
> >> case why were they introduced? The opreturn limit can be
> circumvented by
> >> miners, yet it is rare to see any, the same for maxancestorcount,
> >> minrelayfee or even the dust limit.
> >> >
> >> > This cat and mouse game can be won by bitcoin defenders. Why
> ? Because
> >> it is easier to detect these transactions and make them a
> standardization
> >> rule than to create new types of spam transactions.
> >> >
> >> > As for the default policy, it can be a weakness but also a
> strength
> >> because if the patch is integrated into Bitcoin Core by being
> activated by
> >> default, the patch will become more and more effective as the
> nodes update.
> >> >
> >> > Also, when it came to using a pre-segwit node, it is not a
> solution
> >> because this type of node cannot initiate new ones, which is
> obviously a
> >> big problem.
> >> >
> >> > Finally, I would like to quote satoshi himself who wrote
> about spam
> >> here is the link:
> >> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
> >> >
> >> >> Le 27 juil. 2023 ? 07:10, vjudeu at gazeta.pl a ?crit :
> >> >
> >> >>
> >> >
> >> >> ?
> >> >
> >> >>> not taking action against these inscription could be
> interpreted by
> >> spammers as tacit acceptance of their practice.
> >> >
> >> >>
> >> >
> >> >> Note that some people, even on this mailing list, do not
> consider
> >> Ordinals as spam:
> >>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html
> >> >
> >> >>
> >> >
> >> >> See? It was discussed when it started. Some people believe that
> >> blocking Ordinals is censorship, and could lead to blocking regular
> >> transactions in the future, just based on other criteria. That
> means, even
> >> if developers would create some official version with that
> option, then
> >> some people would not follow them, or even block
> Ordinals-filtering nodes,
> >> exactly as described in the linked thread:
> >>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html
> >> >
> >> >>
> >> >
> >> >>> as spammers might perceive that the Bitcoin network
> tolerates this
> >> kind of behavior
> >> >
> >> >>
> >> >
> >> >> But it is true, you have the whole pages, where you can find
> images,
> >> files, or other data, that was pushed on-chain long before
> Ordinals. The
> >> whole whitepaper was uploaded just on 1-of-3 multisig outputs, see
> >> transaction
> >>
> 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713.
> You have
> >> the whole altcoins that are connected to Bitcoin by using part
> of the
> >> Bitcoin's UTXO set as their database.
> >> >
> >> >>
> >> >
> >> >> That means, as long as you won't solve IBD problem and UTXO set
> >> growing problem, you will go nowhere, because if you block Ordinals
> >> specifically, people won't learn "this is bad, don't do that",
> they could
> >> read it as "use the old way instead", as long as you won't
> block all
> >> possible ways. And doing that, requires for example creating
> new nodes,
> >> without synchronizing non-consensus data, like it could be done
> in "assume
> >> UTXO" model.
> >> >
> >> >>
> >> >
> >> >> Also note that as long as people use Taproot to upload a lot
> of data,
> >> you can still turn off the witness, and become a pre-Segwit
> node. But if
> >> you block those ways, then people will push data into legacy
> parts, and
> >> then you will need more code to strip it correctly. The block
> 774628 maybe
> >> contains almost 4 MB of data from the perspective of Segwit
> node, but the
> >> legacy part is actually very small, so by turning witness off,
> you can
> >> strip it to maybe just a few kilobytes.
> >> >
> >> >>
> >> >
> >> >>> I want to emphasize that my proposal does not involve
> implementing a
> >> soft fork in any way. On the contrary, what I am asking is
> simply to
> >> consider adding a standardization option. This option would
> allow the
> >> community to freely decide whether it should be activated or not.
> >> >
> >> >>
> >> >
> >> >> 1. Without a soft-fork, those data will be pushed by mining
> pools
> >> anyway, as it happened in the block 774628.
> >> >
> >> >> 2. Adding some settings won't help, as most people use the
> default
> >> configuration. For example, people can configure their nodes to
> allow free
> >> transactions, without recompiling anything. The same with
> disabling dust
> >> amounts. But good luck finding a node in the wild that does
> anything
> >> unusual.
> >> >
> >> >> 3. This patch produced by Luke Dashjr does not address all
> cases. You
> >> could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used
> by Ordinals,
> >> and easily bypass those restrictions. This will be just a cat
> and mouse
> >> game, where spammers will even use P2PK, if they will be forced
> to. The
> >> Pandora's box is already opened, that fix could be good for
> February or
> >> March, but not now.
> >> >
> >> >>
> >> >
> >> >>
> >> >
> >> >>
> >> >
> >> >>> On 2023-07-26 11:47:09 user leohaf at orangepill.ovh wrote:
> >> >
> >> >>> I understand your point of view. However, inscription
> represent by
> >> far the largest spam attack due to their ability to embed
> themselves in the
> >> witness with a fee reduction.
> >> >
> >> >>
> >> >
> >> >> Unlike other methods, such as using the op_return field
> which could
> >> also be used to spam the chain, the associated fees and the
> standardization
> >> rule limiting op_return to 80 bytes have so far prevented
> similar abuses.
> >> >
> >> >>
> >> >
> >> >> Although attempting to stop inscription could lead to more
> serious
> >> issues, not taking action against these inscription could be
> interpreted by
> >> spammers as tacit acceptance of their practice. This could
> encourage more
> >> similar spam attacks in the future, as spammers might perceive
> that the
> >> Bitcoin network tolerates this kind of behavior.
> >> >
> >> >>
> >> >
> >> >> I want to emphasize that my proposal does not involve
> implementing a
> >> soft fork in any way. On the contrary, what I am asking is
> simply to
> >> consider adding a standardization option. This option would
> allow the
> >> community to freely decide whether it should be activated or not.
> >> >
> >> >>
> >> >
> >> >>
> >> >
> >> >>>> Le 26 juil. 2023 ? 07:30, vjudeu at gazeta.pl a ?crit :
> >> >
> >> >>>> and I would like to understand why this problem has not been
> >> addressed more seriously
> >> >
> >> >>> Because if nobody has any good solution, then status quo is
> >> preserved. If tomorrow ECDSA would be broken, the default state
> of the
> >> network would be "just do nothing", and every solution would be
> >> backward-compatible with that approach. Burn old coins, and
> people will
> >> call it "Tether", redistribute them, and people will call it
> "BSV". Leave
> >> everything untouched, and the network will split into N parts,
> and then you
> >> pick the strongest chain to decide, what should be done.
> >> >
> >> >>>> However, when it comes to inscriptions, there are no available
> >> options except for a patch produced by Luke Dashjr.
> >> >
> >> >>> Because the real solution should address some different
> problem, that
> >> was always there, and nobody knows, how to deal with it: the
> problem of
> >> forever-growing initial blockchain download time, and
> forever-growing UTXO
> >> set. Some changes with "assume UTXO" are trying to address just
> that, but
> >> this code is not yet completed.
> >> >
> >> >>>> So, I wonder why there are no options to reject
> inscriptions in the
> >> mempool of a node.
> >> >
> >> >>> Because it will lead you to never ending chase. You will
> block one
> >> inscriptions, and different ones will be created. Now, they are
> present
> >> even on chains, where there is no Taproot, or even Segwit. That
> means, if
> >> you try to kill them, then they will be replaced by N regular
> >> indistinguishable transactions, and then you will go back to
> those more
> >> serious problems under the hood: IBD time, and UTXO size.
> >> >
> >> >>>> Inscriptions are primarily used to sell NFTs or Tokens,
> concepts
> >> that the Bitcoin community has consistently rejected.
> >> >
> >> >>> The community also rejected things like sidechains, and
> they are
> >> still present, just in a more centralized form. There are some
> unstoppable
> >> concepts, for example soft-forks. You cannot stop a soft-fork. What
> >> inscription creators did, is just non-enforced soft-fork. They
> believe
> >> their rules are followed to the letter, but this is not the
> case, as you
> >> can create a valid Bitcoin transaction, that will be some
> invalid Ordinals
> >> transaction (because their additional rules are not enforced by
> miners and
> >> nodes).
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> >>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html
> >> >
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >> ------------------------------
> >>
> >> End of bitcoin-dev Digest, Vol 98, Issue 20
> >> *******************************************
> >>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230801/3e3a2496/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 99, Issue 3
> ******************************************
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/b308b9ab/attachment-0001.html>

2023-06-09 13:03:59

- reply

📅 Original date posted:2021-10-04
📝 Original message:
On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > The "dust limit" is arbitrarily decided by each node, and cannot be
> > relied upon for security at all. Expecting it to be a given default value
> > is in itself a security vulnerability
>
> Reality is that an increasing number of funds are secured by assumptions
> around mempool behavior.
In other words, simply not secured.
> And sadly that's going to increase with Lightning growth and deployment of
> other L2s.
L2s shouldn't build on flawed assumptions.
> Maybe we could dry-up some policy rules in consensus like the dust limit
> one :)
No thanks. Not sure that would even help (since policies can always be set to
a higher dust limit than any consensus rule)

2023-06-09 13:03:58

- reply

📅 Original date posted:2021-10-04
📝 Original message:
On Monday 04 October 2021 15:09:28 Antoine Riard wrote:
> Still during August 2021, the Bitcoin Core dust limit was actively
> discussed on the mailing list. Changes of this dust limit would have
> affected the ongoing development of the mitigations.
The "dust limit" is arbitrarily decided by each node, and cannot be relied
upon for security at all. Expecting it to be a given default value is in
itself a security vulnerability.
P.S. It'd be nice if someone familiar with these could fill in
https://en.bitcoin.it/wiki/CVEs

2023-06-09 13:02:59

- reply

📅 Original date posted:2021-07-02
📝 Original message:
Yes, many systems doesn't really make sense. We can add editors and revise the
BIP process as needed (BOLTs might prefer to use markdown?). Even aside from
Lightning BIPs, there are several improvements that can be made, so it makes
sense to address everything at once.
https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
The BIP 2xx range has been set aside for Lightning years ago, and we can do
similar things to help keep things organized within BIPs. Kalle suggested
maybe it'd be better to do BIP "L###" instead, and perhaps that would work
better if there's likely to be several sub-namespaces.
Luke
On Friday 02 July 2021 12:02:28 Dan Gershony wrote:
> Hi,
> There will be many layer 2 (and probably layer 3) protocols (BOLT, RGB,
> Volts etc...) does it really make sense to merge them all into the BIPs
> system?
>
>
> On Fri, Jul 2, 2021 at 10:03 AM nathanael via Lightning-dev <
>
> lightning-dev at lists.linuxfoundation.org> wrote:
> > Michael Folkson <michaelfolkson at gmail.com> wrote:
> > > > Adding a third BIP editor more involved with Lightning sounds like a
> >
> > good idea.
> >
> > > Or alternatively if BOLTs were subsumed into BIPs I think Bastien
> > > would be a great additional BIP editor to cover Lightning related BIPs
> > >
> > > :) I think BOLTs being subsumed into BIPs would be nice but I'm
> > >
> > > pessimistic it will happen. Like legislation and regulation in the
> > > legacy financial system alphabet soups only expand they never get
> > > simplified. Let's at least resist alphabet soup expansion here.
> >
> > arent lightning improvements in the end bitcoin improvements too?
> > i am thinking of bips like the rfcs of the internet
> >
> > --
> > nathanael
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:02:56

- reply

📅 Original date posted:2021-07-01
📝 Original message:
BOLTs should be BIPs too. Ideally, the authors should be the ones to migrate
them, but mirroring is fine - just nobody's taken the time to do it yet.
Please stop promoting lies about the BIP repo. I did not "steelman" anything.
Adding a third BIP editor more involved with Lightning sounds like a good
idea.
On Thursday 01 July 2021 20:25:23 Olaoluwa Osuntokun wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
>
> create a
>
> > BIP and they create an environment of discussion).
>
> The answer to why not BIPs here applies to BOLTs as well, as bLIPs are
> intended to effectively be nested under the BOLT umbrella (same repo, etc).
> It's also the case that any document can be mirrored as a BIP, this has
> been suggested before, but the BIP editors have decided not to do so.
>
> bLIPs have a slightly different process than BIPs, as well as a different
> set
> of editors/maintainers (more widely distributed). As we saw with the Speedy
> Trial saga (fingers crossed), the sole (?) maintainer of the BIP process
> was able to effectively steelman the progression of an author document,
> with no sound technical objection (they had a competing proposal that
> could've been a distinct document). bLIPs sidestep shenanigans like this by
> having the primary maintainer/editors be more widely distributed and closer
> to the target domain (LN).
>
> The other thing bLIPs do is do away with the whole "human picks the number
> of documents", and "don't assign your own number, you must wait". Borrowing
> from EIPs, the number of a document is simply the number of the PR that
> proposes the document. This reduces friction, and eliminates a possible
> bikeshedding vector.
>
> -- Laolu
>
> On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces <arielluaces at gmail.com> wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
> > create a BIP and they create an environment of discussion).
> >
> > BOLTs are essentially one big BIP in the sense that they started as a
> > place for discussion but are now more rigid. BOLTs must be followed
> > strictly to ensure a node is interoperable with the network. And BOLTs
> > should be rigid, as rigid as any widely used BIP like 32 for example.
> > Even though BOLTs were flexible when being drafted their purpose has
> > changed from descriptive to prescriptive.
> > Any alternatives, or optional features should be extracted out of
> > BOLTs, written as BIPs. The BIP should then reference the BOLT and the
> > required flags set, messages sent, or alterations made to signal that
> > the BIP's feature is enabled.
> >
> > A BOLT may at some point organically change to reference a BIP. For
> > example if a BIP was drafted as an optional feature but then becomes
> > more widespread and then turns out to be crucial for the proper
> > operation of the network then a BOLT can be changed to just reference
> > the BIP as mandatory. There isn't anything wrong with this.
> >
> > All of the above would work exactly the same if there was a bLIP
> > repository instead. I don't see the value in having both bLIPs and
> > BIPs since AFAICT they seem to be functionally equivalent and BIPs are
> > not restricted to exclude lightning, and never have been.
> >
> > I believe the reason this move to BIPs hasn't happened organically is
> > because many still perceive the BOLTs available for editing, so
> > changes continue to be made. If instead BOLTs were perceived as more
> > "consensus critical", not subject to change, and more people were
> > strongly encouraged to write specs for new lightning features
> > elsewhere (like the BIP repo) then you would see this issue of growing
> > BOLTs resolved.
> >
> > Cheers
> > Ariel Lorenzo-Luaces
> >
> > On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> >
> > wrote:
> > > > That being said I think all the points that are addressed in Ryan's
> >
> > mail
> >
> > > > could very well be formalized into BOLTs but maybe we just need to
> >
> > rethink
> >
> > > > the current process of the BOLTs to make it more accessible for new
> >
> > ideas
> >
> > > > to find their way into the BOLTs?
> > >
> > > I think part of what bLIPs are trying to solve here is promoting more
> >
> > loosely
> >
> > > coupled evolution of the network. I think the BOLTs do a good job
> >
> > currently of
> >
> > > specifying what _base_ functionality is required for a routing node in
> > > a prescriptive manner (you must forward an HTLC like this, etc).
> > > However
> >
> > there's
> >
> > > a rather large gap in describing functionality that has emerged over
> >
> > time due
> >
> > > to progressive evolution, and aren't absolutely necessary, but enhance
> > > node/wallet operation.
> > >
> > > Examples of include things like: path finding heuristics (BOLTs just
> >
> > say you
> >
> > > should get from Alice to Bob, but provides no recommendations w.r.t
> >
> > _how_ to do
> >
> > > so), fee bumping heuristics, breach retribution handling, channel
> >
> > management,
> >
> > > rebalancing, custom records usage (like the podcast index meta-data,
> >
> > messaging,
> >
> > > etc), JIT channel opening, hosted channels, randomized channel IDs, fee
> > > optimization, initial channel boostrapping, etc.
> > >
> > > All these examples are effectively optional as they aren't required for
> >
> > base
> >
> > > node operation, but they've organically evolved over time as node
> > > implementations and wallet seek to solve UX and operational problems
> > > for their users. bLIPs can be a _descriptive_ (this is how things can
> > > be
> >
> > done)
> >
> > > home for these types of standards, while BOLTs can be reserved for
> > > _prescriptive_ measures (an HTLC looks like this, etc).
> > >
> > > The protocol as implemented today has a number of extensions (TLVs,
> >
> > message
> >
> > > types, feature bits, etc) that allow implementations to spin out their
> >
> > own
> >
> > > sub-protocols, many of which won't be considered absolutely necessary
> >
> > for node
> >
> > > operation. IMO we should embrace more of a "bazaar" style of evolution,
> >
> > and
> >
> > > acknowledge that loosely coupled evolution allows participants to more
> >
> > broadly
> >
> > > explore the design space, without the constraints of "it isn't a thing
> >
> > until N
> >
> > > of us start to do it".
> > >
> > > Historically, BOLTs have also had a rather monolithic structure. We've
> >
> > used
> >
> > > the same 11 or so documents for the past few years with the size of the
> > > documents swelling over time with new exceptions, features,
> > > requirements, etc. If you were hired to work on a new codebase and saw
> > > that everything
> >
> > is
> >
> > > defined in 11 "functions" that have been growing linearly over time,
> >
> > you'd
> >
> > > probably declare the codebase as being unmaintainable. By having
> > > distinct documents for proposals/standards, bLIPs (author documents
> > > really), each
> >
> > new
> >
> > > standard/proposal is able to be more effectively explained, motivated,
> >
> > versionsed,
> >
> > > etc.
> > >
> > > -- Laolu
> > >
> > >
> > > On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <
> >
> > lightning-dev at lists.linuxfoundation.org> wrote:
> > >> Hey everyone,
> > >>
> > >> just for reference when I was new here (and did not understand the
> >
> > processes well enough) I proposed a similar idea (called LIP) in 2018
> > c.f.:
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/00136
> >7.html
> >
> > >> I wonder what exactly has changed in the reasoning by roasbeef which I
> >
> > will repeat here:
> > >> > We already have the equiv of improvement proposals: BOLTs.
> >
> > Historically
> >
> > >> > new standardization documents are proposed initially as issues or
> >
> > PR's when
> >
> > >> > ultimately accepted. Why do we need another repo?
> > >>
> > >> As far as I can tell there was always some form of (invisible?)
> > >> barrier
> >
> > to participate in the BOLTs but there are also new BOLTs being offered:
> > >> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> > >> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> > >> and topics to be included like:
> > >> * dual funding
> > >> * splicing
> > >> * the examples given by Ryan
> > >>
> > >> I don't see how a new repo would reduce that barrier - Actually I
> > >> think
> >
> > it would even create more confusion as I for example would not know where
> > something belongs. That being said I think all the points that are
> > addressed in Ryan's mail could very well be formalized into BOLTs but
> > maybe we just need to rethink the current process of the BOLTs to make it
> > more accessible for new ideas to find their way into the BOLTs? One thing
> > that I can say from answering lightning-network questions on
> > stackexchange is that it would certainly help if the BOLTs where
> > referenced on lightning.network web page and in the whitepaper as the
> > place to be if one wants to learn about the Lightning Network
> >
> > >> with kind regards Rene
> > >>
> > >> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
> >
> > lightning-dev at lists.linuxfoundation.org> wrote:
> > >>> Hi all,
> > >>>
> > >>>
> > >>> The recent thread around zero-conf channels [1] provides an
> >
> > opportunity to discuss how the BOLT process handles features and best
> > practices that arise in the wild vs. originating within the process
> > itself. Zero-conf channels are one of many LN innovations on the app
> > layer that have struggled to make their way into the spec. John Carvalho
> > and Bitrefill launched Turbo channels in April 2019 [2], Breez posted
> > their solution to the mailing list for feedback in August 2020 [3], and
> > we know at least ACINQ and Muun (amongst others) have their own
> > implementations. In an ideal world there would be a descriptive design
> > document that the app layer implementers had collaborated on over the
> > years that the spec group could then pick up and merge into the BOLTs now
> > that the feature is deemed spec-worthy.
> >
> > >>> Over the last couple of months, we have discussed the idea of adding
> > >>> a
> >
> > BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
> > members of the community, and have received positive feedback from both
> > app layer and protocol devs. This would not affect the existing BOLT
> > process at all, but simply add a place for app layer best practices to be
> > succinctly described and organized, especially those that require
> > coordination. These features are being built outside of the BOLT process
> > today anyways, so ideally a bLIP process would bring them into the fold
> > instead of leaving them buried in old ML posts or not documented at all.
> >
> > >>> Some potential bLIP ideas that people have mentioned include: each
> >
> > lnurl variant, on-the-fly channel opens, AMP, dynamic commitments,
> > podcast payment metadata, p2p messaging formats, new pathfinding
> > heuristics, remote node connection standards, etc.
> >
> > >>> If the community is interested in moving forward, we've started a
> >
> > branch [5] describing such a process. It's based on BIP-0002, so not
> > trying to reinvent any wheels. It would be great to have developers from
> > various implementations and from the broader app layer ecosystem
> > volunteer to be listed as editors (basically the same role as in the
> > BIPs).
> >
> > >>> Looking forward to hearing your thoughts!
> > >>>
> > >>>
> > >>> Best,
> > >>> Ryan
> > >>>
> > >>>
> > >>> [1]
> >
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/00307
> >4.html
> >
> > >>> [2]
> >
> > https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-
> >bitcoins-lightning-faster
> >
> > >>> [3]
> >
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002
> >780.html
> >
> > >>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
> >
> > Standardization of Protocols at the Request of the Kommunity (h/t
> > fiatjaf)
> >
> > >>> [5]
> >
> > https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-
> >0001.mediawiki
> >
> > >>> _______________________________________________
> > >>> Lightning-dev mailing list
> > >>> Lightning-dev at lists.linuxfoundation.org
> > >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > >>
> > >> --
> > >> https://www.rene-pickhardt.de
> > >> _______________________________________________
> > >> Lightning-dev mailing list
> > >> Lightning-dev at lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:02:48

- reply

📅 Original date posted:2021-06-30
📝 Original message:
Or just use BIPs instead of further fracturing...?
On Jun 30, 2021 10:10 AM, Ryan Gentry via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
>
> The recent thread around zero-conf channels [1] provides an opportunity to discuss how the BOLT process handles features and best practices that arise in the wild vs. originating within the process itself. Zero-conf channels are one of many LN innovations on the app layer that have struggled to make their way into the spec. John Carvalho and Bitrefill launched Turbo channels in April 2019 [2], Breez posted their solution to the mailing list for feedback in August 2020 [3], and we know at least ACINQ and Muun (amongst others) have their own implementations. In an ideal world there would be a descriptive design document that the app layer implementers had collaborated on over the years that the spec group could then pick up and merge into the BOLTs now that the feature is deemed spec-worthy.
>
>
> Over the last couple of months, we have discussed the idea of adding a BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various members of the community, and have received positive feedback from both app layer and protocol devs. This would not affect the existing BOLT process at all, but simply add a place for app layer best practices to be succinctly described and organized, especially those that require coordination. These features are being built outside of the BOLT process today anyways, so ideally a bLIP process would bring them into the fold instead of leaving them buried in old ML posts or not documented at all.
>
>
> Some potential bLIP ideas that people have mentioned include: each lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment metadata, p2p messaging formats, new pathfinding heuristics, remote node connection standards, etc.
>
>
> If the community is interested in moving forward, we've started a branch [5] describing such a process. It's based on BIP-0002, so not trying to reinvent any wheels. It would be great to have developers from various implementations and from the broader app layer ecosystem volunteer to be listed as editors (basically the same role as in the BIPs).
>
>
> Looking forward to hearing your thoughts!
>
>
> Best,
> Ryan
>
>
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>
> [2] https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>
> [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>
> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>
> [5] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki

2023-06-09 13:00:06

- reply

📅 Original date posted:2020-05-05
📝 Original message:
On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
> may attract a lot of adoption without users running a full-node.
No, it cannot be shifted. This would compromise Bitcoin itself, which for
security depends on the assumption that a supermajority of the economy is
verifying their incoming transactions using their own full node.
The past few years has seen severe regressions in this area, to the point
where Bitcoin's future seems quite bleak. Without serious improvements to the
full node ratio, Bitcoin is likely to fail.
Therefore, all efforts to improve the "full node-less" experience are harmful,
and should be actively avoided. BIP 157 improves privacy of fn-less usage,
while providing no real benefits to full node users (compared to more
efficient protocols like Stratum/Electrum).
For this reason, myself and a few others oppose merging support for BIP 157 in
Core.
> Assuming a user adoption path where a full-node is required to benefit for
> LN may deprive a lot of users, especially those who are already denied a
> real financial infrastructure access.
If Bitcoin can't do it, then Bitcoin can't do it.
Bitcoin can't solve *any* problem if it becomes insecure itself.
Luke
P.S. See also
https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25

2023-06-09 12:51:10

- reply

📅 Original date posted:2018-07-22
📝 Original message:
Lightning is covered by BIPs already. There's no need for a separate
repository, and the existing BOLTs should be submitted to the BIPs repository
too.
On Sunday 22 July 2018 13:45:21 René Pickhardt via Lightning-dev wrote:
> Hey everyone,
>
> in the grand tradition of BIPs I propose that we also start to have our own
> LIPs (Lightning Network Improvement proposals)
>
> I think they should be placed on the github.com/lightning account in a repo
> called lips (or within the lightning rfc repo) until that will happen I
> created a draft for LIP-0001 (which is describing the process and is 95%
> influenced by BIP-0002) in my github repo:
>
> https://github.com/renepickhardt/lips (There are some open Todos and
> Questions in this LIP)
>
> The background for this Idea: I just came home from the bitcoin munich
> meetup where I held a talk examining BOLT. As I was asked to also talk
> about the future plans of the developers for BOLT 1.1 I realized while
> preparing the talk that many ideas are distributed within the community but
> it seems we don't have a central place where we collect future enhancements
> for BOLT1.1. Having this in mind I think also for the meeting in Australia
> it would be nice if already a list of LIPs would be in place so that the
> discussion can be more focused.
> potential LIPs could include:
> * Watchtowers
> * Autopilot
> * AMP
> * Splicing
> * Routing Protcols
> * Broadcasting past Routing statistics
> * eltoo
> * ...
>
> As said before I would volunteer to work on a LIP for Splicing (actually I
> already started)
>
> best Rene

2023-06-09 12:51:07

- reply

📅 Original date posted:2018-07-03
📝 Original message:
On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional applications where a third party might pay to
> an address a second time, and should only be used in special protocols
> which make that kind of mistake unlikely.
I don't agree. Address reuse is undefined behaviour. Nobody should assume it
is safe or works.
I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in
a wallet I am writing, which explicitly does not support address reuse.
Luke

2023-06-09 12:46:56

- reply

📅 Original date posted:2016-11-30
📝 Original message:
To conclude discussion on BIP 2, I have opened a pull request to implement it
and mark it active. Note this implies activation and implementation of BIP 123
as well: https://github.com/bitcoin/bips/pull/478
I plan to merge this on December 14th. If there are any hard objections to
this change, please bring it up on the bitcoin-dev mailing list before then.
Further reviews of the implementation are welcome in the meantime. Please
refrain from requesting further changes to the BIPs themselves unless it is a
blocker/show-stopper or trivial (not changing the meaning).
In the process of implementing BIP 2, I came across a number of BIPs which
managed to get into the repository without a proper license. Authors of any of
these BIPs should open a pull request adding the necessary Copyright section
and License header(s). (If there are other contributors to the document in the
BIP git logs, I will try to reach out to them to get permission. If you have
accepted contributions from anyone not documented in git as an Author, please
mention this in the PR explicitly.)
These BIPs need a license:
001 BIP Purpose and Guidelines
010 Multi-Sig Transaction Distribution
011 M-of-N Standard Transactions
012 OP_EVAL
013 Address Format for pay-to-script-hash
014 Protocol Version and User Agent
015 Aliases
016 Pay to Script Hash
021 URI Scheme
030 Duplicate transactions
031 Pong message
032 Hierarchical Deterministic Wallets
033 Stratized Nodes
034 Block v2, Height in Coinbase
035 mempool message
039 Mnemonic code for generating deterministic keys
043 Purpose Field for Deterministic Wallets
044 Multi-Account Hierarchy for Deterministic Wallets
045 Structure for Deterministic P2SH Multisignature Wallets
047 Reusable Payment Codes for Hierarchical Deterministic Wallets
061 Reject P2P message
062 Dealing with malleability
064 getutxo message
066 Strict DER signatures
067 Deterministic Pay-to-script-hash multi-signature addresses through
public key sorting
068 Relative lock-time using consensus-enforced sequence numbers
070 Payment Protocol
071 Payment Protocol MIME types
072 bitcoin: uri extensions for Payment Protocol
073 Use "Accept" header for response type negotiation with Payment Request
URLs
075 Out of Band Address Exchange using Payment Protocol Encryption
101 Increase maximum block size
102 Block size increase to 2MB
103 Block size following technological growth
106 Dynamically Controlled Bitcoin Block Size Max Cap
120 Proof of Payment
121 Proof of Payment URI scheme
123 BIP Classification
Thanks,
Luke

2023-06-09 12:46:51

- reply

📅 Original date posted:2016-10-15
📝 Original message:
BIP 2 is currently believed to be a final draft of what will replace BIP 1 in
specifying how the entire BIP process works. This Process BIP will require
rough consensus from the Bitcoin-dev mailing list to become Active (see BIP 2
for the procedure, which I intend to use for its own activation due to absence
of a clear process defined in BIP 1).
Therefore, if you have any objections to the new BIP process as specified in
BIP 2, please voice your concerns ASAP.
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
Thanks for your review,
Luke

2023-06-09 12:46:22

- reply

📅 Original date posted:2016-07-18
📝 Original message:
On Sunday, July 10, 2016 8:35:21 AM Ron OHara wrote:
> With Bitcoin it is NOT 'Alice transacting with Bob'.
> It is Address(1) transacting with Address(2) .... and if both parties
> are following the recommended practice of not re-using addresses, then
> their next interaction is Address(3) transacting with Address(4) -
> removing any possibility of optimization.
This is wrong. Addresses only receive, never send.
It'd make sense* (but only at a low level) if you used "Key" instead of
"Address", but even that doesn't reflect on what is actually going on in
Bitcoin. There is simply a database update that is consuming N tokens (all of
which are authenticated by satisfying their respective scripts), and producing
M new tokens with defined scripts to authenticate future attempts to spend
them.
At a high level, you have two wallets transacting, but those wallets remain
the same regardless of address reuse. That is, Wallet(1) is transacting with
Wallet(2) for every interaction, there is no Wallet(3) or Wallet(4). And of
course, the blockchain cannot see anything about these Wallets today.
Luke
* To be picky, note that the next interaction might be Key(2) with Key(3) if
it is spending the output created by the initial interaction. But that's
beside the point.

2023-06-09 12:45:24

- reply

📅 Original date posted:2015-12-13
📝 Original message:
On Sunday, December 13, 2015 2:08:47 AM Denis Gorbachev wrote:
> Are you talking about the wallet integration or LN node management?
I don't see a distinction. Why wouldn't every wallet be a LN node?
> Suppose you are running an intermediary LN node. You want to compare your
> fees for current month VS previous month. You can do that with command line
> (dump the logs, parse them, etc) or you can do that with GUI.
Seems to me reports on various transactions would be a useful feature in
general, not necessarily tied to LN.
Luke

2023-06-09 12:45:23

- reply

📅 Original date posted:2015-12-12
📝 Original message:
On Sunday, December 13, 2015 1:03:12 AM Denis Gorbachev wrote:
> Hi everybody,
>
> Do you think it's a good idea to write a GUI for LN node management?
>
> Which features would you like to see there?
I would like to see it transparently supported in Bitcoin Core GUI, using an
external library.
Luke

- reply

- reply

- reply

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Bitcoin Core should have extended spam filters to Taproot transactions. A bugfix can address this issue, and censorship at the node level is an alternative.
📝 Original message:Action should have been taken months ago. Spam filtration has been a
standard part of Bitcoin Core since day 1. It's a mistake that the
existing filters weren't extended to Taproot transactions. We can
address that, or try a more narrow approach like OP_RETURN (ie, what
"Ordisrespector" does). Since this is a bugfix, it doesn't really even
need to wait for a major release.
(We already have pruning. It's not an alternative to spam filtering.)
Luke
On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:
> Hi guys,
>
> I think everyone on this list knows what has happened to the Bitcoin
> mempool during the past 96 hours. Due to side projects such as BRC-20
> having such a high volume, real bitcoin transactions are being priced
> out and that is what is causing the massive congestion that has
> arguable not been seen since December 2017. I do not count the March
> 2021 congestion because that was only with 1-5sat/vbyte.
>
> Such justifiably worthless ("worthless" is not even my word - that's
> how its creator described them[1]) tokens threaten the smooth and
> normal use of the Bitcoin network as a peer-to-pear digital currency,
> as it was intended to be used as.
>
> If the volume does not die down over the next few weeks, should we
> take an action? The bitcoin network is a triumvirate of developers,
> miners, and users. Considering that miners are largely the entities at
> fault for allowing the system to be abused like this, the harmony of
> Bitcoin transactions is being disrupted right now. Although this
> community has a strong history of not putting its fingers into pies
> unless absolutely necessary - an example being during the block size
> wars and Segwit - should similar action be taken now, in the form of
> i) BIPs and/or ii) commits into the Bitcoin Core codebase, to curtail
> the loophole in BIP 342 (which defines the validation rules for
> Taproot scripts) which has allowed these unintended consequences?
>
> An alternative would be to enforce this "censorship" at the node level
> and introduce a run-time option to instantly prune all non-standard
> Taproot transactions. This will be easier to implement, but won't hit
> the road until minimum next release.
>
> I know that some people will have their criticisms about this,
> absolutists/libertarians/maximum-freedom advocates, which is fine, but
> we need to find a solution for this that fits everyone's common
> ground. We indirectly allowed this to happen, which previously wasn't
> possible before. So we also have a responsibility to do something to
> ensure that this kind of congestion can never happen again using Taproot.
>
> -Ali
>
> ---
>
> [1]:
> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/6fa702e3/attachment.html>

2023-06-07 23:20:16

- reply

📅 Original date posted:2023-03-02
🗒️ Summary of this message: A developer plans to use service bit 24 to signal Utreexo-capable nodes on testnet and signet, with plans to release binaries in the coming months.
📝 Original message:This sounds like something that should be written up as a BIP and use a
normal service bit assignment...?
Luke
On 3/2/23 01:55, kcalvinalvin via bitcoin-dev wrote:
> Hello all,
>
> Wanted to tell the mailing list that I'll be using service bit 24 (1
> << 24) to signal that nodes are Utreexo capable nodes on testnet and
> signet as requested by the comment in protocol.h in
> bitcoind (https://github.com/bitcoin/bitcoin/blob/74981aa02d2b14ad1c0b82d1eb09cf3169eaa8ae/src/protocol.h#L295-L301).
> There are plans to release binaries for the utreexo node
> (github.com/utreexo/utreexod) in the next few months so that power
> users can try it out. I have no plans to release binaries for mainnet
> yet.
>
> Do let me know if someone else is using the same bit to signal for
> something else and we can coordinate accordingly.
>
> Best,
> Calvin
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:20:10

- reply

📅 Original date posted:2023-03-13
🗒️ Summary of this message: A proposed BIP for a deposit -> withdrawal -> resolve(claim/clawback) wallet paradigm is deemed too complicated for everyday use and may harm privacy. A new approach is suggested.
📝 Original message:In ordinary use cases, you wouldn't clawback; that would only be in the
extreme case of the wallet being compromised. So typical usage would
just be receive -> send, like wallets currently do.
Luke
On 3/13/23 10:56, Greg Sanders wrote:
> Didn't finish sentence: but in practice would end up with pretty
> similar usage flows imho, and as noted in PR, would take a different
> wallet paradigm,
> among other technical challenges.
>
> On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
> Hi Luke,
>
> Can you elaborate why the current idealized functionality of
> deposit -> trigger -> withdrawal is too complicated for
> everyday use but the above deposit -> withdrawal ->
> resolve(claim/clawback) wouldn't be? I admit at a high level
> it's a fine paradigm, but in practice would end
>
> Let's ignore implementation for the discussion, since that's in flux.
>
> Cheers,
> Greg
>
> On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I started reviewing the BIP, but stopped part way through, as
> it seems
> to have a number of conceptual issues.
>
> I left several comments on the PR
> (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),
>
> but ultimately I think it isn't simplified enough for
> day-to-day use,
> and would harm privacy quite a bit.
>
> Instead, I would suggest a new approach where:
>
> 1) Joe receives funds with a taproot output like normal.
> 2) Joe sends funds to Fred, but Fred cannot spend them until N
> blocks
> later (covenant-enforced relative locktime). Ideally, this should
> use/support a taproot keypath spend somehow. It would be nice
> to blind
> the particular relative locktime somehow too, but that may be
> too expensive.
> 2b) If Joe's funds were stolen, Joe can spend Fred's UTXO
> within the N
> block window to a recovery output.
>
> Unfortunately, the implementation details for this kind of
> setup are
> non-obvious and will likely require yet another address format
> (or at
> least recipient-wallet changes), but certainly seems within
> the scope of
> possibility.
>
> Thoughts?
>
> Luke
>
>
> On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
> > Since the last related correspondence on this list [0], a
> number of
> > improvements have been made to the OP_VAULT draft [1]:
> >
> > * There is no longer a hard dependence on package
> relay/ephemeral
> > anchors for fee management. When using "authorized
> recovery," all
> > vault-related transactions can be bundled with unrelated
> inputs and
> > outputs, facilitating fee management that is self
> contained to the
> > transaction. Consequently, the contents of this proposal
> are in theory
> > usable today.
> >
> > * Specific output locations are no longer hardcoded in any
> of the
> > transaction validation algorithms. This means that the
> proposal is now
> > compatible with future changes like SIGHASH_GROUP, and
> > transaction shapes for vault operations are more flexible.
> >
> > ---
> >
> > I've written a BIP that fully describes the proposal here:
> >
> >
> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
> >
> > The corresponding PR is here:
> >
> > https://github.com/bitcoin/bips/pull/1421
> >
> > My next steps will be to try for a merge to the inquisition
> repo.
> >
> > Thanks to everyone who has participated so far, but
> especially to AJ and
> > Greg for all the advice.
> >
> > James
> >
> > [0]:
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
> > [1]: https://github.com/bitcoin/bitcoin/pull/26857
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230313/1ee9a035/attachment.html>

2023-06-07 23:20:09

- reply

📅 Original date posted:2023-03-11
🗒️ Summary of this message: Luke reviewed the BIP but found conceptual issues and suggested a new approach for day-to-day use that would improve privacy. James O'Beirne proposed improvements to the OP_VAULT draft.
📝 Original message:I started reviewing the BIP, but stopped part way through, as it seems
to have a number of conceptual issues.
I left several comments on the PR
(https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),
but ultimately I think it isn't simplified enough for day-to-day use,
and would harm privacy quite a bit.
Instead, I would suggest a new approach where:
1) Joe receives funds with a taproot output like normal.
2) Joe sends funds to Fred, but Fred cannot spend them until N blocks
later (covenant-enforced relative locktime). Ideally, this should
use/support a taproot keypath spend somehow. It would be nice to blind
the particular relative locktime somehow too, but that may be too expensive.
2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N
block window to a recovery output.
Unfortunately, the implementation details for this kind of setup are
non-obvious and will likely require yet another address format (or at
least recipient-wallet changes), but certainly seems within the scope of
possibility.
Thoughts?
Luke
On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
> Since the last related correspondence on this list [0], a number of
> improvements have been made to the OP_VAULT draft [1]:
>
> * There is no longer a hard dependence on package relay/ephemeral
> anchors for fee management. When using "authorized recovery," all
> vault-related transactions can be bundled with unrelated inputs and
> outputs, facilitating fee management that is self contained to the
> transaction. Consequently, the contents of this proposal are in theory
> usable today.
>
> * Specific output locations are no longer hardcoded in any of the
> transaction validation algorithms. This means that the proposal is now
> compatible with future changes like SIGHASH_GROUP, and
> transaction shapes for vault operations are more flexible.
>
> ---
>
> I've written a BIP that fully describes the proposal here:
>
> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
>
> The corresponding PR is here:
>
> https://github.com/bitcoin/bips/pull/1421
>
> My next steps will be to try for a merge to the inquisition repo.
>
> Thanks to everyone who has participated so far, but especially to AJ and
> Greg for all the advice.
>
> James
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
> [1]: https://github.com/bitcoin/bitcoin/pull/26857
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:15:56

- reply

📅 Original date posted:2022-10-27
📝 Original message:More generally, some of the arguments against full RBF seem like debatable
reasons (though not fully convincing) to possibly leave it off, and/or
disabled by default, but definitely NOT reasons to remove the option and
prevent users from deciding for themselves.
On Thursday 27 October 2022 15:37:27 Anthony Towns via bitcoin-dev wrote:
> "Can I prevent someone else's transaction from propagating" is almost
> the entirety of the question with -datacarrier, -datacarriersize and
> -permitbaremultisig though:
Not necessarily the entirety, no. Even if others would propagate it, you also
don't want to waste _your_ bandwidth doing so. This also reveals a difference
between the two policies: with RBF, you have _already_ spent resources
propagating the first transaction (what this implies is not immediately
obvious).
Luke

2023-06-07 23:14:26

- reply

📅 Original date posted:2022-10-07
📝 Original message:On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote:
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to the new policies.
Policies are a per-node decision, and cannot be relied on in general.
Full RBF has been the default in Bitcoin Knots for years, and de facto viable
for use on the network even longer.
> However, when reviewing the 24.0 release candidate just
> a few days ago, we realized that zero-conf apps (like Muun) must
> *immediately turn off* their zero-conf features.
RBF deals with UNconfirmed transactions, not zero-confirmed (Lightning).
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can delay
> the opt-in deployment and find a safer way to deploy full-RBF?
Full RBF has been available for users on an opt-in basis since at least 2013,
long before BIP 125 was even conceived of.
> We call zero-conf applications to entities that accept on-chain payments
> from
> *untrusted parties* and will sometimes deliver the paid-for product or
> service
> without waiting for the transaction to be included in a block.
This is unsafe period. RBF does not make it any less unsafe.
> All of these applications are receiving incoming on-chain transactions for
> which
> they don't control the inputs, and performing a risk analysis to decide
> whether
> they are ok with accepting the payment without confirmation.
This is nothing but a false sense of security.
Luke

2023-06-07 23:12:32

- reply

📅 Original date posted:2022-08-04
📝 Original message:Policy is a subjective per-node, not systemic, not enforcable or expectable,
and generally not eligible for standardization.
The reason BIP125 is an exception, is because it is more than just policy.
It is a way for wallets and nodes to communicate. The wallet is saying "this
is the policy I would like you to apply to potential replacements of these
transactions". Whether the nodes abide this request or not, the purpose and
justification of the BIP is to standardize the communication of it.
Since BIP125 is widely implemented, it should not be changed except for
corrections to things which are errors deviating from the original intent.
If there is merely a new policy intended to be conveyed, a new BIP should be
written that is distinguishable from BIP125 (perhaps drop the sequence number
by 1 more). However, unless nodes are going to honour both the BIP125-request
policy *and* a new policy, it might be simpler for them to just not honour
the requested BIP125 policy exactly.
Also note that security should NEVER depend on assumptions of node policies.
Doing so would be a serious security vulnerability, regardless of what actual
network policies are. It's fine to blame nodes/miners if they single out your
transactions, but if it's just a matter of a general policy your transactions
are failing to meet, that's on the sender/L2 to adapt.
Luke
On Thursday 04 August 2022 14:54:54 Michael Folkson via bitcoin-dev wrote:
> A short history of RBF and BIP125
>
> The history of BIP125 is as far as I’m aware this. RBF rules were merged
> into Bitcoin Core in November 2015 [0]. Following that merge David Harding
> and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had
> been implemented in Bitcoin Core. The rationales for the rules in the BIP
> was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!)
> when L2 protocols were in their infancy. Certainly the research on the
> security of L2 protocols has come a long way since and we have a much
> better idea of some of the possible attacks on L2 protocols that to some
> extent are impacted by policy rules.
>
> In addition it was discovered [2] in May 2021 that the Bitcoin Core
> implementation of the RBF rules had never matched the RBF rules outlined in
> BIP125. Clearly this isn’t ideal but mistakes happen and will continue to
> happen. I certainly do not intend any criticism whatsoever to any of the
> individuals involved. Thankfully this discrepancy doesn’t seem to have
> resulted in any loss of funds or disruption. However, cross checking a
> specification with an implementation presumably led to the discovery and
> allowed for a post mortem on why the implementation didn’t match the
> specification.
>
> There seems to be two views on what to do next given that the RBF rules
> need to be updated. One is to ditch the idea of a specification for RBF
> rules and just document them in the Core repo instead. The other is to have
> a new specification for the RBF rules in Core and attempt to correct the
> mistakes made with BIP125 by having a BIP that does correctly outline the
> RBF rules implemented in Core and includes detailed rationales for why
> those RBF rules have been implemented.
>
> Should anyone care about where things are documented?
>
> Perhaps not but I think if you are a stakeholder in L2 protocol security
> you should. Suppose in the long term future an attacker exploits a L2
> vulnerability that is based on the default policy set by the dominant
> implementation on the network (Bitcoin Core). Which would you prefer the
> norm to be? A detailed static, well reviewed BIP standard that lays out the
> updated RBF rules and the rationales for those new rules that is reviewed
> outside the Core repo and hence not just by Core reviewers? Or cross
> checking Bitcoin Core code with non-standardized Core documentation
> typically reviewed only by Core reviewers?
>
> For the same reason the norm for consensus changes is a specification (BIP)
> and a reference implementation (Bitcoin Core) I think the norm for material
> step change policy changes should be a specification (BIP) and a reference
> implementation (Bitcoin Core). Policy is of course less risky than
> consensus for various reasons including there being no chain split risk if
> the user changes the default policy of their node. Alternative
> implementations are free to set entirely different policy rules too. But
> with L2 protocol security to some extent relying on policy whether we like
> it or not I think we should aspire to similar standards where possible for
> policy too.
>
> Specifications and implementations
>
> The Bitcoin Core review process generally requires Concept ACKs, Approach
> ACKs and then code review, testing ACKs in that order. The reason for this
> is even if the code is perfect if it is implementing a concept or an
> approach that informed reviewers oppose then it doesn’t matter that the
> code is perfect. Documentation is generally done post merge if at all. For
> most PRs e.g. refactors this makes sense. There is no point documenting
> something in advance if it is still under review or may not get merged. For
> consensus PRs this clearly doesn’t make sense. Many of us have and continue
> to cross check the Taproot BIPs with the Taproot reference implementation
> in Bitcoin Core. Having two points of reference released simultaneously is
> treating consensus changes with the highest possible standards we can. I
> think we should strive towards the highest possible standards for step
> change default policy changes in Core too given L2 protocol security is
> (unfortunately, ideally this wouldn’t be the case) relying on them.
>
> What are the new RBF rules replacing the BIP125 rules?
>
> The new RBF rules as implemented in Core today are documented here [3] in
> the Core repo (thanks for the link glozow). To the extent that these are a
> work in progress or close to final (i.e. intended to be static) I don’t
> know. The devs who work on policy will have a much better idea on these
> questions than me. Will the new RBF rules continue to be iterated upon as
> new research on L2 security comes to light? Will this iteration make it
> impossible to maintain a static set of rules that the broader ecosystem can
> get comfortable with? Or is a new static set of RBF rules close to being
> finalized and there is just an aversion to using BIPs and a specification?
>
> Generally, as time passes, the ecosystem grows, layers on top of the base
> layer get built out I get uncomfortable with what I perceive (correctly or
> incorrectly) as a slip in standards. If anything it should be going in the
> opposite direction. Standards should be improving and we should be striving
> to do better and be more rigorous than whatever the standard was in 2015.
> But I don’t work on policy in Core full time and it is very possible that
> there are subtleties that I’m entirely missing here. I think this is the
> right forum to ask about those subtleties though. Thanks to those who work
> on this important area.
>
> [0]: https://github.com/bitcoin/bitcoin/pull/6871
>
> [1]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.htm
>l
>
> [3]:
> https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replaceme
>nts.md
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-07 23:12:30

- reply

📅 Original date posted:2022-08-05
📝 Original message:On Friday 05 August 2022 04:05:56 Ali Sherief wrote:
> Yeah, I have a specific reason to advance this first (emphasis on the word
> first).
>
> I briefly mentioned in the BIP that BIP322 has superior message
> verification capabilities. This is true, but it suffers from the drawback
> that wallets are not using it.
Likely because it is a draft and incomplete.
> Message signatures are highly relied upon in some places (just to name a
> few, at many mining pools e.g. Slushpool, and the Bitcointalk forum),
I'm not aware of any using the current message signatures _correctly_.
Note they are not useful for proving that you sent a transaction, nor have the
ability to send a transaction or access to bitcoins.
> This BIP is kind of like a "bumper car", in that it forces compliance with
> previous BIPs that extend the message signing format, in particular BIP137.
BIPs can't force anything, they're just documentation.
IMO, there is no benefit to an additional message signing standard, especially
one that doesn't address the problems with the current standard or (at
present) BIP322.
Luke

2023-06-07 23:10:28

- reply

📅 Original date posted:2022-06-14
📝 Original message:Bitcoin Knots still uses this service bit, FWIW (though due to a bug in some
older versions, it wasn't signalled by default). There are probably at least
100 nodes with full RBF already.
On Wednesday 15 June 2022 02:27:20 Peter Todd via bitcoin-dev wrote:
> On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev
wrote:
> > If you're a node operator curious to play with full-rbf, feel free to
> > connect to this node or spawn up a toy, public node yourself. There is a
> > ##uafrbf libera chat if you would like information on the settings or
> > looking for full-rbf friends (though that step could be automated in the
> > future by setting up a dedicated network bit and reserving a few outbound
> > slots for them).
>
> I previously maintained a Bitcoin Core fork that did just that, using
> nServices bit 26:
>
> https://github.com/petertodd/bitcoin/commit/1cc1a46a633535c42394380b656d681
>258a111ac
>
> IIRC I was using the code written to prefer segwit peers; I have no idea if
> a similar approach is still easy to implement as I haven't worked on the
> Bitcoin Core codebase for years.

2023-06-07 23:10:00

- reply

📅 Original date posted:2022-05-30
📝 Original message:Bitcoin Knots version 23.0.knots20220529 is now available from:
https://bitcoinknots.org/files/23.x/23.0.knots20220529/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v23.0.knots20220529-release-notes/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220530/02496a9a/attachment.sig>

2023-06-07 23:07:59

- reply

📅 Original date posted:2022-04-22
📝 Original message:There's no reason for before/after/in place. We have version bits specifically
so we can have multiple deployments in parallel.
But none of this ST nonsense, please. That alone is a reason to oppose it.
Luke
On Friday 22 April 2022 11:11:41 darosior via bitcoin-dev wrote:
> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and implemented usecases, that are
> demanded and (please someone correct me if i'm wrong) more widely accepted
> than CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine. Sure then you can't have bare or
> Segwit v0 CTV, and it's a bit more expensive to use. But we can consider
> CTV an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase. Although
> as someone who've been trying to implement practical vaults for the past 2
> years i doubt CTV is necessary nor sufficient for this (but still useful!),
> using APO-AS covers it. And it's not a couple dozen more virtual bytes that
> are going to matter for a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain usage of a less efficient construction
> to achieve the same goal, we could roll-out CTV as an optimization. In the
> meantime others will have been able to deploy new applications leveraging
> ANYPREVOUT (Eltoo, blind statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that BIP118 is a soft fork candidate that
> could benefit more (if not most of) Bitcoin users. Actually i'd also be
> interested in knowing if people would oppose the APO-AS part of BIP118,
> since it enables CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-me
>ssage.
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:07:35

- reply

📅 Original date posted:2022-04-21
📝 Original message:On Thursday 21 April 2022 06:20:15 Jeremy Rubin wrote:
> > While reverting Segwit wouldn't be possible, it IS entirely possible to
> > do an additional softfork to either weigh witness data at the full 4
> > WU/Byte rate (same as other data), or to reduce the total weight limit so
> > as to extend the witness discount to non-segwit transactions (so scriptSig
> > is similarly discounted).
>
> What if I pre signed a transaction which was valid under the discounted
> weighting, but the increase in weight would make it invalid? This would
> serve to confiscate funds. Let's not do that.
You'd be confiscating your own funds by making an absurd spending condition.
By this argument, ALL softforks would have to be ruled out.
> > Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
> > variant which has no purpose other than to try to sabotage parallel UASF
> > efforts.
>
> Why didn't you upstream the code that was used for the actual activation
> into Bitcoin Core in the last year?
>
> In preparing it I just used what was available in Core now, surely the last
> year you could have gotten the appropriate patches done?
They were done, reviewed, and deployed in time for Taproot. You personally
played a part in sabotaging efforts to get it merged into Core, and violating
the community's trust in it by instead merging your BIP9 ST without
consensus. Don't play dumb. You have nobody to blame but yourself.
Luke

2023-06-07 23:07:34

- reply

📅 Original date posted:2022-04-21
📝 Original message:On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> @DavidHarding
>
> Interesting proposal to revert consensus changes. Is it possible to do this
> for soft forks that are already activated?
Generally, no. Reverting a softfork without a built-in expiry would be a
hardfork.
> Example: Some users are not okay with witness discount in segwit
> transactions
>
> https://nitter.net/giacomozucco/status/1513614380121927682
While reverting Segwit wouldn't be possible, it IS entirely possible to do an
additional softfork to either weigh witness data at the full 4 WU/Byte rate
(same as other data), or to reduce the total weight limit so as to extend the
witness discount to non-segwit transactions (so scriptSig is similarly
discounted).
> @LukeDashjr
>
> > The bigger issue with CTV is the miner-decision route. Either CTV has
> > community support, or it doesn't. If it does, miners shouldn't have the
> > ability to veto it. If it doesn't, miners shouldn't have the ability to
> > activate it (making it a 51% attack more than a softfork).
>
> Agree. UASF client compatible with this speedy trial release for BIP 119
> could be a better way to activate CTV. Users can decide if they prefer
> mining pools to make the decision for them or they want to enforce it
> irrespective of how many mining pools signal for it. I haven't seen any
> arguments against CTV from mining pools yet.
We had that for Taproot, and now certain people are trying to say Speedy Trial
activated Taproot rather than the BIP8 client, and otherwise creating
confusion and ambiguity.
Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
variant which has no purpose other than to try to sabotage parallel UASF
efforts.
At this point, it is probably better for any Speedy Trial attempts to be
rejected by the community and fail outright. Perhaps even preparing a real
counter-softfork to invalidate blocks signalling for it.
Luke

2023-06-07 23:07:32

- reply

📅 Original date posted:2022-04-20
📝 Original message:1-2 can be mitigated to some extent by encoding an expiry height in the
address (and pubkey?), and honouring CTV for UTXOs during the active period.
It might take longer to remove CTV code post-deactivation, but that's simply
a tradeoff to consider.
The bigger issue with CTV is the miner-decision route. Either CTV has
community support, or it doesn't. If it does, miners shouldn't have the
ability to veto it. If it doesn't, miners shouldn't have the ability to
activate it (making it a 51% attack more than a softfork).
On Thursday 21 April 2022 01:04:53 David A. Harding via bitcoin-dev wrote:
> Hi all,
>
> The main criticisms I'm aware of against CTV seem to be along the
> following lines:
>
> 1. Usage, either:
> a. It won't receive significant real-world usage, or
> b. It will be used but we'll end up using something better later
> 2. An unused CTV will need to be supported forever, creating extra
> maintenance
> burden, increasing security surface, and making it harder to evaluate
> later
> consensus change proposals due to their interactions with CTV
>
> Could those concerns be mitigated by making CTV an automatically
> reverting
> consensus change with an option to renew? E.g., redefining OP_NOP4 as
> OP_CTV
> for five years from BIP119's activation date and then reverting to
> OP_NOP4.
> If, prior to the end of those five years, a second soft fork was
> activated, it
> could continue enforcing the CTV rules either for another five years or
> permanently.
>
> This would be similar in nature to the soft fork described in BIP50
> where the
> maximum block size was temporarily reduced to address the BDB locks
> issue and
> then allowed to return to its original value. In Script terms, any use
> of
> OP_CTV would effectively be:
>
> OP_IF
> <arguments> OP_CTV
> OP_ELSE
> <5 years after activation> OP_CLTV
> OP_ENDIF
>
> As long as we are absolutely convinced CTV will have no negative effects
> on the
> holders or receivers of non-CTV coins, I think an automatically
> reverting soft
> fork gives us some ability to experiment with new features without
> committing
> ourselves to live with them forever.
>
> The main downsides I can see are:
>
> 1. It creates a big footgun. Anyone who uses CTV without adequately
> preparing for
> the reversion could easily lose their money.
>
> 2. Miners would be incentivized to censor spends of the reverting
> opcode near its reversion date. E.g., if Alice receives 100 bitcoins
> to a
> script secured only by OP_CTV and attempts to spend them the day
> before it
> becomes OP_NOP4, miners might prefer to skip confirming that
> transaction even
> if it pays a high feerate in favor of spending her 100 bitcoins to
> themselves
> the next day after reversion.
>
> The degree to which this is an issue will depend on the diversity of
> hashrate and the willingness of any large percentage of hashrate to
> deliberately reorg the chain to remove confirmed transactions. This
> could be
> mitigated by having OP_CTV change to OP_RETURN, destroying any
> unspent CTV-only
> coins so that any censoring miners only benefited from the (hopefully
> slight)
> decrease in bitcoin currency supply.
>
> 3. A bias towards keeping the change. Even if it turned out very few
> people
> really used CTV, I think there would be a bias at the end of five
> years towards
> "why not just keep it".
>
> 4. The drama doesn't end. Activating CTV now, or decisively not
> activating it,
> may bring to an end our frequent discussions about it (though I
> wouldn't
> count on that). An automatically reverting soft fork would probably
> guarantee we'll have further consensus-level discussions about CTV in
> the
> future.
>
> Thanks for reading. I'm curious to hear y'alls thoughts,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:06:01

- reply

📅 Original date posted:2022-03-10
📝 Original message:On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> The "no-miner-veto" concerns are, to an extent, addressed by the short
> timeline of Speedy Trial. No more waiting 2 years on the miners dragging
> their feet.
It's still a miner veto. The only way this works is if the full deployment
(with UASF fallback) is released in parallel.
> If you are so concerned about listening to legitimate criticism, maybe you
> can design a new deployment mechanism that addresses the concerns of the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> faction.
BIP8 already does that.
> 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 firmware required to support signalling. That activation proposal
> never got broad consensus,
BIP 8 did in fact have broad consensus before some devs decided to ignore the
community and do their own thing. Why are you trying to rewrite history?
> and rightly so, because in retrospect we see
> that the design might have risked knocking a significant fraction of mining
> power offline if it had been deployed. Imagine if the firmware couldn't be
> quickly updated or imagine if the problem had been hardware related.
They had 18 months to fix their broken firmware. That's plenty of time.
Luke

2023-06-07 23:02:31

- reply

📅 Original date posted:2022-01-18
📝 Original message:On Tuesday 18 January 2022 22:02:24 eric at voskuil.org wrote:
> The only material distinction between BIP9 and BIP8 is that the latter may
> activate without signaled support of hash power enforcement.
>
> As unenforced soft forks are not "backward compatible" they produce a chain
> split.
Enforcement of the Bitcoin consensus protocol is by users, not miners.
Softforks never produce a chain split. Miners can, and might try to do it to
cause disruption in retaliation, but the softfork itself does not.
> It was for this reason alone that BIP8 never gained sufficient
> support.
BIP 8 in fact achieved consensus for Taproot activation.
> This is one of the most misleading statements I've seen here. It's not
> technically a lie, because it states what "should" happen. But it is
> clearly intended to lead people to believe that BIP8 was actually used
> ("again") - it was not. ST was some technical tweaks to BIP9.
BIP 8 was used to activate Taproot.
> The outright deception around this one topic has led to significant
> unnecessary conflict in the community. Make your argument, but make it
> honestly.
You are the one attempting to deceive here.
Luke

2023-06-07 23:02:30

- reply

📅 Original date posted:2022-01-18
📝 Original message:tl;dr: I don't think CTV is ready yet (but probably close), and in any case
definitely not worth reviving BIP 9 with its known flaws and vulnerability.
My review here is based solely on the BIP, with no outside context (aside from
current consensus rules, of course). In particular, I have _not_ looked at
the CTV code proposed for Bitcoin Core yet.
>Covenants are restrictions on how a coin may be spent beyond key ownership.
nit: Poorly phrased. Even simple scripts can do that already.
>A few examples are described below, which should be the subject of future
non-consensus standardization efforts.
I would ideally like to see fully implemented BIPs for at least one of these
(preferably the claimed CoinJoin improvements) before we move toward
activation.
>Congestion Controlled Transactions
I think this use case hasn't been fully thought through yet. It seems like it
would be desirable for this purpose, to allow any of the recipients to claim
their portion of the payment without footing the fee for every other payment
included in the batch. This is still a covenant-type solution, but one that
BIP 119 cannot support as-is.
(I realise this may be a known and accepted limitation, but I think it should
be addressed in the BIP)
>Payment Channels
Why batch mere channel creation? Seems like the spending transaction should
really be the channel closing.
>CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than
previously because participants agree on a single output which pays all
participants, which will be lower fee than before.
I don't see how. They still have to agree in advance on the outputs, and the
total fees will logically be higher than not using CTV...?
>Further Each participant doesn't need to know the totality of the outputs
committed to by that output, they only have to verify their own sub-tree will
pay them.
I don't see any way to do this with the provided implementation.
>Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.
Hard NACK on this. BIP 9 at this point represents developers attempting to
disregard and impose their will over community consensus, as well as an
attempt to force a miner veto backdoor/vulnerability on deployment. It should
never be used again.
Speedy Trial implemented with BIP 8 made sense* as a possible neutral
compromise between LOT=True and LOT=False (which could be deployed prior to
or in parallel), but using BIP 9 would destroy this.
As with Taproot, any future deployments should use BIP 8 again, until a better
solution is developed. Reverting back to a known flawed and vulnerable
activation method should not be done, and it would be better not to deploy
CTV at all at such an expense.
The fact that certain developers attempted to deploy a BIP 9 alternative
activation for Taproot against community consensus, and that even managed to
get released as "Bitcoin Core", makes it all the more important that the
community firmly rejects any further action to force this regression.
* it is my opinion a BIP 8 ST would be an okay compromise under those
circumstances; others do disagree that ST is acceptable at all
> This ensures that for a given known input, the TXIDs can also be known ahead
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched
Channel Creation constructions as the redemption TXID could be malleated and
pre-signed transactions invalidated, unless the channels are built using an
Eltoo-like protocol.
Why is it a problem for them to use an Eltoo-like protocol?
Why not just commit to the txid itself if that's the goal?
>P2SH is incompatible with CHECKTEMPLATEVERIFY
Maybe the CTV opcode should only be defined/enforced within witness scripts?
>nLockTime should generally be fixed to 0 (in the case of a payment tree, only
the *first* lock time is needed to prevent fee-sniping the root)
Your "Congestion Controlled Transactions" example would only make sense with
the spending transaction much later than the "root", and so could benefit
from fee sniping malleability. (In fact, in that example, it would be better
not to commit to locktime at all.)
>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to
simple templates. The structure of CHECKTEMPLATEVERIFY template is such that
the outputs must be known exactly at the time of construction. Based on a
destructuring argument, it is only possible to create templates which expand
in a finite number of steps.
It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get added.
>For example, a exchange's hot wallet might use an address which can
automatically be moved to a cold storage address after a relative timeout.
Wouldn't it make more sense to just have a UTXO both cold+hot can spend, then
throw away the hot key?
>In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make scripts
valid for policy until the new rule is active.
Policy isn't validity, and cannot be dictated by BIPs (or anyone/anything, for
that matter).
Luke

2023-06-07 23:01:32

- reply

📅 Original date posted:2021-12-17
📝 Original message:Bitcoin Knots version 21.2.knots20210629 is now available from:
https://bitcoinknots.org/files/21.x/21.2.knots20210629/
This Long Term Support (LTS) "Steel Rope" release is based on the unchanged
Bitcoin Knots feature set from 2021 June 29th, with only bug fixes and updated
translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v21.2.knots20210629/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211217/40240a62/attachment.sig>

2023-06-07 23:00:33

- reply

📅 Original date posted:2021-11-11
📝 Original message:Bitcoin Knots version 22.0.knots20211108 is now available from:
https://bitcoinknots.org/files/22.x/22.0.knots20211108/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Note that I also plan to release a Long-Term Support 21.2 in the near future,
for users who prefer to minimise new feature risks. If you prefer to use a
LTS branch, I recommend *not* upgrading to 22.x and waiting for 21.2 instead.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v22.0.knots20211108/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211112/6b53e516/attachment.sig>

2023-06-07 22:59:46

- reply

📅 Original date posted:2021-10-03
📝 Original message:All attempts are harmful, no matter the intent, in that they waste
contributors' time that could be better spent on actual development.
However, I do also see the value in studying and improving the review process
to harden it against such inevitable attacks. The fact that we know the NSA
engages in such things, and haven't caught one yet should be a red flag.
Therefore, I think any such a scheme needs to be at least opt-out, if not
opt-in. Please ensure there's a simple way for developers with limited time
(or other reasons) to be informed of which PRs to ignore to opt-out of this
study. (Ideally it would also prevent maintainers from merging - maybe
possible since we use a custom merging script, but what it really needs to
limit is the push, not the dry-run.)
Luke
On Sunday 03 October 2021 09:11:53 Manuel Costa via bitcoin-dev wrote:
> Good morning everyone,
>
> Just wanted to point out a few things for discussion which may or may not
> be obvious:
>
> 1) A simple scheme as described by ZmnSCPxj first can lead way for a
> standardized process where people can excuse their legitimate attempts to
> actually introduce vulnerabilities, where they create the precommit and
> then attempt to introduce the vulnerability. If it goes wrong they have
> plausible deniability by revealing it and possibly saving their reputation.
> 2) A more complex scheme as described by Ryan (from my very rough
> understanding) seems to imply a random selection of team for attempting the
> attack, which might be limiting, since someone willing to do it and with
> enough knowledge to attempt it properly might not be picked.
>
> It seems to me that an ideal process would start from the will to attempt
> it from one person (or group), which then by some process similar to what
> Ryan described will pick at random a team of people to back up his claim to
> be doing it in good faith. With that selection done, the initial person
> would warn and gather from the randomly chosen participants a set of
> signatures for a similar message as described by ZmnSCPxj and only then go
> ahead with the attempt. This way you achieve:
>
> - One person can initiate it at will.
> - Other people (provably chosen at random) are insiders to that information
> and have a shared precommit.
> - You can't not reveal your intent in case it isn't caught, since other
> randomly chosen people are in on it.
> - You can't pick a specific group of people which might be willing to
> collude with you to achieve a similar situation to 1).
>
> Another important consideration is that depending on the size of the team
> to be insiders, we might by chance deplete the relevant pool of outsiders
> which would be adequate for reviewing the specific details of the
> vulnerability being introduced.
>
> Prayank via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> escreveu no
>
> dia sábado, 2/10/2021 à(s) 10:20:
> > This looks interesting although I don't understand few things:
> > > The scheme should include public precommitments collected at ceremonial
> >
> > intervals.
> >
> > How would this work? Can you explain with an example please.
> >
> > > Upon assignment, the dev would have community approval to
> >
> > opportunistically insert a security flaw
> >
> > Who is doing the assignment?
> >
> > --
> > Prayank
> >
> > A3B1 E430 2298 178F
> >
> >
> >
> > Oct 2, 2021, 01:45 by bitcoin-dev at rgrant.org:
> >
> > Due to the uneven reputation factor of various devs, and uneven review
> > attention for new pull requests, this exercise would work best as a
> > secret sortition.
> >
> > Sortition would encourage everyone to always be on their toes rather
> > than only when dealing with new github accounts or declared Red Team
> > devs. The ceremonial aspects would encourage more devs to participate
> > without harming their reputation.
> >
> > https://en.wikipedia.org/wiki/Sortition
> > https://en.wikipedia.org/wiki/Red_team
> >
> > The scheme should include public precommitments collected at
> > ceremonial intervals.
> >
> > where:
> > hash1 /* sortition ticket */ = double-sha256(secret)
> > hash2 /* public precommitment */ = double-sha256(hash1)
> >
> > The random oracle could be block hashes. They could be matched to
> > hash1, the sortition ticket. A red-team-concurrency difficulty
> > parameter could control how many least-significant bits must match to
> > be secretly selected. The difficulty parameter could be a matter of
> > group consensus at the ceremonial intervals, based on a group decision
> > on how much positive effect the Red Team exercise is providing.
> >
> > Upon assignment, the dev would have community approval to
> > opportunistically insert a security flaw; which, when either caught,
> > merged, or on timeout, they would reveal along with the sortition
> > ticket that hashes to their public precommitment.
> >
> > Sortition Precommitment Day might be once or twice a year.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:59:08

- reply

📅 Original date posted:2021-09-09
📝 Original message:https://github.com/bitcoin/libblkmaker/blob/master/blkmaker.c#L172
On Thursday 09 September 2021 12:54:18 Mike Rosset via bitcoin-dev wrote:
> Hello all,
>
> I recently went down the bitcoin protocol rabbit hole. I wanted to use
> GNU guile scheme to experiment with bitcoin. I initially started by
> creating a toy bitcoin miner but I've run into some inconsistencies with
> the documentation found on
> https://en.bitcoin.it/wiki/Getblocktemplate. Namely with creating the
> templates merkle root.
>
> From my understanding a coinbase transaction should have the
> transactions data concatenated before creating the merkle root. But
> getblocktemplate does not have a json cointbasetxn field. So I'm not
> sure how to create a coinbase transaction without that.
>
> I have a test template response data found here.
> https://raw.githubusercontent.com/mrosset/prospect/master/test-suite/data.j
>son and using a modified version of the merkle python reference script found
> on the wiki page. see
> https://github.com/mrosset/prospect/blob/master/scripts/merkle.py . I'm
> able to create a merkle root with the hash
> c5fff939f628a04428c080ed5bd7cd9bc0b4722b2522743049adb18213adf28a but
> that's minus the coinbase transaction.
>
> So far I'm able to replicate this hash using the test data in guile. But
> I'd like to sanitize this so that I'm using a coinbase transaction and
> making sure the python and guile merkle roots match.
>
> In short how do I get the coinbase transaction without the coinbasetxn
> field existing?
>
> Mike
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:55:48

- reply

📅 Original date posted:2021-07-01
📝 Original message:Bitcoin Knots version 0.21.1.knots20210629 is now available from:
https://bitcoinknots.org/files/0.21.x/0.21.1.knots20210629/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v0.21.1.knots20210629/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210701/19d621fb/attachment.sig>

2023-06-07 22:55:31

- reply

📅 Original date posted:2021-06-29
📝 Original message:The only alternative to a split in the problematic scenarios are 1) concede
centralised miner control over the network, and 2) have inconsistent
enforcement of rules by users who don't agree on what the correct rules are,
again leading to centralised miner control over the network.
In other words, in this context, accepting a split between disagreeing users
is the ONLY way Bitcoin can possibly continue as a decentralised currency.
Making that split as clean and well-defined as possible not only ensures the
best opportunity for both sides of the disagreement, but also minimises the
risk that the split occurs at all (since the "losing" side needs to concede,
rather than passively continue the disagreement ongoing after the attempted
protocol change).
Luke
On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
> At least we are now acknowledging that splitting is what it’s about. That’s
> progress.
>
> e
>
> > On Jun 29, 2021, at 01:32, Jorge Timón <jtimon at jtimon.cc> wrote:
> >
> >
> > I think the option of "permanent failure because miners veto" should
> > actually be abandoned. No, I don't think we should avoid splits when
> > possible, I don't think we should avoid splits at all costs.
> >
> >> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud at gmail.com> wrote:
> >> @Luke
> >>
> >> > They can still slow it down.
> >>
> >> Absolutely. However I think that the option of permanent failure is
> >> important. It certainly would be ideal to ensure that enough bitcoin
> >> users support the upgrade *before* releasing it, however realistically
> >> this can never be more than an estimate, and estimates can sometimes be
> >> wildly wrong. It would be unfortunate if miners had a substantially
> >> different estimate of user support than the people putting in the work
> >> to release bitcoin upgrades. Even if upgrades are never released before
> >> it becomes clear that a large supermajority of users want the upgrade,
> >> if miners don't agree with the estimate a harmful chain split could
> >> occur. And I agree with Eric that the goal here is to prevent a chain
> >> split during an upgrade when possible. This includes permanent failure
> >> of an upgrade when there is unexpectedly large miner opposition.
> >>
> >> This of course does not prevent a UASF-style deployment to be done after
> >> an initial failure to deploy occurs. My proposal is essentially a
> >> mechanism to improve upon the speedy-trial idea, allowing for even
> >> speedier releases (than speedy trial) without adding additional risk of
> >> undesired chain splits.
> >>
> >> > [BIP8] already has the trinary state you seem to be describing
> >>
> >> It sounds like you're saying the trinary state of BIP8 is A. Follow the
> >> longest chain, B. Follow the upgrade chain, or C. follow the
> >> non-upgraded chain. I agree. However the trinary state in my proposal is
> >> materially different - it is the signaling itself that is trinary, not
> >> just which chain is being followed. This allows others to know and make
> >> programmatic decisions (in software) based on that signaling. I'm sure
> >> you can agree that does not exist in BIP8.
> >>
> >> > No additional bit is needed, as softforks are coordinated between
> >> > users, NOT miners
> >>
> >> And yet there is miner involvement, as you rightly pointed out. Miners
> >> are needed to set the nVersion in the header. So when you say "no
> >> additional bit is needed", could you please be clearer as to what you
> >> mean? Do you mean that signaling of opposition in a block can be done
> >> without any "additional bit"? Or are you just saying that it is
> >> redundant to consider what miners might be opposing an upgrade?
> >>
> >> @Jorge
> >>
> >> > If different users want different incompatible things... there's no
> >> > way to avoid the split
> >>
> >> I agree. This happened with bcash, and that's fine. It was painful, but
> >> there were a significant amount of users that disagreed, and they have
> >> the chain they want now.
> >>
> >> But we generally all want to avoid a chain split when possible. Because
> >> chain splits have a cost, and that cost can be high, its likely that
> >> many users would rather choose the chain with the most support rather
> >> than choosing the chain with their preferred rules.
> >>
> >> However, the question here is: how do we estimate what fraction of users
> >> wants which rules? We don't have a divining rod to determine with
> >> certainty what users want. We can only make polls of various levels of
> >> inaccuracy. The methods bitcoin has been using is community discussion
> >> and social consensus estimation as well as miner signaling during the
> >> actual deployment period. Neither of these are perfect, but they are
> >> both reasonable enough mechanisms. However, because both of these
> >> mechanisms are very rough estimates of user sentiment, we need to
> >> consider the possibility that sometimes the estimate may be
> >> substantially inaccurate when we design deployment procedures. This
> >> inaccuracy is why we need multiple barriers in place for an upgrade, and
> >> why we need to have higher thresholds of success (require larger
> >> supermajorities in both consensus and miner signaling).
> >>
> >> Developers obviously care about bitcoin and have an incentive (personal
> >> and probably financial) to do it right. And miners have both an
> >> incentive to keep the system healthy, as well as an incentive to mine on
> >> the chain that the economic majority of users is using. But measuring
> >> the consensus of the bitcoin community can be extraordinarily difficult
> >> to do with consistent accuracy, and so I think miner signaling as it has
> >> been used as a second barrier to entry for an upgrade is quite
> >> appropriate.
> >>
> >>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org> wrote:
> >>> I have not objected to anyone splitting. As I said, a split is always
> >>> possible, and of course has been done on a large scale. It is only the
> >>> misleading statements about inherent soft fork “compatibility” and the
> >>> implication that activation without hash power enforcement does not
> >>> create a split that I object to. People who know better should be
> >>> honest about it.
> >>>
> >>> Far too many people have been led to believe there is some sort of
> >>> activation choice with “ensured” equal outcomes (maybe “slowed down”).
> >>> There is only a choice between creating a split and hash power
> >>> enforcement. Soft forks are rule changes, and thereby incompatible -
> >>> unless enforced by majority hash power.
> >>>
> >>> The statements below are grossly misleading and need to be called out
> >>> as such so that people can actually make this decision you speak of.
> >>> This idea that “users” decide the rules is not the question. The
> >>> question is only how to avoid a split. If one does not care he can
> >>> split at any time, no discussion required.
> >>>
> >>> e
> >>>
> >>> > On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>> >
> >>> > If different users want different incompatible things (enough on
> >>> > each side), there's no way to avoid the split. We shouldn't try to
> >>> > avoid such a split.
> >>> > Users decide the rules, not miners nor developers.
> >>> >
> >>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
> >>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> >>
> >>> >> Ultimately there is only one answer to this question. Get majority
> >>> >> hash power support.
> >>> >>
> >>> >> Soft fork enforcement is the same act as any other censorship
> >>> >> enforcement, the difference is only a question of what people want.
> >>> >> Given that there is no collective “we”, those wants differ. Bitcoin
> >>> >> resolves this question of conflicting wants, but it is not a
> >>> >> democracy, it’s a market. One votes by trading.
> >>> >>
> >>> >> If one wants to enforce a soft fork (or otherwise censor) this is
> >>> >> accomplished by mining (or paying others to do so). Anyone can mine,
> >>> >> so everyone gets a say. Mining is trading capital now for more
> >>> >> later. If enough people want to do that, they can enforce a soft
> >>> >> fork. It’s time Bitcoiners stop thinking of miners as other people.
> >>> >> Anyone can mine, and that’s your vote.
> >>> >>
> >>> >> Otherwise, as mentioned below, anyone can start a new coin. But it’s
> >>> >> dishonest to imply that one can do this and all others will surely
> >>> >> follow. This cannot be known, it’s merely a gamble. And it’s one
> >>> >> that has been shown to not always pay off.
> >>> >>
> >>> >> e
> >>> >>
> >>> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
> >>> >>>
> >>> >>> For some definitions of “block”.
> >>> >>>
> >>> >>> Without majority hash power support, activation simply means you
> >>> >>> are off on a chain split. Anyone can of course split off from a
> >>> >>> chain by changing a rule (soft or otherwise) at any time, so this
> >>> >>> is a bit of an empty claim.
> >>> >>>
> >>> >>> Nobody can stop a person from splitting. The relevant question is
> >>> >>> how to *prevent* a split. And activation without majority hash
> >>> >>> power certainly does not “ensure” this.
> >>> >>>
> >>> >>> e
> >>> >>>
> >>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
> >>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> >>>>
> >>> >>>> BIP8 LOT=True just ensures miners cannot block an upgrade
> >>> >>>> entirely. They can still slow it down.
> >>> >>>>
> >>> >>>> It also already has the trinary state you seem to be describing
> >>> >>>> (although perhaps this could be better documented in the BIP):
> >>> >>>> users who oppose the softfork can and should treat the successful
> >>> >>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do
> >>> >>>> not follow a chain with the rules in force.
> >>> >>>>
> >>> >>>> No additional bit is needed, as softforks are coordinated between
> >>> >>>> users, NOT miners (who have no particular say in them, aside from
> >>> >>>> their role as also being users). The miner involvement is only out
> >>> >>>> of necessity (to set the bit in the header, which users coordinate
> >>> >>>> with) and potentially to accelerate activation by protecting
> >>> >>>> upgrade-lagging users.
> >>> >>>>
> >>> >>>> Luke
> >>> >>>>
> >>> >>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
> >>> >>>>>> wrote:
> >>> >>>>>
> >>> >>>>> Given the recent controversy over upgrade mechanisms for the
> >>> >>>>> non-controversial taproot upgrade, I have been thinking about
> >>> >>>>> ways to solve the problems that both sides brought up. In short,
> >>> >>>>> BIP8 LOT=true proponents make the point that lazy miners failing
> >>> >>>>> to upgrade in a timely manner slow down releases of bitcoin
> >>> >>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
> >>> >>>>> that LOT=true can lead to undesirable forks that might cause a
> >>> >>>>> lot of chaos. I believe both points are essentially correct and
> >>> >>>>> have created a proposal
> >>> >>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blo
> >>> >>>>>b/master/b ip-trinary-version-bits.md> for soft fork upgrades that
> >>> >>>>> solve both problems.
> >>> >>>>>
> >>> >>>>> The proposal uses trinary version signaling rather than binary
> >>> >>>>> signaling. For any particular prospective soft fork upgrade, this
> >>> >>>>> allows for three signaling states:
> >>> >>>>>
> >>> >>>>> * Actively support the change.
> >>> >>>>> * Actively oppose the change.
> >>> >>>>> * Not signaling (neither support or oppose). This is the default
> >>> >>>>> state.
> >>> >>>>>
> >>> >>>>> Using this additional information, we can release non-contentious
> >>> >>>>> upgrades much quicker (with a much lower percent of miners
> >>> >>>>> signaling support). For contentious upgrades, miners who oppose
> >>> >>>>> the change are incentivized to update their software to a version
> >>> >>>>> that can actively signal opposition to the change. The more
> >>> >>>>> opposition there is, the higher the threshold necessary to lock
> >>> >>>>> in the upgrade. With the parameters I currently recommended in
> >>> >>>>> the proposal, this chart shows how much support signaling would
> >>> >>>>> be necessary given a particular amount of active opposition
> >>> >>>>> signaling:
> >>> >>>>>
> >>> >>>>> [image: thresholdChart.png]
> >>> >>>>> If literally no one signals opposition, a 60% threshold should be
> >>> >>>>> relatively safe because it is a supermajority amount that is
> >>> >>>>> unlikely to change significantly very quickly (ie if 60% of
> >>> >>>>> miners support the change today, its unlikely that less than a
> >>> >>>>> majority of miners would support the change a year or two from
> >>> >>>>> now), and if no one is signaling opposition, chances are that the
> >>> >>>>> vast majority of the other 40% would also eventually signal
> >>> >>>>> support.
> >>> >>>>>
> >>> >>>>> This both gives an incentive for "lazy" miners to upgrade if they
> >>> >>>>> actually oppose the change while at the same time allowing these
> >>> >>>>> lazy miners to remain lazy without slowing down the soft fork
> >>> >>>>> activation much.
> >>> >>>>>
> >>> >>>>> I think now is the right time to discuss new soft fork upgrade
> >>> >>>>> mechanisms, when there are no pressing soft fork upgrades ready
> >>> >>>>> to deploy. Waiting until we need to deploy a soft fork to discuss
> >>> >>>>> this will only delay things and cause contention again like it
> >>> >>>>> did with taproot.
> >>> >>>>>
> >>> >>>>> I'm very curious to know what people think of this mechanism. I
> >>> >>>>> would appreciate any comments here, or written as github issues
> >>> >>>>> on the proposal repo itself.
> >>> >>>>>
> >>> >>>>> Thanks,
> >>> >>>>> BT
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> bitcoin-dev mailing list
> >>> >>>> bitcoin-dev at lists.linuxfoundation.org
> >>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>> >>
> >>> >> _______________________________________________
> >>> >> bitcoin-dev mailing list
> >>> >> bitcoin-dev at lists.linuxfoundation.org
> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:55:24

- reply

📅 Original date posted:2021-06-26
📝 Original message:BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
still slow it down.
It also already has the trinary state you seem to be describing (although
perhaps this could be better documented in the BIP): users who oppose the
softfork can and should treat the successful signal (whether MASF or UASF) as
invalid, thereby ensuring they do not follow a chain with the rules in force.
No additional bit is needed, as softforks are coordinated between users, NOT
miners (who have no particular say in them, aside from their role as also
being users). The miner involvement is only out of necessity (to set the bit
in the header, which users coordinate with) and potentially to accelerate
activation by protecting upgrade-lagging users.
Luke
On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
> Given the recent controversy over upgrade mechanisms for the
> non-controversial taproot upgrade, I have been thinking about ways to solve
> the problems that both sides brought up. In short, BIP8 LOT=true proponents
> make the point that lazy miners failing to upgrade in a timely manner slow
> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> proponents make the point that LOT=true can lead to undesirable forks that
> might cause a lot of chaos. I believe both points are essentially correct
> and have created a proposal
> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
>ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
>
> The proposal uses trinary version signaling rather than binary signaling.
> For any particular prospective soft fork upgrade, this allows for three
> signaling states:
>
> * Actively support the change.
> * Actively oppose the change.
> * Not signaling (neither support or oppose). This is the default state.
>
> Using this additional information, we can release non-contentious upgrades
> much quicker (with a much lower percent of miners signaling support). For
> contentious upgrades, miners who oppose the change are incentivized to
> update their software to a version that can actively signal opposition to
> the change. The more opposition there is, the higher the threshold
> necessary to lock in the upgrade. With the parameters I currently
> recommended in the proposal, this chart shows how much support signaling
> would be necessary given a particular amount of active opposition
> signaling:
>
> [image: thresholdChart.png]
> If literally no one signals opposition, a 60% threshold should be
> relatively safe because it is a supermajority amount that is unlikely to
> change significantly very quickly (ie if 60% of miners support the change
> today, its unlikely that less than a majority of miners would support the
> change a year or two from now), and if no one is signaling opposition,
> chances are that the vast majority of the other 40% would also eventually
> signal support.
>
> This both gives an incentive for "lazy" miners to upgrade if they actually
> oppose the change while at the same time allowing these lazy miners to
> remain lazy without slowing down the soft fork activation much.
>
> I think now is the right time to discuss new soft fork upgrade mechanisms,
> when there are no pressing soft fork upgrades ready to deploy. Waiting
> until we need to deploy a soft fork to discuss this will only delay things
> and cause contention again like it did with taproot.
>
> I'm very curious to know what people think of this mechanism. I would
> appreciate any comments here, or written as github issues on the proposal
> repo itself.
>
> Thanks,
> BT

2023-06-07 22:53:47

- reply

📅 Original date posted:2021-05-21
📝 Original message:On Friday 21 May 2021 07:56:51 Billy Tetrud via bitcoin-dev wrote:
> These look like relatively well put together documents. However, they seem
> relatively orthogonal to Bitcoin in that they look like protocols that
> build on top of the bitcoin platform but aren't directly related to
> changing how bitcoin operates at its base layer. Am I miss reading these?
BIPs are not limited to the base layer. Anything that coordinates between
Bitcoin software at any layer can use BIPs.

2023-06-07 22:53:29

- reply

📅 Original date posted:2021-05-16
📝 Original message:On Friday 14 May 2021 21:41:23 Michael Fuhrmann via bitcoin-dev wrote:
> Bitcoin should create blocks every 10 minutes in average. So why do
> miners need to mine the 9 minutes after the last block was found? It's
> not necessary.
It increases security, and is unavoidable anyway.
> Problem: How to prevent "pre-mining" in the 9 minutes time window?
You can't.
> Possible ideas for discussion:
>
> - (maybe most difficult) global network timer sending a salted hash time
> code after 9 minutes. this enables validation by nodes.
PoW *is* the global network timer.
> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> high enough) times higher difficulty. so everyone can mine any time but
> before to 9 minutes are up there will be a too high downside. It is more
> efficient to wait then paying high bills. The bitcoin will get a "puls".
There's no timestamp at this stage of consensus.
On Sunday 16 May 2021 18:10:12 Karl via bitcoin-dev wrote:
> The clock might be implementable on a peer network level by requiring
> inclusion of a transaction that was broadcast after a 9 minute delay.
That requires a centralised authority.
On Sunday 16 May 2021 20:31:47 Anton Ragin via bitcoin-dev wrote:
> 1. Has anyone considered that it might be technically not possible to
> completely 'power down' mining rigs during this 'cool-down' period of time?
> While modern CPUs have power-saving modes, I am not sure about ASICs used
> for mining.
That would be miners' problem, not the network's... New ASICs would no doubt
be made to work more efficiently.
> 2. I am not a huge data-center specialist, but it was my understanding that
> they charge per unit of installed (maximum) electricity consumption. It
> would mean that if the miner needs X kilowatts-hour within that 1 minute
> when they are allowed to mine, he/she will have to pay for the same X for
> the remaining 9 minutes - and as such would have no economic incentive not
> to draw that power when idling.
Actually, this would be a good thing: it would heavily discourage datacentre
use (which is very harmful to mining decentralisation).
> 4. My counter-proposal to the community to address energy consumption
> problems would be *to encourage users to allow only 'green miners' process
> their transaction.* In particular:
>...
> (b) Should there be some non-profit organization(s) certifying green miners
> and giving them cryptographic certificates of conformity (either usage of
> green energy or purchase of offsets), users could encrypt their
> transactions and submit to mempool in such a format that *only green miners
> would be able to decrypt and process them*.
Hello centralisation. Might as well just have someone sign miner keys, and get
rid of PoW entirely...

2023-06-07 22:52:32

- reply

📅 Original date posted:2021-05-11
📝 Original message:Is there a list of software impacted by this CVE, and the versions it is fixed
in?
(Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a policy
matter, not part of the consensus rules and never safe to rely on in any
case...)
On Thursday 06 May 2021 13:55:53 Antoine Riard via bitcoin-dev wrote:
> Hi,
>
> I'm writing to report a defect in Bitcoin Core bip125 logic with minor
> security and operational implications for downstream projects. Though this
> defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't
> impacted.
>
> # Problem
>
> Bip 125 specification describes the following signalling mechanism :
>
> "
> This policy specifies two ways a transaction can signal that it is
> replaceable.
>
> * Explicit signaling: A transaction is considered to have opted in to
> allowing replacement of itself if any of its inputs have an nSequence
> number less than (0xffffffff - 1).
>
> * Inherited signaling: Transactions that don't explicitly signal
> replaceability are replaceable under this policy for as long as any one of
> their ancestors signals replaceability and remains unconfirmed.
>
> One or more transactions currently in the mempool (original transactions)
> will be replaced by a new transaction (replacement transaction) that spends
> one or more of the same inputs if,
>
> # The original transactions signal replaceability explicitly or through
> inheritance as described in the above Summary section.
> "
>
> An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an
> unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable as
> the child transaction signals "through inheritance". However, the
> replacement code as implemented in Core's `PreChecks()` shows that this
> behavior isn't enforced and Core's mempool rejects replacement attempts of
> an unconfirmed child transaction.
>
> Branch asserting the behavior is here :
> https://github.com/ariard/bitcoin/commits/2021-03-test-rbf
>
> # Solution
>
> The defect has not been patched.
>
> # Downstream Projects Affected
>
> * LN : State-of-the-art pinning attacks against second-stage HTLCs
> transactions were thought to be only possible by exploiting RBF rule 3 on
> the necessity of a higher absolute fee [0]. However, this replacement
> defect opens the way for an attacker to only pin with an opt-out child
> without a higher fee than the honest competing transaction. This lowers the
> cost of attack as the malicious pinning transaction only has to be above
> mempools'min feerate. This also increases odds of attack success for a
> reduced feerate diminishes odds of confirmation ending the pinning.
>
> A functional test demo illustrating cases is available on this branch:
> https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings
>
> LN nodes operators concerned by this defect might favor anchor outputs
> channels, fully mitigating this specific pinning vector.
>
> * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple
> stages of execution with time-sensitive transactions opening the way to
> pinning attacks. Those protocols being non-deployed or in early phase, I
> would recommend that any in-protocol competing transactions explicitly
> signal RBF.
>
> * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if
> the coinjoin transaction is still laying in network mempools, if a
> fee-bumping output is spendable by any protocol participant, this
> fee-bumping mechanism might be halted by a malicious protocol participant
> broadcasting an low-feerate opt-out child. According to bip125, if the
> coinjoin parent tx signals replaceability, the child transaction should be
> replaceable, whatever its signaling. However Core doesn't apply this
> policy. RBF of the coinjoin transaction itself should be used as a
> fallback. I'm not aware of any deployed coinjoin using such
> "anyone-can-bump" fee-bumping strategy.
>
> * Simple wallets : RBF engines' behaviors might be altered in ways not
> matching the intent of their developers. I invite RBF engines dev to verify
> what those components are doing in the light of disclosed information.
>
> # Discovery
>
> While reviewing the LN dual-funding flow, I inquired on potential new DoS
> vectors introduced by relying on counterparty utxos in this following
> analysis [1]. The second DoS issue "RBF opt-out by a Counterparty
> Double-Spend" is relying on a malicious chain of transactions where the
> parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the
> child, servicing as a pinning transaction, opt-out from the RBF policy.
> This pinning trick conception was matching my understanding of Core code
> but while reading again the specification, I observed that it was
> inconsistent from the inherited signaling mechanism as described in the
> bip's "Summary" section.
>
> After exercising the logic, I did submit the defect to Dave Harding, asking
> confirmation of divergence between Bitcoin Core and BIP 125. Soon after, he
> did confirm it and pointed that the defect has been there since the 2015's
> PR introducing the opt-in RBF, advicing to to consider security
> implications for deployed second-layer protocols. After noticing the minor
> implications for pinning attacks on second-stage LN transactions while
> talking with Matt Corallo, I did disclose to the Bitcoin Core security
> list.
>
> My initial report was recommending avoiding a covert patch in the mempool
> as risks of introducing DoS in this part of the codebase seemed to outweigh
> security of deployed LN channels. This direction was agreed by the opinions
> expressed on the security list. Beyond, there was a lack of agreement on
> how to proceed with the disclosure as so far in the history project,
> transaction relay policy have not been considered as strongly reliable.
> Though from now on, L2 protocols like Lightning are making assumptions on
> subset of this policy for their safety, such as the highlighted RBF one.
>
> Defect was disclosed to the LN projects maintainers, informing them that
> currently in deployment anchor outputs protocol upgrade was mitigating
> against this defect though old channels will stay vulnerable. To the best
> of my knowledge, I didn't identify other deployed protocols of which coins
> safety are impacted by this defect.
>
> # Ecosystem Observations
>
> This long-standing defect with benign security implications provided an
> opportunity to exercise coordinated security disclosure across layers and
> development teams.
>
> IMO, it underlies few interesting points:
> * the lack of an established policy for coordinated security disclosures
> between a base layer implementation and its downstream projects
> * the lack of a clear methodology to identify downstream projects affected
> by a transaction relay policy wreckage
> * the lack of minimally-disruptive, emergency upgrade mechanisms
> implemented by downstream projects [2]
>
> Finally, security implications for downstream projects provoked by base
> layer issues shouldn't be minimized as they do have a risk of windblow on
> base layer operations. I believe we should minimize risks of disaster
> scenarios such as thousands of LN channels manually closed by worried
> operators due to a non-concerted security disclosure, provoking mempool
> cloaks and disrupting regular transactions for a while.
>
> # Timeline
>
> 2021-03-18 : Defect discovered, report to Dave Harding original author of
> bip125, confirmation of the defect
> 2021-03-19 : Disclosure to the Bitcoin Core security list, Dave Harding,
> Matt Corallo, acknowledgment of the issue
> 2021-04-05 : Disclosure to the LN projects maintainers (c-lightning, lnd,
> eclair, electrum, rust-lightning)
> 2021-04-28 : CVE-2021-31876 assigned
> 2021-05-06 : Full disclosure to the bitcoin-dev mailing list
>
> I believe the information reported is correct and reflects the best of my
> knowledge, please point any shortcoming.
>
> Cheers,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639
>.html [1] See "On Mempool Funny Games against Multi-Party Funded
> Transactions", published 2021-05-06
> [2] Such as
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.
>html

2023-06-07 22:52:10

- reply

📅 Original date posted:2021-04-25
📝 Original message:On Sunday 25 April 2021 21:14:08 Matt Corallo wrote:
> On 4/25/21 17:00, Luke Dashjr wrote:
> > I will not become an accomplice to this deception by giving special
> > treatment, and will process the BIP PR neutrally according to the
> > currently-defined BIP process.
>
> Again, please don't play dumb, no one watching believes this - you've been
> active on the BIP repo on numerous PRs and this has never in the past been
> the case.
I started going through PRs a few days ago, in order of "Recently updated" on
GitHub, starting with the least-recent following the last one I triaged a
month ago that hasn't seen activity.. the same as I have been doing month
after month prior to this.
If you don't believe me, feel free to look through the repo history.
Luke

2023-06-07 22:52:09

- reply

📅 Original date posted:2021-04-25
📝 Original message:On Sunday 25 April 2021 20:29:44 Matt Corallo wrote:
> If the BIP editor is deliberately refusing to accept changes which the
> author's approval (which appears to be occurring here),
It isn't. I am triaging BIPs PRs the same as I have for years, and will get to
them all in due time, likely before the end of the month.
Rather, what we have going on is a few bad actors trying to misportray the
BIPs as an approval process so they can pretend ST is somehow official, or
that the preexisting Core+Taproot client is "breaking" the spec. And to
further their agenda, they have been harassing me demanding special
treatment.
I will not become an accomplice to this deception by giving special treatment,
and will process the BIP PR neutrally according to the currently-defined BIP
process.
Despite the continual harassment, I have even made two efforts to try to
(fairly) make things faster, and have been obstructed both times by ST
advocates. It appears they intend to paint me as "deliberately refusing" (to
use your words) in order to try to put Bitcoin and the BIP process under
their control, and abuse it in the same manner in which they abused Bitcoin
Core's usual standards (by releasing ST without community consensus).
Luke

2023-06-07 22:52:03

- reply

📅 Original date posted:2021-04-22
📝 Original message:Unless there are objections, I intend to add Kalle Alm as a BIP editor to
assist in merging PRs into the bips git repo.
Since there is no explicit process to adding BIP editors, IMO it should be
fine to use BIP 2's Process BIP progression:
> A process BIP may change status from Draft to Active when it achieves
> rough consensus on the mailing list. Such a proposal is said to have
> rough consensus if it has been open to discussion on the development
> mailing list for at least one month, and no person maintains any
> unaddressed substantiated objections to it.
A Process BIP could be opened for each new editor, but IMO that is
unnecessary. If anyone feels there is a need for a new Process BIP, we can go
that route, but there is prior precedent for BIP editors appointing new BIP
editors, so I think this should be fine.
Please speak up soon if you disagree.
Luke

2023-06-07 22:52:00

- reply

📅 Original date posted:2021-04-25
📝 Original message:On Wednesday 21 April 2021 04:26:26 Prayank via bitcoin-dev wrote:
> Also since this involves LN, maybe it can just be a LN project instead of
> BIP? Not the best person to comment on what can be a BIP.
Anything that Bitcoin software would benefit in collaboration with other
projects on qualifies.
Lightning itself really should be a series of BIPs.
Luke

2023-06-07 18:30:54

- reply

📅 Original date posted:2021-03-16
📝 Original message:(To reiterate: I do not intend any of this as a NACK of Taproot.)
On Monday 15 March 2021 22:05:45 Matt Corallo wrote:
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> > efforts discouraging address use. If the standard loses the hash, the
> > situation cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at
> least nine years and still haven't solved it.
I think we've made progress over those 9 years, don't you?
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it can
> > be seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> > supply minable by QCs is really no different than 37% minable by ASICs.
> > (We've seen far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of
> supply rather quickly (presumably over the course of a few days, at
> maximum), instead of a slow process with significant upfront real-world
> cost in the form of electricity.
My understanding is that at least initial successes would likely be very slow.
Hopefully we would have a permanent solution before it got too out of hand.
On Monday 15 March 2021 23:01:47 Karl-Johan Alm via bitcoin-dev wrote:
> The important distinction here is that, with hashes, an attacker has
> to race against the spending transaction confirming, whereas with
> naked pubkeys, the attacker doesn't have to wait for a spend to occur,
> drastically increasing the available time to attack.
More importantly, once an attack is recognised, with hashes, people can simply
stop sending transactions and await a fix, to protect their stash. Without
hashes, there is no defense at all (other than sending bitcoins to a
non-taproot address and hoping they evade the attack in time).
On Monday 15 March 2021 23:12:18 Andrew Poelstra wrote:
> "No gain" except to save significant CPU time and bandwidth?
The CPU time is localised to involved nodes, and (correct me if I'm wrong)
trivial in comparison to what is required to run a full node in the first
place. I'm not sure how it looks with bandwidth.
> Having exposed keys also lets you do ring signatures over outputs, creating
> the ability to do private proof of funds via Provisions.
But you can also do comparable proofs behind a hash with Bulletproofs, right?
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> > should be fairly trivial to add a hash on top in an additional softfork
> > and fix this.
>
> This would make Bitcoin strictly worse.
How so? People could just not use it if they don't care, right?
The alternative (if people care enough) is that those concerned about quantum
risk would be forced to forego the benefits of Taproot and stick to p2pkh or
such, which seems like an artificial punishment.
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> > is at risk" argument. This argument is based in part on the fact that
> > many people reuse Bitcoin invoice addresses.
>
> 37% is a dramatic understatement. Every address which is derived using
> BIP32 should be assumed compromised to a QC attacker because xpubs are not
> treated like secret key material and are trivial to e.g. extract from
> hardware wallets or PSBTs. I expect the real number is close to 100%.
xpubs should be treated like secret key material IMO.
A quantum attacker would need to compromise your PC to attack a hardware
wallet, right?
> In any case, Taproot keys, when used according to the recommendation in
> BIP-0341, are already hashes of their internal keys, so (a) Taproot outputs
> actually have better quantum resistance than legacy outputs; and (b) adding
> another hash would be strictly redundant.
It not only stops the attacker from obtaining the original key, but also
prevents creating a new private key that can spend the output?
On Tuesday 16 March 2021 02:38:55 ZmnSCPxj via bitcoin-dev wrote:
> From this point-of-view, it seems to me that the amount of energy to mount
> a "fast" attack may eventually approach the energy required by mining, in
> which case someone who possesses the ability to mount such an attack may
> very well find it easier to just 51% the network (since that can be done
> today without having to pour R&D satoshis into developing practical quantum
> computers).
Mining adapts its difficulty to the block rate, so it will slow you down up to
4x each retarget. An attack on public keys would probably scale better. :)
Luke

2023-06-07 18:30:50

- reply

📅 Original date posted:2021-03-15
📝 Original message:I do not personally see this as a reason to NACK Taproot, but it has become
clear to me over the past week or so that many others are unaware of this
tradeoff, so I am sharing it here to ensure the wider community is aware of
it and can make their own judgements.
Mark Friedenbach explains on his blog:
https://freicoin.substack.com/p/why-im-against-taproot
In short, Taproot loses an important safety protection against quantum.
Note that in all circumstances, Bitcoin is endangered when QC becomes a
reality, but pre-Taproot, it is possible for the network to "pause" while a
full quantum-safe fix is developed, and then resume transacting. With Taproot
as-is, it could very well become an unrecoverable situation if QC go online
prior to having a full quantum-safe solution.
Also, what I didn't know myself until today, is that we do not actually gain
anything from this: the features proposed to make use of the raw keys being
public prior to spending can be implemented with hashed keys as well.
It would use significantly more CPU time and bandwidth (between private
parties, not on-chain), but there should be no shortage of that for anyone
running a full node (indeed, CPU time is freed up by Taproot!); at worst, it
would create an incentive for more people to use their own full node, which
is a good thing!
Despite this, I still don't think it's a reason to NACK Taproot: it should be
fairly trivial to add a hash on top in an additional softfork and fix this.
In addition to the points made by Mark, I also want to add two more, in
response to Pieter's "you can't claim much security if 37% of the supply is
at risk" argument. This argument is based in part on the fact that many
people reuse Bitcoin invoice addresses.
First, so long as we have hash-based addresses as a best practice, we can
continue to shrink the percentage of bitcoins affected through social efforts
discouraging address use. If the standard loses the hash, the situation
cannot be improved, and will indeed only get worse.
Second, when/if quantum does compromise these coins, so long as they are
neglected or abandoned/lost coins (inherent in the current model), it can be
seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply
minable by QCs is really no different than 37% minable by ASICs. (We've seen
far higher %s available for mining obviously.)
To conclude, I recommend anyone using Bitcoin to read Mark's article, my
thoughts, and any other arguments on the topic; decide if this is a concern
to you, and make your own post(s) accordingly. Mark has conceded the argument
(AFAIK he doesn't have an interest in bitcoins anyway), and I do not consider
it a showstopper - so if anyone else out there does, please make yourself
known ASAP since Taproot has already moved on to the activation phase and it
is likely software will be released within the next month or two as things
stand.
Luke

2023-06-07 18:30:48

- reply

📅 Original date posted:2021-03-15
📝 Original message:I am referring to the timeline and recommendation from the meeting on February
16th, which has been slowly making progress toward a release:
https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
The first period from height 693504-695520 here overlaps with the last period
of AChow's ST pull request.
A release today is impossible of course. But 1 or 2 days late is nothing
compared to waiting a week and not having even gotten started. :)
I expect/hope that there will be consensus to adapt around ST, shifting
everything later, but I'm just one person.
roconnor pointed out that the best solution is probably to just enclose ST's
timeline; something like this:
https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/3/files#diff-e43ac101b32b6804209cfdf26da4d122e54b994eb7f1538d4378f6a508dab817L529
Luke
On Monday 15 March 2021 20:59:11 Jeremy wrote:
> Can you expand on the timeline issue? Which timelines are incompatible and
> why?
>
> It does seem like a release done *today* cannot happen anyways, so it
> sounds like it's already too late... or do you mean beginning the release
> process today?
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr <luke at dashjr.org> wrote:
> > While I agree 24 hours is too short notice, if someone wishes to insist
> > on keeping the current timeline, software supporting it should be
> > released _today_. Putting the meeting off a week would almost necessarily
> > imply rejection of any desires to stick to the original plan.
> >
> > So for that reason, I think we need to at least try to have a meeting
> > tomorrow, at least to give anyone who won't agree to such a delay a
> > chance to
> > speak up before it's too late, and have his argument fairly considered.
> >
> > We can still have a meeting next week. The idea of having one every other
> > week
> > seems like a good idea to avoid this in the future, too.
> >
> > Luke
> >
> > On Monday 15 March 2021 19:14:02 Jeremy wrote:
> > > Please announce such meetings with more than ~24 hours notice -- this
> > > has happened several times and while I recognize the pace of
> > > development on this issue I think that slotting a consensus meeting
> > > with less than 24 hours is inappropriate.
> > >
> > > I think we should proactively postpone it a week so that there isn't an
> > > arbitrary "too low turnout" measure and instead anyone who really wants
> >
> > to
> >
> > > be present for the meeting can plan to be.
> > >
> > > So as not to lose momentum on having a discussion, I propose to plan to
> > > hold a general discussion tomorrow at that time and a meeting (with the
> > > intent of resolving issues in a more binding way) next week. It may be
> > > a good idea to hold the time slot every other week for the next while
> > > so
> >
> > that
> >
> > > we can avoid this 24 hour thing altogether.
> > >
> > > It sucks to lose another week but a precedent of 24 hour notice
> > > meetings for non urgent changes is very negative.
> > >
> > > (This isn't any comment on if ST is OK or not -- the schedules proposed
> >
> > for
> >
> > > ST thus far seem acceptable to me)
> > >
> > > Best,
> > >
> > > Jeremy
> > > --
> > > @JeremyRubin <https://twitter.com/JeremyRubin>
> > > <https://twitter.com/JeremyRubin>
> > >
> > >
> > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
> > >
> > > bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > > At the previous meeting, there was consensus for BIP8 activation
> > > > parameters
> > > > except for LOT, assuming a release around this time. Since then, a
> > > > release has not occurred, and the new idea of Speedy Trial has been
> > > > proposed to preempt the original/main activation plan.
> > > >
> > > > It's probably a good idea to meet up again to discuss these things
> > > > and adjust
> > > > accordingly.
> > > >
> > > > Agenda:
> > > >
> > > > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > > > (Note: current draft conflicts with original plan timeline)
> > > >
> > > > - Main activation, post ST: Moving startheight (and timeoutheight?)
> >
> > later
> >
> > > > is probably a good idea at this point, both because too little
> >
> > progress
> >
> > > > has
> > > > been made on it, and to avoid the conflict with the current ST
> > > > draft.
> > > >
> > > > - Making progress: To date, too few people have been involved in
> > > > materialising
> > > > the main activation plan. If it's going to move forward, more
> > > > people need to
> > > > get actively involved. This should not wait for ST to complete,
> >
> > unless
> >
> > > > we want another 4-5 month slip of the timeline.
> > > >
> > > > This meeting is tentatively scheduled for *tomorrow*, March 16th at
> > > > the usual
> > > > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > > > turnout
> > > > is too low, we can postpone it a week, but it'd be nice to get things
> > > > resolved and moving sooner.
> > > >
> > > > As a reminder, the channel is also open for ongoing discussion 24/7,
> >
> > and
> >
> > > > there
> > > > is a web chat client here:
> > > >
> > > > https://webchat.freenode.net/?channel=##taproot-activation
> > > >
> > > > Luke
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev at lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:30:48

- reply

📅 Original date posted:2021-03-15
📝 Original message:While I agree 24 hours is too short notice, if someone wishes to insist on
keeping the current timeline, software supporting it should be released
_today_. Putting the meeting off a week would almost necessarily imply
rejection of any desires to stick to the original plan.
So for that reason, I think we need to at least try to have a meeting
tomorrow, at least to give anyone who won't agree to such a delay a chance to
speak up before it's too late, and have his argument fairly considered.
We can still have a meeting next week. The idea of having one every other week
seems like a good idea to avoid this in the future, too.
Luke
On Monday 15 March 2021 19:14:02 Jeremy wrote:
> Please announce such meetings with more than ~24 hours notice -- this has
> happened several times and while I recognize the pace of development on
> this issue I think that slotting a consensus meeting with less than 24
> hours is inappropriate.
>
> I think we should proactively postpone it a week so that there isn't an
> arbitrary "too low turnout" measure and instead anyone who really wants to
> be present for the meeting can plan to be.
>
> So as not to lose momentum on having a discussion, I propose to plan to
> hold a general discussion tomorrow at that time and a meeting (with the
> intent of resolving issues in a more binding way) next week. It may be a
> good idea to hold the time slot every other week for the next while so that
> we can avoid this 24 hour thing altogether.
>
> It sucks to lose another week but a precedent of 24 hour notice meetings
> for non urgent changes is very negative.
>
> (This isn't any comment on if ST is OK or not -- the schedules proposed for
> ST thus far seem acceptable to me)
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
>
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > At the previous meeting, there was consensus for BIP8 activation
> > parameters
> > except for LOT, assuming a release around this time. Since then, a
> > release has not occurred, and the new idea of Speedy Trial has been
> > proposed to preempt the original/main activation plan.
> >
> > It's probably a good idea to meet up again to discuss these things and
> > adjust
> > accordingly.
> >
> > Agenda:
> >
> > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > (Note: current draft conflicts with original plan timeline)
> >
> > - Main activation, post ST: Moving startheight (and timeoutheight?) later
> > is probably a good idea at this point, both because too little progress
> > has
> > been made on it, and to avoid the conflict with the current ST draft.
> >
> > - Making progress: To date, too few people have been involved in
> > materialising
> > the main activation plan. If it's going to move forward, more people
> > need to
> > get actively involved. This should not wait for ST to complete, unless
> > we want another 4-5 month slip of the timeline.
> >
> > This meeting is tentatively scheduled for *tomorrow*, March 16th at the
> > usual
> > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > turnout
> > is too low, we can postpone it a week, but it'd be nice to get things
> > resolved and moving sooner.
> >
> > As a reminder, the channel is also open for ongoing discussion 24/7, and
> > there
> > is a web chat client here:
> >
> > https://webchat.freenode.net/?channel=##taproot-activation
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:30:47

- reply

📅 Original date posted:2021-03-15
📝 Original message:At the previous meeting, there was consensus for BIP8 activation parameters
except for LOT, assuming a release around this time. Since then, a release
has not occurred, and the new idea of Speedy Trial has been proposed to
preempt the original/main activation plan.
It's probably a good idea to meet up again to discuss these things and adjust
accordingly.
Agenda:
- Speedy Trial: Can we get a comparable consensus on the proposal?
(Note: current draft conflicts with original plan timeline)
- Main activation, post ST: Moving startheight (and timeoutheight?) later
is probably a good idea at this point, both because too little progress has
been made on it, and to avoid the conflict with the current ST draft.
- Making progress: To date, too few people have been involved in materialising
the main activation plan. If it's going to move forward, more people need to
get actively involved. This should not wait for ST to complete, unless we
want another 4-5 month slip of the timeline.
This meeting is tentatively scheduled for *tomorrow*, March 16th at the usual
time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If turnout
is too low, we can postpone it a week, but it'd be nice to get things
resolved and moving sooner.
As a reminder, the channel is also open for ongoing discussion 24/7, and there
is a web chat client here:
https://webchat.freenode.net/?channel=##taproot-activation
Luke

2023-06-07 18:30:32

- reply

📅 Original date posted:2021-03-15
📝 Original message:The last period before timeoutheight here overlaps with the current BIP8(True)
deployment plan. So if this period specifically were to reach 90% signalling,
nodes would activate Taproot at height 697536, but ST-only nodes would still
wait until 709632 instead.
Probably the best solution is to just move this ST window 1 period earlier?
Luke
On Saturday 06 March 2021 06:04:22 Andrew Chow via bitcoin-dev wrote:
> I like this idea.
>
> In terms of actual parameters, I propose that we base this Speedy Trial
> off of BIP 8 with the following parameters:
> * start height = 681408
> * timeout height = 695520
> * lockinontimeout = False
> * signaling bit = 2
> * threshold = 1815/2016 blocks (90%)
>
> For the extended lockin period, I propose 14112 blocks, which is 7
> retarget periods. Thus the earliest activation height will be 697536 and
> the latest activation height will be 709632.
>
> This will give us an approximate start time of May 1st 2021 and an
> approximate timeout time of August 7th 2021, for a total activation
> period of just over 3 months. The extended lockin period is the same
> number of blocks as the activation period so that will also be just over
> 3 months, giving us the latest activation time of November 13th, 2021.
> If miners activated as soon as possible, the earliest activation time
> would be August 21st 2021.
>
> Additionally, this timeline assumes a mid-April release of Bitcoin Core
> 0.21.1 containing these parameters. They could be changed to move up if
> the expected release date were sooner.
>
>
> Andrew Chow
>
> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
> > On the ##taproot-activation IRC channel, Russell O'Connor recently
> > proposed a modification of the "Let's see what happens" activation
> > proposal.[1] The idea received significant discussion and seemed
> > acceptable to several people who could not previously agree on a
> > proposal (although this doesn't necessarily make it their first
> > choice). The following is my attempt at a description.
> >
> > 1. Start soon: shortly after the release of software containing this
> > proposed activation logic, nodes will begin counting blocks towards
> > the 90% threshold required to lock in taproot.[2]
> >
> > 2. Stop soon: if the lockin threshold isn't reached within approximately
> > three months, the activation attempt fails. There is no mandatory
> > activation and everyone is encouraged to try again using different
> > activation parameters.
> >
> > 2. Delayed activation: in the happy occasion where the lockin threshold
> > is reached, taproot is guaranteed to eventually activate---but not
> > until approximately six months after signal tracking started.
> >
> > ## Example timeline
> >
> > (All dates approximate; see the section below about BIP9 vs BIP8.)
> >
> > - T+0: release of one or more full nodes with activation code
> > - T+14: signal tracking begins
> > - T+28: earliest possible lock in
> > - T+104: locked in by this date or need to try a different activation
> > process - T+194: activation (if lockin occurred)
> >
> > ## Analysis
> >
> > The goal of Speedy Trial is to allow a taproot activation attempt to
> > either quickly succeed or quickly fail---without compromising safety in
> > either case. Details below:
> >
> > ### Mitigating the problems of early success
> >
> > New rules added in a soft fork need to be enforced by a large part of
> > the economy or there's a risk that a long chain of blocks breaking the
> > rules will be accepted by some users and rejected by others, causing a
> > chain split that can result in large direct losses to transaction
> > receivers and potentially even larger indirect losses to holders due to
> > reduced confidence in the safety of the Bitcoin system.
> >
> > One step developers have taken in the past to ensure widespread adoption
> > of new consensus rules is programming in a delay between the time
> > software with those rules is expected to be released and when the
> > software starts tracking which blocks signal for activation. For
> > example:
> >
> > Soft fork | Release | Start | Delta
> > -----------------+------------+------------+----------
> > BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
> > BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
> >
> > Sources: BitcoinCore.org,
> > https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
> >
> > Speedy Trial replaces most of that upfront delay with a backend delay.
> > No matter how fast taproot's activation threshold is reached by miners,
> > there will be six months between the time signal tracking starts and when
> > nodes will begin enforcing taproot's rules. This gives the userbase even
> > more time to upgrade than if we had used the most recently proposed start
> > date for a BIP8 activation (~July 23rd).[2]
> >
> > ### Succeed, or fail fast
> >
> > The earlier version of this proposal was documented over 200 days ago[3]
> > and taproot's underlying code was merged into Bitcoin Core over 140 days
> > ago.[4] If we had started Speedy Trial at the time taproot
> > was merged (which is a bit unrealistic), we would've either be less than
> > two months away from having taproot or we would have moved on to the
> > next activation attempt over a month ago.
> >
> > Instead, we've debated at length and don't appear to be any closer to
> > what I think is a widely acceptable solution than when the mailing list
> > began discussing post-segwit activation schemes over a year ago.[5] I
> > think Speedy Trial is a way to generate fast progress that will either
> > end the debate (for now, if activation is successful) or give us some
> > actual data upon which to base future taproot activation proposals.
> >
> > Of course, for those who enjoy the debate, discussion can continue while
> > waiting for the results of Speedy Trial.
> >
> > ### Base activation protocol
> >
> > The idea can be implemented on top of either Bitcoin Core's existing
> > BIP9 code or its proposed BIP8 patchset.[6]
> >
> > - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
> > these values plus a time-based parameter for the minimum activation
> > delay would give three months for miners to activate taproot, but some
> > of that time near the start or the end might not be usable due to
> > signals only being measured in full retarget periods. However, the
> > six month time for users to upgrade their node would be not be
> > affected by either slow or fast block production.
> >
> > BIP9 is already part of Bitcoin Core and I think the changes being
> > proposed would be relatively small, resulting in a small patch that
> > could be easy to review.
> >
> > - BIP8 uses two height-based parameters, startheight and timeoutheight.
> > Using height values would ensure miners had a certain number of
> > retarget periods (6) to lock in taproot and that there'd be a certain
> > number of blocks (about 24,000) until activation, although latest lock
> > in and expected activation could occur moderately earlier or later
> > than the estimated three and six months.
> >
> > BIP8 would likely be used if Speedy Trial fails, so it could be
> > advantageous to base this proposal on BIP8 so that we gain
> > experience running that code in production.
> >
> > For additional discussion about using times versus heights, see today's
> > log for ##taproot-activation.[11]
> >
> > ### Additional concerns
> >
> > - Encourages false signaling: false signaling is when miners signal
> > readiness to enforce rules that their nodes don't actually support.
> > This was partially responsible for a six-block reorg shortly after the
> > final BIP66 activation[8] and was found to still be a problem during
> > the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
> >
> > Because Speedy Trial only gives miners a maximum of three months to
> > signal support for taproot, it may encourage such false signaling. If
> > taproot locks in as a result of their signaling but most of them fail
> > to upgrade by the activation date several months later, unprepared
> > miners could lose large amounts of money and users could see long
> > reorgs (with unupgraded nodes and SPV lite clients potentially losing
> > money).
> >
> > Compared to other activation proposals, I think the only difference is
> > Speedy Trial's short timeline. False signaling is possible with any
> > other proposal and the same problems can occur if miners fail to
> > upgrade for any mandatory activation.
> >
> > ### Additional advantages
> >
> > - No mandatory signaling: at no time are miners required to signal by
> > Speedy Trial. This includes no mandatory signaling during the
> > locked_in period(s), although such signaling will be encouraged (as it
> > was with BIP9[10]).
> >
> > - Party time: to a lesser degree, a benefit mentioned for flag day
> > activation may also apply here: we could get up to six months
> > advanced notice of taproot activation, allowing users, developers, and
> > organizations to prepare software, announcements, and celebrations for
> > that event.
> >
> > ## Implementation details and next steps
> >
> > Initial discussion about implementation may be found in today's
> > ##taproot-activation log.[11] If it appears Speedy Trial may have
> > traction, Russell O'Connor has offered to work on a patch against BIP8
> > implementing it.
> >
> > ## Acknowledgments
> >
> > The original idea for a short-duration attempt was discussed in the
> > ##taproot-activation IRC channel last July and the revised idea saw
> > additional evaluation there this week. Despite growing frustration,
> > discussion has been overwhelmingly constructive, for which all the
> > contributors should be commended. Although this should not in any way
> > imply endorsement, I'm grateful for the review and comments on a draft
> > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> > Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> > O'Connor, and IRC users maybehuman and proofofkeags
> >
> > ## Footnotes
> >
> > [1]
> > https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see
> >_what_happens.2C_BIP8.28false.2C_3m.29
> >
> > [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
> > seemed to have near-universal support during the 2021-02-16 IRC
> > meeting. See:
> > https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> >
> > [3]
> > https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldi
> >d=68062
> >
> > [4] https://github.com/bitcoin/bitcoin/pull/19953
> >
> > [5]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0175
> >47.html
> >
> > [6] https://github.com/bitcoin/bitcoin/pull/19573
> >
> > [7] BIP9's times are based on the median of the past 11 blocks, which
> > usually trails UTC by about 90 minutes but which can trail behind
> > realtime significantly if miners are doing weird things.
> >
> > [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
> >
> > [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
> >
> > [10]
> > https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf
> >9348f3a/src/test/versionbits_tests.cpp#L337-L339
> >
> > [11] http://gnusha.org/taproot-activation/2021-03-05.log
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:59

- reply

📅 Original date posted:2021-03-05
📝 Original message:On Friday 05 March 2021 14:51:12 Ryan Grant via bitcoin-dev wrote:
> On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
>
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > So that leads me to believe here that the folks who oppose LOT=true
> > primarily have an issue with forced signaling, which personally I
> > don't care about as much, not the idea of committing to a UASF from
> > the get go.
>
> The biggest disconnect is between two goals: modern soft-fork
> activation's "Don't (needlessly) lose hashpower to un-upgraded
> miners"; and UASF's must-signal strategy to prevent inaction.
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547
>.html
>
> This question dives to the heart of Bitcoin's far-out future.
> Of two important principles, which principle is more important:
>
> - to allow everyone (even miners) to operate on the contract they
> accepted when entering the system; or
There was never any such a contract. Even full nodes must upgrade in a
softfork, or they lose their security and become comparable to light wallets.
> - to protect against protocol sclerosis for the project as a whole?
What?
> Do miners have a higher obligation to evaluate upgrades than economic
> nodes implementing cold storage and infrequent spends? If they do,
> then so far it has been implicit. LOT=true would make that obligation
> explicit.
Miners either make valid blocks or they don't.
The only thing they "need" to evaluate is the market for their work.
Luke

2023-06-07 18:29:47

- reply

📅 Original date posted:2021-03-02
📝 Original message:On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote:
> I'm realizing that a clear advantage of LOT=false is that it can happen
> without the need for a social movement. All that is really needed is the
> convincing of 95% miners. Apathetic users will never notice any kind of
> service disruption no matter the success or failure of the activation. This
> is obviously why it naturally became the default activation method.
No. Miners enforcing rules without the social support is a 51% attack, not a
softfork.
> While LOT=true, on the other hand, must be able to 51% the blockchain to
> win the apathetic users. But then the reorgs will not be pretty. Or if it
> ever clearly gets over the 51% hurdle then all apathetic users now need to
> scramble to use the rogue client to be safe from reorgs. Either way it's
> disruptive.
No, LOT=True doesn't do this. It only happens if miners choose to create an
invalid chain, which they could do at any time with or without a softfork
involved.
Luke

2023-06-07 18:29:22

- reply

📅 Original date posted:2021-02-28
📝 Original message:(Note: I am writing this as a general case against LOT=False, but using
Taproot simply as an example softfork. Note that this is addressing
activation under the assumption that the softfork is ethical and has
sufficient community support. If those criteria have not been met, no
activation should be deployed at all, of any type.)
As we saw in 2017 with BIP 9, coordinating activation by miner signal alone,
despite its potential benefits, also leaves open the door to a miner veto.
This was never the intended behaviour, and a bug, which took a rushed
deployment of BIP148 to address. LOT=False would reintroduce that same bug.
It wouldn't be much different than adding back the inflation bug
(CVE-2018-17144) and trusting miners not to exploit it.
Some have tried to spin LOT=True as some kind of punishment for miners or
reactive "counter-attack". Rather, it is simply a fallback to avoid
regression on this and other bugs. "Flag day" activation is not fundamentally
flawed or dangerous, just slow since everyone needs time to upgrade.
BIP 8(LOT=True) combines the certainty of such a flag day, with the speed
improvement of a MASF, so that softforks can be activated both reasonably
quick and safely.
In the normal path, and that which BIP8(True) best incentivises, miners will
simply upgrade and signal, and activation can occur as soon as the economic
majority is expected to have had time to upgrade. In the worst-case path, the
behaviour of LOT=True is the least-harmful result: unambiguous activation and
enforcement by the economy, with miners either deciding to make an
anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners
revolt against the softfork, the LOT=True nodes are simply faced with a
choice to hardfork (replacing the miners with a PoW change) or concede - they
do not risk vulnerability or loss.
With LOT=False in the picture, however, things can get messy: some users will
enforce Taproot(eg) (those running LOT=True), while others will not (those
with LOT=False). Users with LOT=True will still get all the safety thereof,
but those with LOT=False will (in the event of miners deciding to produce a
chain split) face an unreliable chain, being replaced by the LOT=True chain
every time it overtakes the LOT=False chain in work. For 2 weeks, users with
LOT=False would not have a usable network. The only way to resolve this would
be to upgrade to LOT=True or to produce a softfork that makes an activated
chain invalid (thereby taking the anti-Taproot path). Even if nobody ran
LOT=True (very unlikely), LOT=False would still fail because users would be
faced with either accepting the loss of Taproot(eg), or re-deploying from
scratch with LOT=True. It accomplishes nothing compared to just deploying
LOT=True from the beginning. Furthermore, this process creates a lot of
confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I have
to do it AGAIN?"), and in some scenarios additional code may be needed to
handle the subsequent upgrade cleanly.
To make matters worse for LOT=False, giving miners a veto also creates an
incentive to second-guess the decision to activate and/or hold the activation
hostage. This is a direct result of the bug giving them a power they weren't
intended to have. Even if we trust miners to act ethically, that does not
justify sustaining the bug creating both a possibility and incentive to
behave unethically.
So in all possible scenarios, LOT=False puts users and the network at
significant risk. In all possible scenarios, LOT=True minimises risk to
everyone and has no risk to users running LOT=True.
The overall risk is maximally reduced by LOT=True being the only deployed
parameter, and any introduction of LOT=False only increases risk probability
and severity.
For all these reasons, I regret adding LOT as an option to BIP 8, and think it
would be best to remove it entirely, with all deployments in the future
behaving as LOT=True. I do also recognise that there is not yet consensus on
this, and for that reason I have not taken action (nor intend to) to remove
LOT from BIP 8. However, the fact remains that LOT=False should not be used,
and it is best if every softfork is deployed with LOT=True.
Luke

2023-06-07 18:29:17

- reply

📅 Original date posted:2021-02-28
📝 Original message:On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> many individuals are committing themselves to running
> incompatible consensus rules.
Yet that is exactly what you propose herein...
> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022.
Concept NACK. This still has the same problems BIP149 would have had, as I
just reminded in my last email to this ML:
1) Such a chain does not indicate activation at all, leaving it unresolved and
debatable whether activation has occurred or not.
2) As a result, it is also impractical to intentionally reject the softfork
should anyone decide to do so.
Signalling is important to activation.
> 2) The high node-level-adoption bar is one of the most critical goals, and
> the one most currently in jeopardy in a BIP 8 approach.
It is only jeopardized if people continue to push for a LOT=False deployment
(or this new proposal of yours).
BIP 8 itself, with LOT=True, does not create such a risk at all.
> Users demanding alternative consensus rules (or, worse, configuration flags
> to change consensus rules on individual nodes with an expectation of use)
> makes this very complicated in the context of BIP 8.
Alternative consensus rules is exactly what you are proposing here.
More alternative rules to choose from just increase the risks. Two options is
annoying, but adding a third for no reason is just absurd.
Luke

2023-06-07 18:29:11

- reply

📅 Original date posted:2021-02-27
📝 Original message:This has the same problems BIP149 did: since there is no signalling, it is
ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF
nodes will remain on the same chain, with conflicting perceptions of the
rules, and resolution (if ever) will be chaotic. Absent resolution, however,
there is a strong incentive not to rely on the rules, and thus it may never
get used, and therefore also never resolved.
Additionally, it loses the flexibility of BIP 8 to, after the initial
deployment, move the timeoutheight sooner.
Luke
On Thursday 25 February 2021 22:33:25 Gregorio Guidi via bitcoin-dev wrote:
> Hello,
>
> I followed the debate on LOT=false / LOT=true trying to get a grasp of
> the balance of risks and advantages. The summary by Aaron van Wirdum [1]
> explains well the difficulties to find a good equilibrium... it
> concludes that "perhaps, a new possibility will present itself".
>
> Thinking about such a "new possibility" that overcomes the
> LOT=true/false dichotomy, I would like to offer the following proposal.
> It could be called "decreasing threshold activation".
>
> Decreasing threshold activation works similarly to BIP8, with the
> difference that the threshold that triggers the STARTED -> LOCKED_IN
> transition starts at 100% for the first retargeting period, and then is
> gradually reduced on each period in steps of 24 blocks (~1,2%). More
> precisely:
>
> On the 1st period (starting on start_height): if 2016 out of 2016 blocks
> signal, the state is changed to LOCKED_IN on the next period (otherwise
> stays STARTED)
> On the 2nd period: if 1992 out of 2016 blocks signal (~98.8%), the state
> transitions to LOCKED_IN on the next period
> On the 3rd period: if 1968 out of 2016 blocks signal (~97.6%), the state
> transitions to LOCKED_IN on the next period
> ...
> On the 14th period (~6 months): if 1704 out of 2016 blocks signal
> (~84.5%), the state transitions to LOCKED_IN on the next period
> ...
> On the 27th period (~12 months): if 1392 out of 2016 blocks signal
> (~69.0%), the state transitions to LOCKED_IN on the next period
> ...
> On the 40th period (~18 months): if 1080 out of 2016 blocks signal
> (~53.6%), the state transitions to LOCKED_IN on the next period
> ...
> On the 53th period (~24 months): if 768 out of 2016 blocks signal
> (~38.1%), the state transitions to LOCKED_IN on the next period
> ...
> On the 66th period (~30 months): if 456 out of 2016 blocks signal
> (~22.6%), the state transitions to LOCKED_IN on the next period
> ...
> On the 79th period (~36 months): if 144 out of 2016 blocks signal
> (~7.1%), the state transitions to LOCKED_IN on the next period
> ...
> On the 84th and final period (~39 months): if 24 out of 2016 blocks
> signal (~1.2%), the state transitions to LOCKED_IN on the next period,
> otherwise goes to FAILED
>
> (For reference, I include below a snippet of pseudocode for the
> decreasing thresholds in the style of BIP8 and BIP9.)
>
> Here are the main features and advantages of this approach:
>
> 1. It is relatively conservative at the beginning: for activation to
> happen in the first year, it requires a clear majority of signaling
> hashrate, indicating that the activation is relatively safe. Only later
> the threshold starts to move towards "unsafe" territory, accepting the
> tradeoff of less support from existing hashrate in exchange for ensuring
> that the activation eventually happens.
>
> 2. Like LOT=true, the activation will always occur in the end (except in
> the negligible case where less than 1.2% of hashrate supports it).
>
> 3. This approach is quite easy to implement, in particular it avoids the
> extra code to deal with the MUST_SIGNAL period.
>
> 4. There are no parameters to set (except startheight). I am a KISS fan,
> so this is a plus for me, making the activation mechanism robust and
> predictable with less chance for users to shoot themselves in the foot.
> It is also a plus for me that - if adopted as the default mechanism - it
> would require very little discussion on how to activate future
> soft-forks. In fact I think it would be a winning move for Core to
> commit to such a scheme, to avoid getting lost in game-theoretic rabbit
> holes.
>
> 5. Since there is no MUST_SIGNAL period, no automatic chain split occurs
> around activation when not all miners have upgraded (so activation is
> generally as benign as a MASF). A chain split will occur only when/if an
> invalid block is created (and this requires dedicated effort! it can
> only happen by circumventing the normal policy rules [2]). This
> mitigates the risk of reorgs and involuntary forks around activation,
> even with low miner signaling.
>
> 6. It removes motivation to create UASF clients that force activation.
> While individual nodes could still try to force a quicker activation,
> the motivation to do so is reduced since the same result is obtained
> just by waiting a little more.
>
> 7. Compared to LOT=true, activation is cleaner and quicker when it is
> relatively safe to do so (when the signaling hashrate is - let's say -
> in the 70%-80% range). On the other hand, activation is pushed further
> and further in time when it is less safe (when signaling hashrate is
> <50%, meaning that there is a serious risk that users/miners that did
> not upgrade start following an alternative chain). This gives everyone
> time to prepare properly for such a potentially disruptive event.
>
> 8. If a significant number of users and miners consciously decide (for
> whatever reasons) that they don't want to upgrade and want to fork
> themselves off from the chain followed by Core (as is their
> prerogative), they will have time to do so safely.
>
> 9. Compared to the strategy of doing LOT=false and then LOT=true if it
> fails, using the decreasing threshold approach may not seem very
> different. But it completely removes the need to fiddle with different
> client releases and with the issues associated with deployed nodes with
> different consensus parameters.
>
> All in all, reading the various perspectives on this mailing list and
> outside I have the feeling that the strongest arguments against LOT=true
> have at their core a certain uneasiness with the MUST_SIGNAL mechanism
> and the related automatic chain split on activation, which is something
> that greatly complicates the analysis (but please tell me if I am
> wrong...). In this sense, this proposal achieves the big objective of
> always ending in activation (like LOT=true) without resorting to
> MUST_SIGNAL and chain splits.
>
> A final note: this proposal should be seen as somewhat independent from
> the discussion on taproot activation. Personally I would be happy with a
> LOT=false activation for taproot that succeeds quickly, while the
> decreasing threshold approach could be evaluated as potential default
> activation mechanism for the future.
>
> I would be happy to hear what you think about this. What are the
> possible issues/drawbacks of using this mechanism?
>
> Thanks,
>
> Gregorio
>
> [1]
> https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-h
>urdle-before-taproot-activation
>
> [2] This was not the case in the past for upgrades such as BIP16 (P2SH),
> which generated frequent reorgs due to a combination of low activation
> threshold (55%) and no policy protection. But for upgrades such as
> taproot the normal policy rules prevent the creation of invalid blocks
> by non-upgraded miners. See
> https://blog.bitmex.com/the-arts-of-making-softforks-protection-by-policy-r
>ule/
>
> Pseudocode:
>
> case STARTED:
> int elapsed_periods = (block.height - startheight) / 2016;
> if (elapsed_periods > 2016 / 24) {
> return FAILED;
> }
> int threshold = 2016 - 24 * (elapsed_periods - 1);
> int count = 0;
> walk = block;
> for (i = 0; i < 2016; i++) {
> walk = walk.parent;
> if (walk.nVersion & 0xE0000000 == 0x20000000 &&
> (walk.nVersion >> bit) & 1 == 1) { ++count;
> }
> }
> if (count >= threshold) {
> return LOCKED_IN;
> }
> return STARTED;
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:28:26

- reply

📅 Original date posted:2021-02-28
📝 Original message:Answering the F1-F7 arguments for LOT=False...
> F1) The probability of Taproot not being activated by miners is small. This
> is not 2017, this is not SegWit, there is no need to worry.
While we believe miners have no reason to sabotage Taproot activation, this
was also the belief leading up to Segwit’s activation in 2017, and regardless
it is not desirable to create such a risk forcing the community to place
extra trust in miners. Miners might very well not exploit an inflation bug,
but that is no reason to purposefully add an inflation bug.
> F2) The worst case scenario is we have to wait over a year for Taproot to
> be activated. Even the worst case scenario is not a disaster.
While it is true that a second activation can be deployed in the event of the
first one failing, doing so would not necessarily change the situation unless
LOT were changed to true anyway - in which case, it might as well be true for
the initial deployment as well. Furthermore, a re-deployment could create a
situation where users believe they have already upgraded for Taproot, but do
not enforce it due to not understanding the need to upgrade yet again.
> F3) If in the unlikely scenario miners did not activate Taproot for a year
> for no apparent reason we would never set LOT to false again for any
> potential future soft fork. If miners fail to activate Taproot despite
> pledging support and there being overwhelming community consensus for it,
> it would set a precedent that miners cannot be relied upon *at all* to
> activate soft forks.
Setting LOT=false with a threat to change it to true later is antagonistic
against miners. With LOT=true, expectations are simply made clear and miners
can simply cooperate by making valid blocks as they do day-to-day already.
> F4) If in the highly unlikely scenario that a bug or some problem with the
> Taproot implementation was found during the signaling period miners could
> choose not to activate it which is cleaner than needing an emergency Core
> release.
The risk that a bug in Taproot is discovered this late yet before activation,
to warrant aborting the deployment, is extremely low (much lower than the
risks created by LOT=false). Even if such a scenario occurred, and even with
LOT=false, users would still need to upgrade to back out the deployment. In
the best-case scenario, users would need to upgrade to deploy the fixed
Taproot. So in the end, nothing is to be gained from relying on a miner abort
for such scenarios.
> F5) LOT = false is more similar to what was done previously (unless you go
> way back to the earliest soft forks which were more similar to LOT = true)
The behaviour of LOT=false has proven problematic and caused failure of Segwit
activation in 2017. LOT=true behaviour has a long history of success, and was
used to resolve and activate Segwit in 2017 after LOT=false’s failure.
> F6) It is more important that no rules that harm users are deployed than it
> is that new useful rules are deployed quickly. If there is a choice between
> “faster” and “more clear that this isn’t a mechanism to force bad things on
> users” we should prefer the latter. Plenty of people just don’t like
> LOT=true very much absent evidence that miners are blocking deployment. To
> some it just feels needlessly antagonistic and distrusting towards part of
> our community.
Any deployment, or even status quo, can be falsely portrayed/spun in a way to
harm Bitcoin. As such, only objective criteria should be considered.
BIP 8 makes it explicitly easy for people to reject the softfork if they don't
like it, so any claim of being "forced" is a non-starter to an honest person.
> F7) defaulting to LOT=false makes non-activation possible even if people
> run the code that developers provide, meaning a successful
> activation proves that at least some people (e.g. miners or UASFers)
> voluntarily took actions that were well outside the scope of
> developer control.
>
> This makes it clear that developers don't control changes to the
> system. There are other arguments that demonstrate that developers
> aren't in control[1], but they aren't as clear as simply pointing
> out that a rule change won't go into effect until at least several
> non-developers independently act of their own accord.
>
> Having such a clear argument that developers aren't in control
> bolsters the decentralized ethos of Bitcoin and reduces the chance
> that bad actors will pressure Bitcoin developers to attempt future
> unwanted changes.
Even if developers release software, it must still be accepted by the
community in the form of actively choosing to run the software which includes
the activation. So long as the activation is clearly and prominently
documented, users have taken the action to accept the protocol change.
Furthermore, the community has already demonstrated a clear and undisputed
support for the activation of Taproot. If there was/is any question of
whether that is true or not, it is premature to be planning activation of ANY
type.
Luke

2023-06-07 18:28:19

- reply

📅 Original date posted:2021-02-01
📝 Original message:Bitcoin Knots version 0.21.0.knots20210130 is now available from:
https://bitcoinknots.org/files/0.21.x/0.21.0.knots20210130/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v0.21.0.knots20210130/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210201/78dfe7a2/attachment.sig>

2023-06-07 18:27:54

- reply

📅 Original date posted:2020-12-23
📝 Original message:1) People should not be encouraged to write or use web browsers for their
wallet.
2) You may want to look over earlier work in this area.
On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote:
> Hi
>
> This is a first draft of a BIP we intend to submit. The main intention is
> to define a simple interface that wallets and applications can agree on
> that would cover the vast majority of use cases. This can enable writing
> bitcoin applications (e.g. time lock, multi sig) on the web that can be
> seamlessly used with any compatible wallets. We have implementations of
> such examples but I don't want to turn this thread into a promotion and
> rather focus on the spec.
>
> Appreciate input from the list. Please share if there are existing efforts,
> relevant specs or use cases.
>
> ------------------------------
>
> A wallet interface specification for bitcoin applications
>
> ## Abstract
>
> This BIP describes an API for Bitcoin wallets and applications as a
> standard.
>
> ## Summary
>
> Bitcoin wallets should expose their address derivation and signing
> functions to external applications. The interface would be expressed as
> follows in javascript:
>
> ```
> {
> // Wallet Metadata
> wallet: {
> name: 'Bitcoin Core'
> },
>
> // Request access to the wallet for the current host
> async enable: (),
>
> // Request addresses and signatures from wallet
> async request ({ method, params })
> }
> ```
>
> In the web context the interface could be exposed at the top level of a
> webpage, for example under `window.bitcoin`. However this spec does not
> intend to define any standards for how and where the interfaces should be
> exposed.
>
> ## Motivation
>
> Due to the seldom available APIs exposed by wallets, applications (web or
> otherwise) are limited in how they are able to interact. Generally only
> simple sends have been available. A more robust API that introduces other
> requests will promote richer Bitcoin applications.
>
> Additionally, wallet APIs have frequently included inconsistencies in their
> interfaces and behaviour. This has required applications to build and
> maintain a separate client for each wallet, increasing the risk of bugs and
> unintended behaviour as well as being a limiting factor for the adoption of
> usable bitcoin applications.
>
> With a standardised wallet API:
>
> - Wallets have a clear API to implement
> - Applications have a clear expectation of wallet interface and behaviour
> - Applications become agnostic to the wallet specifics, increasing choice
> for users
>
> If more wallets implement the specification, applications will be developed
> more confidently by benefiting from the wallet interoperability. This
> creates a positive feedback loop.
>
> ## Specification
>
> For simplicity, the interface is defined in the context of web applications
> running in the browser (JS) however, they are simple enough to be easily
> implemented in other contexts.
>
> ### General Rules
>
> - For sensitive functions (e.g. signing), wallet software should always
> prompt the user for confirmation
>
> ### Types
>
> **UserDeniedError**
> An error type indicating that the application's request has been denied by
> the user
> Type: Error
>
> **Hex**
> Type: String
> Example:
> `"0000000000000000000a24677957d1e50d70e67c513d220dbe8868c4c3aefc08"`
>
> **Address**
> Address details
> Type: Object
> Example:
>
> ```
> {
> "address": "bc1qn0fqlzamcfuahq6xuujrq08ex7e26agt20gexs",
> "publicKey":
> "02ad58c0dced71a236f4073c3b6f0ee27dde6fe96978e9a9c9500172e3f1886e5a",
> "derivationPath": "84'/1'/0'/0/0"
> }
> ```
>
> ### API
>
> The wallet must implement the following methods.
>
> **enable**
>
> The enable call prompts the user for access to the wallet.
>
> If successful, it resolves to an address (`**Address**` type) of the
> wallet. Typically the first external address to be used as an identity.
>
> **`UserDeniedError`** will be thrown if the request is rejected.
>
> **request**
>
> The request method must take one parameter in the following format:
>
> ```
> {
> "method": "wallet_methodName",
> "params": ["foo", "bar", "baz"]
> }
> ```
>
> For a list of mandatory methods see Table
>
> The wallet should reject request calls unless `enable` has been resolved.
>
> Sensitive requests that involve signing should always prompt the user for
> confirmation
>
> On success the request should resolve to the response as defined in the
> method table.
>
> **`UserDeniedError`** will be thrown if the request is rejected.
>
> **Mandatory methods**
>
> method: `wallet_getAddresses` params: [`index = 0, numAddresses = 1, change
> = false`]
> return: `[ Address ]`
> error: UserDeniedError
>
> method: `wallet_signMessage` params: `[ message, address ]`
> return: Signature `Hex`
> error: UserDeniedError
>
> method: `wallet_signPSBT` params: `[ [psbtBase64, inputIndex, address] ]`
> return: `psbtBase64`
> error: UserDeniedError
>
> method: `wallet_getConnectedNetwork` params: `[]`
> return: Network object `mainnet` | `testnet` | `regetst`
> error: UserDeniedError
>
> ## Rationale
>
> The purpose of the API is to expose a set of commonly used wallet
> operations. In addition, it should be flexible enough to serve for other
> requests such as node RPC calls.
>
> **Why is there a singular request call instead of named methods?**
> The transport layer for the requests cannot be assumed, therefore it is
> much more flexible to instead define an abstract format.
>
> **Why are the mandatory methods so primitive? Where is getBalance,
> getUtxos, ... ?**
> A wallet need not worry about providing every possible scenario for usage.
> The primitives of keys and signing can expose enough to applications to do
> the rest. Applications should have flexibility in how they implement these
> functions. It is the role of a library rather than the wallet.
>
> ## Security Implications
>
> Great care should be taken when exposing wallet functionality externally as
> the security and privacy of the user is at risk.
>
> ### Signing
>
> Operations that trigger signing using private keys should be guarded behind
> confirmation screens where the user is fully aware of the nature of the
> transaction. In the example of a PSBT signature request, the outputs, the
> inputs and which key is being used should be clearly marked.
>
> ### Privacy
>
> Some api methods expose metadata about the user, such as public keys.
> Depending on how privacy focused the wallet intends to be, the wallet could
> protect these behind a confirmation. Commonly the wallet just needs to give
> the origin access to all of its public keys, however it could also allow
> the option to expose only selected derivation paths.
>
> -monokh

2023-06-07 18:27:49

- reply

📅 Original date posted:2020-12-18
📝 Original message:Thanks for explaining where instructions are lacking.
How does this look?
https://github.com/bitcoin/bips/pull/1046/files
On Friday 18 December 2020 01:44:27 dentondevelopment wrote:
> Hi Luke,
>
> It looks to have the same motivations and be compatible with
> https://github.com/bitcoin/bips/pull/253 (if I am reading it correctly).
>
> The only guidance I have on proposing a bip is what is on the readme
> https://github.com/bitcoin/bips/blob/master/README.mediawiki
>
> 48 would be fitting if it is unused.
>
> This is still very much a work in progress and there does seem to be
> community support.
>
> Pavol and others have shared relevant info/suggestions which I will be
> using to update the proposal.
>
> Will share again here when the next draft is ready.
>
> Many thanks,
> Fontaine
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Thursday, December 17, 2020 1:16 AM, Luke Dashjr <luke at dashjr.org> wrote:
> > BIP number 48 has not been assigned. Do not self-assign BIP numbers.
> >
> > Is this intended to be compatible with
> > https://github.com/bitcoin/bips/pull/253 ?
> >
> > Luke
> >
> > On Wednesday 16 December 2020 14:10:28 dentondevelopment via bitcoin-dev
> >
> > wrote:
> > > Here is the repo instead of a static link:
> > > https://github.com/Fonta1n3/bips/blob/master/bip-0048.mediawiki
> > > Fontaine
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Wednesday, December 16, 2020 8:43 PM, dentondevelopment via
> > > bitcoin-dev
> >
> > bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > Hello,
> > > > I would like to propose bip48 (taking bip44 as inspiration), with the
> > > > purpose of documenting modern multi-sig derivations.
> > > > Please see a rough draft of the proposed bip attached, comments/input
> > > > welcome.
> > > > Regards,
> > > > Fontaine

2023-06-07 18:27:49

- reply

📅 Original date posted:2020-12-16
📝 Original message:BIP number 48 has not been assigned. Do not self-assign BIP numbers.
Is this intended to be compatible with
https://github.com/bitcoin/bips/pull/253 ?
Luke
On Wednesday 16 December 2020 14:10:28 dentondevelopment via bitcoin-dev
wrote:
> Here is the repo instead of a static link:
> https://github.com/Fonta1n3/bips/blob/master/bip-0048.mediawiki
>
> Fontaine
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Wednesday, December 16, 2020 8:43 PM, dentondevelopment via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hello,
> >
> > I would like to propose bip48 (taking bip44 as inspiration), with the
> > purpose of documenting modern multi-sig derivations.
> >
> > Please see a rough draft of the proposed bip attached, comments/input
> > welcome.
> >
> > Regards,
> > Fontaine

2023-06-07 18:27:43

- reply

📅 Original date posted:2020-12-06
📝 Original message:Anything that makes sense to coordinate between different programs is BIP
material, not just core Bitcoin protocol...
On Sunday 06 December 2020 19:14:13 yanmaani--- via bitcoin-dev wrote:
> The reason Samourai did not propose a BIP is that that was not a
> proposal to improve the Bitcoin protocol.
>
> You could write a specification for it, but this mailing list is
> probably the wrong venue.
>
> On 2020-12-06 18:20, Prayank via bitcoin-dev wrote:
> > Hello Everyone,
> >
> > I know there have been lot of controversial and heated discussions
> > involving Samourai in past. Ignoring everything including the tweets
> > in which Samourai team mentioned no interest in proposing a BIP
> > related to automated and secure communication used in Soroban, I
> > wanted to know if enough people would be interested in a BIP because
> > it may help other bitcoin projects in future.
> >
> > Tweets: https://twitter.com/SamouraiWallet/status/1334977957157367810
> > [1]
> >
> > https://twitter.com/SamouraiDev/status/1335103101188104194 [2]
> >
> > Ben also tweeted that a BIP would make sense:
> > https://twitter.com/benthecarman/status/1334977096079306753 [3]
> >
> > I think we should keep all the controversial things aside and do
> > everything that helps Bitcoin. It's mentioned in the medium article
> > that it can help other projects like joinmarket, coinswap, snickr etc.
> >
> > https://link.medium.com/uBvIJUSLQbb
> >
> > The source code for a client library in Java is available here
> > https://code.samourai.io/wallet/soroban-client-java and the source
> > code for the Go based server component is available here
> > https://code.samourai.io/wallet/samourai-soroban
> >
> > Let me know if a BIP for such implementation to be used by other
> > bitcoin projects makes sense and if anyone willing to help me in
> > creating a BIP.
> >
> > Thanks.
> >
> > -- Prayank
> >
> > Links:
> > ------
> > [1] https://twitter.com/SamouraiWallet/status/1334977957157367810?s=19
> > [2] https://twitter.com/SamouraiDev/status/1335103101188104194?s=19
> > [3] https://twitter.com/benthecarman/status/1334977096079306753?s=19
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:26:36

- reply

📅 Original date posted:2020-08-18
📝 Original message:Bitcoin Knots version 0.20.1.knots20200815 is now available from:
https://bitcoinknots.org/files/0.20.x/0.20.1.knots20200815/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v0.20.1.knots20200815/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200818/13a10f73/attachment.sig>

2023-06-07 18:25:31

- reply

📅 Original date posted:2020-06-16
📝 Original message:Bitcoin Knots version 0.20.0.knots20200614 is now available from:
https://bitcoinknots.org/files/0.20.x/0.20.0.knots20200614/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v0.20.0.knots20200614/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200617/26758bcd/attachment.sig>

2023-06-07 18:24:17

- reply

📅 Original date posted:2020-05-05
📝 Original message:On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
> may attract a lot of adoption without users running a full-node.
No, it cannot be shifted. This would compromise Bitcoin itself, which for
security depends on the assumption that a supermajority of the economy is
verifying their incoming transactions using their own full node.
The past few years has seen severe regressions in this area, to the point
where Bitcoin's future seems quite bleak. Without serious improvements to the
full node ratio, Bitcoin is likely to fail.
Therefore, all efforts to improve the "full node-less" experience are harmful,
and should be actively avoided. BIP 157 improves privacy of fn-less usage,
while providing no real benefits to full node users (compared to more
efficient protocols like Stratum/Electrum).
For this reason, myself and a few others oppose merging support for BIP 157 in
Core.
> Assuming a user adoption path where a full-node is required to benefit for
> LN may deprive a lot of users, especially those who are already denied a
> real financial infrastructure access.
If Bitcoin can't do it, then Bitcoin can't do it.
Bitcoin can't solve *any* problem if it becomes insecure itself.
Luke
P.S. See also
https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25

2023-06-07 18:23:21

- reply

📅 Original date posted:2020-03-07
📝 Original message:Bitcoin Knots version 0.19.1.knots20200304 is now available from:
https://bitcoinknots.org/files/0.19.x/0.19.1.knots20200304/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v0.19.1.knots20200304/doc/release-notes.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200307/dcd345ed/attachment.sig>

2023-06-07 18:23:15

- reply

📅 Original date posted:2020-03-04
📝 Original message:In addition to starting with proof-of-funds instead of proof-of-receiver, it
would be nice to integrate with Taproot somehow or another. Perhaps
OP_MESSAGEONLY is the most straightforward way to do this? It might be a good
idea to have a message type after the opcode too.
On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev wrote:
> Hello,
>
> I noticed recently that a PR to Bitcoin Core that pretty much touched
> everything my BIP-322 pull request touches (around the same
> complexity) was merged without a thought given to BIP-322
> compatibility, despite the BIP-322 PR being open for 2x the time. I
> can only conclude from this that people dislike BIP-322 in its current
> form, which the 9 month old pull request stagnating can probably
> attest to.
>
> There are several things that I can do to make this a bit more
> appealing to people, which would hopefully kick the progress on this
> forward. I have already put in a non-trivial amount of energy and
> effort into maintaining the pull request as is, so I'd prefer if
> people were harsh and unfiltered in their criticism rather than polite
> and buffered, so I can beat this thing into shape (or abandon it, in
> the worst case).
>
> =============
> 1. People use signmessage as a way to prove funds. This is misleading
> and should be discouraged; throw the sign message stuff out and
> replace it entirely with a prove funds system.
>
> I know in particular luke-jr is of this opinion, and Greg Maxwell in
> https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
> leans towards this opinion as well, it seems.
>
> =============
> 2. Use a transaction rather than a new format; make the first input's
> txid the message hash to ensure the tx cannot be broadcasted. This has
> the benefit of being able to provide to an existing hardware wallet
> without making any modifications to its firmware.
>
> I think Mark Friedenbach and Johnson Lau are of this opinion, except
> Johnson Lau also suggests that the signature hash is modified, see
> https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
> which defeats the benefit above since now hw wallets can no longer
> sign.
>
> Prusnak (I think he works at Trezor; apologies if I am mistaken) is
> against this idea, and proposes (3) below:
> https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
>
> =============
> 3. Use Trezor style
>
> See https://github.com/trezor/trezor-mcu/issues/169
>
> This has the benefit of already being adopted (which clearly BIP-322
> is failing hard at right now), but has the drawback that we can no
> longer do *generic* signing; we are stuck with the exact same
> limitations as in the legacy system, which we kinda wanted to fix in
> the updated version.
>
> =============
> 4. Introduce OP_MESSAGEONLY
>
> Quoting Johnson Lau at
> https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
> """
> OP_MESSAGEONLY means the script following the code would never be
> valid. For example, a scriptPubKey:
>
> OP_IF OP_MESSAGEONLY <key_m> OP_ELSE <key_s> OP_ENDIF OP_CHECKSIG
>
> For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
> ignored. A message could be signed with either key_m or key_s.
>
> For spending, only key_s is valid.
>
> I don't think it is a big problem to consume a op_code. If this is a
> real concern, I could modify it as follow: in message system,
> OP_RETURN will pop the top stack. If top stack is msg in hex, it is
> ignored. Otherwise, the script fails.
> """
>
> =============
> 5. Some other solution
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:22:37

- reply

📅 Original date posted:2020-01-19
📝 Original message:Bitcoin Knots version 0.19.0.1.knots20200104 is now available from:
https://bitcoinknots.org/files/0.19.x/0.19.0.1.knots20200104/
This release includes new features, various bug fixes and performance
improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoinknots/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoinknots.org/list/announcements/join/
For the full release notes and change log, see:
https://github.com/bitcoinknots/bitcoin/blob/v0.19.0.1.knots20200104/doc/release-notes.md
New features of particular interest
===================================
- BIP157 (Neutrino) can be enabled to serve compact block filters to peers.
This requires both the `-blockfilterindex` and `-peercfilters` options
enabled, and can also be turned on in the GUI settings under the Network
tab.
- PSBT support has been experimentally expanded to include the new version and
proprietary fields, as well as easier usage from the GUI for watch-only
wallets.
- The Overview tab now has the ability to hide private information. This is
still an experimental feature, and suggestions for how the new "privacy
mode" should look can be made on the related Core PR:
https://github.com/bitcoin/bitcoin/pull/16432
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1524 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200119/83ec0ecc/attachment.sig>

2023-06-07 18:22:18

- reply

📅 Original date posted:2020-01-10
📝 Original message:I think BIP 9 is a proven failure, and flag day softforks have their own
problems:
A) There is no way to unambiguously say "the rules for this chain are
<x,y,z>". It leaves the chain in a kind of "quantum state" where the rules
could be one thing, or could be another. Until the new rules are violated, we
do not know if the softfork was a success or not. Because of this, people
will rightly shy away from relying on the new rules. This problem is made
worse by the fact that common node policies might not produce blocks which
violate the rules. If we had gone with BIP149 for Segwit, it is IMO probable
we would still not have a clear answer today to "Is Segwit active or not?"
B) Because of (A), there is also no clear way to intentionally reject the
softfork. Those who do not consent to it are effectively compelled to accept
it anyway. While it is usually possible to craft an opposing softfork, this
should IMO be well-defined and simple to do (including a plan to do so in any
BIP9-alike spec).
For these reasons, in 2017, I proposed revising BIP 8 with a mandatory signal,
similar to how BIP148 worked: https://github.com/bitcoin/bips/pull/550
However, the author of BIP 8 has since vanished, and because we had no
immediate softfork plans, efforts to move this forward were abandoned
temporarily. It seems like a good time to resume this work.
In regard to your goal #3, I would like to note that after the mandatory
signal period, old miners could resume mining unchanged. This means there is
a temporary loss of hashrate to the network, but I think it is overall better
than the alternatives. The temporary loss of income from invalid blocks will
also give affected miners a last push to upgrade, hopefully improving the
long run security of the network hashrate.
Luke
(P.S. As for your #1, I do think it is oversimplified in some cases, but we
should leave that for later discussion when it actually becomes relevant.)
On Friday 10 January 2020 21:30:09 Matt Corallo via bitcoin-dev wrote:
> There are a series of soft-fork designs which have recently been making
> good progress towards implementation and future adoption. However, for
> various reasons, activation methods therefor have gotten limited
> discussion. I'd like to reopen that discussion here.
>
> It is likely worth revisiting the goals both for soft forks and their
> activation methods to start. I'm probably missing some, but some basic
> requirements:
>
> 1) Avoid activating in the face of significant, reasonable, and directed
> objection. Period. If someone has a well-accepted, reasonable use of
> Bitcoin that is working today, have no reason to believe wouldn't work
> long into the future without a change, and which would be made
> impossible or significantly more difficult by a change, that change must
> not happen. I certainly hope there is no objection on this point (see
> the last point for an important caveat that I'm sure everyone will jump
> to point out).
>
> 2) Avoid activating within a timeframe which does not make high
> node-level-adoption likely. As with all "node" arguments, I'll note that
> I mean "economically-used" nodes, not the thousand or so spy nodes on
> Google Cloud and AWS. Rule changes don't make sense without nodes
> enforcing them, whether they happen to be a soft fork, hard fork, or a
> blue fork, so activating in a reduced timeframe that doesn't allow for
> large-scale node adoption doesn't have any value, and may cause other
> unintended side effects.
>
> 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of
> Bitcoin's security comes from miners, reducing the hashpower of the
> network as a side effect of a rule change is a needless reduction in a
> key security parameter of the network. This is why, in recent history,
> soft forks required 95% of hashpower to indicate that they have upgraded
> and are capable of enforcing the new rules. Further, this is why recent
> soft forks have not included changes which would result in a standard
> Bitcoin Core instance mining invalid-by-new-rules changes (by relying on
> the standardness behavior of Bitcoin Core).
>
> 4) Use hashpower enforcement to de-risk the upgrade process, wherever
> possible. As a corollary of the above, one of the primary reasons we use
> soft forks is that hashpower-based enforcement of rules is an elegant
> way to prevent network splits during the node upgrade process. While it
> does not make sense to invest material value in systems protected by new
> rules until a significant majority of "economic nodes" is enforcing said
> rules, hashpower lets us neatly bridge the gap in time between
> activation and then. By having a supermajority of miners enforce the new
> rules, attempts at violating the new rules does not result in a
> significant network split, disrupting existing users of the system. If
> we aren't going to take advantage of this, we should do a hard fork
> instead, with the necessarily slow timescale that entails.
>
> 5) Follow the will of the community, irrespective of individuals or
> unreasoned objection, but without ever overruling any reasonable
> objection. Recent history also includes "objection" to soft forks in the
> form of "this is bad because it doesn't fix a different problem I want
> fixed ASAP". I don't think anyone would argue this qualifies as a
> reasonable objection to a change, and we should be in a place, as a
> community (never as developers or purely one group), to ignore such
> objections and make forward progress in spite of them. We don't make
> good engineering decisions by "bundling" unrelated features together to
> enable political football and compromise.
>
> I think BIP 9 (plus a well-crafted softfork) pretty effectively checks
> the boxes for #2-4 here, and when done carefully with lots of community
> engagement and measurement, can effectively fulfill #1 as well. #5 is,
> as I'm sure everyone is aware, where it starts to fall down pretty hard.
>
> BIP 8 has been proposed as an alternative, largely in response to issues
> with #5. However, a naive deployment of it, rather obviously, completely
> fails #1, #3, and #4, and, in my view, fails #5 as well by both giving
> an impression of, setting a precedent of, and possibly even in practice
> increasing the ability of developers to decide the consensus rules of
> the system. A BIP 8 deployment that more accurately measures community
> support as a prerequisite could arguably fulfill #1 and #5, though I'm
> unaware of any concrete proposals on how to accomplish that. Arguably, a
> significantly longer activation window could also allow BIP 8 to fulfill
> #3 and #4, but only by exploiting the "needlessly" and "wherever
> possible" loopholes.
>
> You may note that, from the point of view of achieving the critical
> goals here, BIP 8 is only different from a flag-day activation in that,
> if it takes the "happy-path" of activating before the flag day, it looks
> like BIP 9, but isn't guaranteed to. It additionally has the
> "nice-to-have" property that activation can occur before the flag-day in
> the case of faster miner adoption, though there is a limit of how fast
> is useful due to node adoption.
>
> Thus, to strike a balance between the drawbacks of BIP 8 and BIP 9, the
> Great Consensus Cleanup softfork proposal included this text in the
>
> discussion section (with the spec describing a BIP 9 deployment):
> > In spite of some suggestion that other activation methods be used, BIP
> > 9 is proposed as ensuring miners have upgraded to enforce new rules is
> > an important part of minimizing disruption. While previous BIP 9 soft-
> > forks have resulted in political contention, this comparatively-
> > unimportant soft-fork provides a good opportunity to attempt to return
> > to utilizing BIP 9 to ensure miner upgrade prior to activation, which
> > the authors believe is a critical goal. However, if there is broad
> > agreement to activate these rules when the BIP 9 expiry time is
> > reached, and miners have not yet signaled sufficient level of
> > readiness, a later flag-day activation may be merited. For this
> > reason, implementations may wish to provide a compatibility option
> > which allows flag-day enforcement of these rules without an update.
>
> Ultimately, through admittedly rather limited discussion, I still like
> this model (though I cannot claim it as my own, the original proposal
> came from Greg Maxwell). BIP 9 only falls apart in case of unreasonable
> objection, which, naturally, should carry a high bar to ignore, given we
> have to have some level of agreement that it is, in fact, unreasonable
> (or untargeted). While I admit this is a possibility, I both find it
> less likely than in previous soft-forks, and even if it is the case, it
> only slows down the process, it doesn't necessarily stop it. In the case
> that it does fail, BIP 9 process, in fact, provides a good learning
> opportunity as to the level of community readiness and desire for a
> given change. While we can (and should, and are) learning a lot about
> community readiness for, and acceptability of a change through outreach
> and discussion, there is something about a change with a timeframe that
> forces people to more carefully consider it.
>
> Thus, as something a bit more concrete, I think an activation method
> which sets the right precedent and appropriately considers the above
> goals, would be:
>
> 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 can analyze and discussion
> the reasons for no activation and,
> 3) in the case that it makes sense, a simple command-line/bitcoin.conf
> parameter which was supported since the original deployment release
> would enable users to opt into a BIP 8 deployment with a 24-month
> time-horizon for flag-day activation (as well as a new Bitcoin Core
> release enabling the flag universally).
>
> This provides a very long time horizon for more standard activation,
> while still ensuring the goals in #5 are met, even if, in those cases,
> the time horizon needs to be significantly extended to meet the goals of
> #3. Developing Bitcoin is not a race. If we have to, waiting 42 months
> ensures we're not setting a negative precedent that we'll come to regret
> as Bitcoin continues to grow.
>
> Matt
>
> Thanks also to AJ for feedback on an earlier version of this rant.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:22:17

- reply

📅 Original date posted:2020-01-12
📝 Original message:On Saturday 11 January 2020 14:42:07 Anthony Towns wrote:
> the UASF approach had significant potential technical problems
> (potential for long reorgs, p2p network splits) that weren't
> resolved by the time it became active.
Long reorgs, only for old nodes, were a possibility, but not a problem.
The p2p network split issues WERE resolved well before activation.
(In fact, Bitcoin Knots still ships with the general p2p fixes.)
> neither
> BIP-148 or BIP-91 gained enough consensus to be supported in
> bitcoin core though
There was no measurable difference in community support between BIP148 and
Segwit itself, months before BIP148's activation. (There was about 20% that
indicated they would support BIP148 "only if Bitcoin Core releases it", which
IMO "counts" in this context.)
The only difference was in the opinions of developers. Basing the decision to
exclude BIP148 as even an *option* on this basis was IMO improper and
shouldn't be repeated. The community's readiness to switch to another
fork/build for UASFs is also valuable, but shouldn't be necessary.
Luke

2023-06-07 18:21:46

- reply

📅 Original date posted:2019-11-22
📝 Original message:CVE-2018-20586 is a log injection vulnerability which allows any software with
access to the RPC port to create fake or confusing entries in the debug log.
Valid authentication (username/password/cookie) for the RPC service is NOT
required to exploit this vulnerability, only the ability to connect to the
RPC port (which is by default only exposed to the local machine).
The vulnerability was introduced in 40b556d3742a1f65d67e2d4c760d0b13fe8be5b7
("libevent-based http server") and first released in Bitcoin Core v0.12.0rc1
in 2016 Jan 13. A fix was hidden in 79358817e53ac0a7afa64c747115d492a74e3155
("rpc: Make HTTP RPC debug logging more informative") released in v0.17.1,
2018 Dec 22.
To be vulnerable, the malicious software must either be running on the same
machine as the node, have the ability to proxy connections to the node via
the local machine, or the node must be configured to accept RPC connections
from a network via which the attacker can connect. Additionally, a human user
must read the debug log and act on or otherwise believe the injected data, in
a way that is somehow harmful.
Because the node would log the arbitrary POST request from any connection, an
attacker can add nearly any content to the request to inject it into the log.
To ensure their entire request is injected, standard spaces would need to be
replaced with alternative whitespace characters, and newlines would need to
become other control characters (such as "\r\v"). Because the injected data
must use such non-standard characters, it is most likely to not fool other
software parsing the debug log, and only a human visually reading it.
To fix this vulnerability, POST requests are now sanitised before being
logged, removing all characters that shouldn't be in an ordinary POST
request.
Credit goes to practicalswift (https://twitter.com/practicalswift) for
discovering and fixing the vulnerability.
Timeline:
- 2015-01-18: Vulnerability introduced in PR #5677.
- 2015-09-04: Vulnerability merged to master git repository.
- 2016-01-13: Vulnerability published in v0.12.0rc1.
- 2016-02-18: Vulnerability released in v0.12.0.
...
- 2018-10-25: practicalswift discloses vulnerability to security team.
- 2018-10-31: practicalswift opens PR #14618 to quietly fix vulnerability.
- 2018-11-05: Fix merged to master git repository.
- 2018-11-30: Fix merged to 0.17 git repository.
- 2018-12-07: Fix published in v0.17.1rc1.
- 2018-12-22: Fix released in v0.17.1.
...
- 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019-11-22: Vulnerability details disclosure to bitcoin-dev ML.

2023-06-07 18:21:39

- reply

📅 Original date posted:2019-11-08
📝 Original message:CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious
SOCKS proxy server to overwrite the program stack on systems with a signed
`char` type (including common 32-bit and 64-bit x86 PCs).
The vulnerability was introduced in 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
(SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27.
A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 ("Improve and
document SOCKS code") released in v0.15.1, 2017 Nov 6.
To be vulnerable, the node must be configured to use such a malicious proxy in
the first place. Note that using *any* proxy over an insecure network (such
as the Internet) is potentially a vulnerability since the connection could be
intercepted for such a purpose.
Upon a connection request from the node, the malicious proxy would respond
with an acknowledgement of a different target domain name than the one
requested. Normally this acknowledgement is entirely ignored, but if the
length uses the high bit (ie, a length 128-255 inclusive), it will be
interpreted by vulnerable versions as a negative number instead. When the
negative number is passed to the recv() system call to read the domain name,
it is converted back to an unsigned/positive number, but at a much wider size
(typically 32-bit), resulting in an effectively infinite read into and beyond
the 256-byte dummy stack buffer.
To fix this vulnerability, the dummy buffer was changed to an explicitly
unsigned data type, avoiding the conversion to/from a negative number.
Credit goes to practicalswift (https://twitter.com/practicalswift) for
discovering and providing the initial fix for the vulnerability, and Wladimir
J. van der Laan for a disguised version of the fix as well as general cleanup
to the at-risk code.
Timeline:
- 2012-04-01: Vulnerability introduced in PR #1141.
- 2012-05-08: Vulnerability merged to master git repository.
- 2012-08-27: Vulnerability published in v0.7.0rc1.
- 2012-09-17: Vulnerability released in v0.7.0.
...
- 2017-09-21: practicalswift discloses vulnerability to security team.
- 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
- 2017-09-27: Fix merged to master git repository.
- 2017-10-18: Fix merged to 0.15 git repository.
- 2017-11-04: Fix published in v0.15.1rc1.
- 2017-11-09: Fix released in v0.15.1.
...
- 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.

2023-06-07 18:21:34

- reply

📅 Original date posted:2019-11-11
📝 Original message:On Monday 11 November 2019 17:10:16 Hampus Sjöberg wrote:
> > It ISN'T low right now...
>
> I agree, but I don't think it's a good idea to softfork it to lower than 4M
> WU though, and I don't think we need to;
> hopefully when exchanges start using Lightning or Liquid, avg blocksize
> will go down.
Not likely, so long as spam continues to pad blocks full.
> > Extension blocks are not softforks, and are unreasonably convoluted for
> no
> real gain. When the time comes, the block size should be increased only
> using
> a hardfork.
>
> It depends on how you define soft and hardforks, I suspect you don't see
> extension blocks as a softforks because old nodes won't maintain a correct
> UTXO set.
> I think an extension block is a softfork because old nodes will still be
> able to follow the mainchain.
Softforks leave old nodes *working*, so yes, maintaining the correct UTXO
state.
Simply "following" is meaningless, as even soft-hardforks are "followed".
> I don't know if a blocksize increase hardfork will get consensus as the
> idea has been ruined by all malicious hijack attempts we've seen over the
> years.
If there isn't consensus, then it shouldn't be done, period.
Luke

2023-06-07 18:21:33

- reply

📅 Original date posted:2019-11-11
📝 Original message:On Monday 11 November 2019 16:08:43 Hampus Sjöberg via bitcoin-dev wrote:
> I am advocating to keep the blocksize low right now,
It ISN'T low right now...
> but I don't leave out
> in increasing it in the future when we have a need for it, preferably via
> an extension block (softfork).
Extension blocks are not softforks, and are unreasonably convoluted for no
real gain. When the time comes, the block size should be increased only using
a hardfork.
Luke

2023-06-07 18:21:07

- reply

📅 Original date posted:2019-10-06
📝 Original message:On Saturday 05 October 2019 21:57:48 Emil Engler via bitcoin-dev wrote:
> Hello dear mailing list subscribers.
> Before I'll explain my idea here, I need to define a term first
>
> 'address':
> When I use the terms address, pubkey, etc., I mean the same: The Base58
> string
But a pubkey is not a Base58 string, and fundamentally different from an
address. An address identifies the recipient and the purpose of the payment;
a pubkey does not. The pubkey remains with the UTXO; an address does not.
> Ok now let's get into it:
> As you should know, sending bitcoins to an address more than once is a
> very bad approach.
> In my opinion the problem why so many people are still doing this is
> because of the term 'address' which is used in lots of wallets,
> implementations, BIP 21 and so on. It is a design issue.
> With the term 'address' most people identify things that are fixed and
> don't change really often (e.g postal address, IP address [depends on
> provider], Domain, E-Mail address, ...).
> Because of this most people compare bitcoin addresses with e-mail
> addresses and use this address to send the recipient money multiple times.
That problem would require using a different term than "address" to address.
A BIP is unlikely to do the job (though it may help).
> My suggestion would be to change the term address in wallets, the URI
> scheme and so on to something of the following options by a
> Informational/Process BIP:
>
> * Payment Password
> * Transaction Password
> * ...
Neither the address nor pubkey are a password...
Some possible alternative terms would be "invoice id", "payment token", etc.
> The guideline for the term should indicate that it is:
> * temporary
> * Something that identifies the recipient
>
> I've chosen 'password' because they can be used as a pseudonym to
> identify a person.
> This is already used in stuff like bank transfers where something like
> the transaction id should be used as the purpose or at universities
> there are student numbers.
> The first is probably a better example because student numbers aren't
> temporary.
>
> What do you think? Should I write a BIP for this or use another term?
> Feedback is most welcome :)
>
> Greetings,
> Emil Engler

2023-06-07 18:19:40

- reply

📅 Original date posted:2019-07-25
📝 Original message:On Tuesday 23 July 2019 15:09:02 Karl-Johan Alm via bitcoin-dev wrote:
> People come in as Bitcoin developers all the time, but sometimes
> people also leave permanently. In the case of BIP authors, when a user
> leaves and does not respond to (reasonable) requests to change their
> BIPs, we are sort of stuck right now.
BIP 2 allows assigning a new champion.
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Transferring_BIP_Ownership

2023-06-07 18:19:39

- reply

📅 Original date posted:2019-07-22
📝 Original message:On Monday 22 July 2019 18:52:10 Peter via bitcoin-dev wrote:
> Privacy is a matter of individual choice in the current protocol. Why not
> let people provide this network service? I don't see why it should be
> end-of-life if it provides value.
It's not EOL, just disabled by default. Anyone can provide it by choice.
Same as with Stratum/Electrum right now (except easier to enable).
> I believe there's a network security obtained by having a large quantity of
> people following the Bitcoin headers based on longest weighted chain. As a
> means of nullifying potential miner initiated hard forks (like S2X).
This is incorrect. Such wallets strictly degrade security, as they are blindly
trusting miners. They make the network more VULNERABLE to 2X-like attacks.
Luke

2023-06-07 18:19:38

- reply

📅 Original date posted:2019-07-27
📝 Original message:On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote:
> 3) Afaik, it enforces/encourages address re-use. This stems from the
> fact that the server decides on the filter and in particular on the
> false positive rate. On wallets with many addresses, a hardcoded filter
> will be too blurry and thus each block will be matched. So wallets that
> follow the "one address per incoming payment" pattern (e.g. HD wallets)
> at some point will be forced to wrap their key chains back to the
> beginning. If I'm wrong on this one please let me know.
BTW, you are indeed wrong on this. You don't need to match every single
address the wallet has ever used, only outstanding addresses that haven't
been paid. ;)
Luke

2023-06-07 18:19:37

- reply

📅 Original date posted:2019-07-25
📝 Original message:On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote:
> > the DNS seed infrastructure among others can easily direct
> > wallets to those nodes
>
> Last I checked none of the seeds did. But I agree this would be nice to
> have.
It's supported by default in sipa's bitcoin-seeder, which many DNS seeds use.
My seed also currently requires NODE_BLOOM for *any* answers returned.
(But I don't guarantee that will remain forever.)
> As a side note, Coinbase just announced their 30M'th wallet. I'm
> convinced this massive run into custodial wallets...
Light wallets are just as bad for the network as custodial wallets.
> IMHO, BIP 37 is the only scaling technology that has proven successful and
> could – if supported and improved rather than choked – continue to help
> holding against the bitbanks trend.
Light wallets are not Bitcoin scaling. They are just trusting anonymous 3rd
parties, which is harmful to Bitcoin.
Luke

2023-06-07 18:19:36

- reply

📅 Original date posted:2019-07-22
📝 Original message:On Monday 22 July 2019 13:25:25 Jonas Schnelli via bitcoin-dev wrote:
> > I also think as long as we don't have an alternative, we should improve
> > the current filtering for segwit. E.g. testing the scripts themselves
> > and each scriptPubKey spent by any input against the filter would do,
> > and it also fixes the main privacy issue with server-side filtering
> > (wallets have to add two items per address to the filter).
>
> I think the consensus among protocol developers is (please speak up), that
> BIP37 (public server based tx filtering) – in general – was a conceptual
> mistake. Maybe extending it further is the wrong step, especially when
> promising alternatives like BIP158 (neutrino) are around.
Neutrino is very controversial, and NOT less trustful than bloom filters.
It also uses significantly more bandwidth.
It seems a better approach is to add Stratum (Electrum) support, and to limit
usage of all pseudo-SPV protocols to trusted peers.
> The fact that nobody cared about extending it for SW may also underline that
> BIP37 is seen as a conceptual mistake and/or "low interest in further
> extensions“.
Eric Lombrozo added segwit support. While it was never reviewed for Core, it
has been included and supported in Knots since v0.15.1. As I understand it,
his mSIGNA wallet also makes usage of the feature.
Luke

2023-06-07 18:19:36

- reply

📅 Original date posted:2019-07-22
📝 Original message:On Sunday 21 July 2019 22:56:33 Andreas Schildbach via bitcoin-dev wrote:
> An estimated 10+ million wallets depend on that NODE_BLOOM to be
> updated.
Where do you see this number? I think it would be useful to chart.
> So far, I haven't heard of an alternative, except reading all
> transactions and full blocks.
Electrum has a JSON-based protocol that can provide information much more
efficiently.
Currently, this does require nodes that run additional software and/or
indexes, but there are plenty of them available, and there are steps that can
be taken to improve that situation.
> > It is not anticipated that
> > this will result in a significant lack of availability of
> > NODE_BLOOM-enabled nodes in the coming years
>
> Why don't you anticipate that? People almost never change defaults,
> especially if it's not for their own immediate benefit. At the same
> time, release notes in general recommend updating to the latest version.
> I *do* anticipate this will reduce the number of nodes usable by a large
> enough amount so that the feature will become unstable.
Many users run older versions, and do not update immediately. Today, only 42%
of listening nodes are using 0.18.
(If it helps ease the concern, we can keep bloom enabled by default in Knots
longer.)
> I strongly recommend postponing this change until an alternative exists
> and then give developers enough time to implement, test and roll out.
There will be time to do so, since the functionality won't disappear
overnight.
Luke

2023-06-07 18:18:43

- reply

📅 Original date posted:2019-06-22
📝 Original message:Two relatively minor vulnerabilities will likely be disclosed sometime soon.
The first vulnerability, CVE-2017-18350, was introduced in v0.7.0 (released in
2012 September), and affects all versions released until the fix was included
in v0.15.1 (released in 2017 November). No versions prior to v0.15.1 are
expected to be fixed.
The second vulnerability, CVE-2018-20586, was introduced in v0.12.0 (released
in 2016 February), and affects all versions released until the fix was
included in v0.17.1 (released in 2018 December). As of today, this fix has
NOT been backported to older versions. When/if v0.15.3 and v0.16.4 are
released, they may also include a fix, but due to the minor severity of this
vulnerability, it does not merit a dedicated release on its own. (The git
branches are also NOT fixed at this time.)
Please be sure you have upgraded to a fixed version no later than August 1st.

2023-06-07 18:18:02

- reply

📅 Original date posted:2019-05-08
📝 Original message:On Monday 06 May 2019 20:17:09 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.
This would be especially useful for things like OP_CHECKBLOCKATHEIGHT:
https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki

2023-06-07 18:17:58

- reply

📅 Original date posted:2019-05-06
📝 Original message:There are multiple references to "space savings", but no rationale for
treating "space" as something to save or even define. The costs are in CPU
time and I/O (which "space saving" doesn't necessarily reduce) and bandwidth
(which can often be reduced without "space saving" in commitments). The
proposal can apparently be made simpler by ignoring this irrelevant "space
saving" goal.
Tagged hashes put the tagging at the start of the hash input. This means
implementations can pre-cache SHA2 states, but it also means they can't reuse
states to produce data for different contexts. (I'm not sure if there is a
use for doing so... but maybe as part of further hiding MAST branches?)
Is there any way to use the Taproot construct here while retaining external
script limitations that the involved party(ies) *cannot* agree to override?
For example, it is conceivable that one might wish to have an unconditional
CLTV enforced in all circumstances.
It may be useful to have a way to add a salt to tap branches.
Some way to sign an additional script (not committed to by the witness
program) seems like it could be a trivial addition.
On Monday 06 May 2019 17:57:57 Pieter Wuille via bitcoin-dev wrote:
> Hello everyone,
>
> Here are two BIP drafts that specify a proposal for a Taproot
> softfork. A number of ideas are included:
>
> * Taproot to make all outputs and cooperative spends indistinguishable
> from eachother.
> * Merkle branches to hide the unexecuted branches in scripts.
> * Schnorr signatures enable wallet software to use key
> aggregation/thresholds within one input.
> * Improvements to the signature hashing algorithm (including signing
> all input amounts).
> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
> batch validation.
> * Tagged hashing for domain separation (avoiding issues like
> CVE-2012-2459 in Merkle trees).
> * Extensibility through leaf versions, OP_SUCCESS opcodes, and
> upgradable pubkey types.
>
> The BIP drafts can be found here:
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
> specifies the transaction input spending rules.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
> specifies the changes to Script inside such spends.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> is the Schnorr signature proposal that was discussed earlier on this
> list (See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.ht
>ml)
>
> An initial reference implementation of the consensus changes, plus
> preliminary construction/signing tests in the Python framework can be
> found on https://github.com/sipa/bitcoin/commits/taproot. All
> together, excluding the Schnorr signature module in libsecp256k1, the
> consensus changes are around 520 LoC.
>
> While many other ideas exist, not everything is incorporated. This
> includes several ideas that can be implemented separately without loss
> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
> which we're working on as an independent proposal.
>
> The document explains basic wallet operations, such as constructing
> outputs and signing. However, a wide variety of more complex
> constructions exist. Standardizing these is useful, but out of scope
> for now. It is likely also desirable to define extensions to PSBT
> (BIP174) for interacting with Taproot. That too is not included here.
>
> Cheers,

2023-06-07 18:17:50

- reply

📅 Original date posted:2019-04-29
📝 Original message:On Saturday 27 April 2019 10:37:29 Aymeric Vitte via bitcoin-dev wrote:
> Maybe trivial question but asking here because I can't find anything
> clear (or updated) about it: is somewhere explained in details what txs
> are considered standard and non standard today without having to read
> the core code?
>
> For example, modification of multisig 2 of 3:
>
> scriptSig:
>     OP_0
>     OP_PUSHDATA sign1
>     OP_PUSHDATA sign2
>     OP_2
>     OP_PUSHDATA <pubkey1><pubkey2><pubkey3> OP_3 OP_CHECKMULTISIG
>
> scriptPubKey:
>     OP_HASH160 hash160(<pubkey1><pubkey2><pubkey3> OP_3
> OP_CHECKMULTISIG) OP_EQUAL
>
> Is this standard? Are lightning txs standards ? etc
The name is confusing. It has little to do with standards, really.
IsStandard is just one of the functions which implement the node's policy.
It allows many things for which there is no standard (eg, data carrier /
OP_RETURN outputs), and can vary freely from node to node (either by
configurable parameters, or by different/modified software) without breaking
consensus.
As it is a node-specific criteria, it is not itself even a possible *subject*
for standards.
Additionally, it should not be given much (if any) attention when defining new
standards. Just do what makes sense for the standard, and node policies can
be adapted around that.
So, overall, there's limited use case for documenting this beyond the code.
It makes far more sense to document actual standards instead.
Luke

2023-06-07 18:17:26

- reply

📅 Original date posted:2019-04-03
📝 Original message:This would lead to users trusting third parties (like developers) way too
much.
Furthermore, removing the ability for users to easily set it removes the one
reasonable use case: where the user has already verified the state at some
point previously, and saved the hash (ie, as backup of the UTXO set).
Luke
On Tuesday 02 April 2019 20:43:11 James O'Beirne via bitcoin-dev wrote:
> Hi,
>
> I'd like to discuss assumeutxo, which is an appealing and simple
> optimization in the spirit of assumevalid[0].
>
> # Motivation
>
> To start a fully validating bitcoin client from scratch, that client
> currently
> needs to perform an initial block download. To the surprise of no one, IBD
> takes a linear amount time based on the length of the chain's history. For
> clients running on modest hardware under limited bandwidth constraints,
> say a mobile device, completing IBD takes a considerable amount of time
> and thus poses serious usability challenges.
>
> As a result, having fully validating clients run on such hardware is rare
> and
> basically unrealistic. Clients with even moderate resource constraints
> are encouraged to rely on the SPV trust model. Though we have promising
> improvements to existing SPV modes pending deployment[1], it's worth
> thinking about a mechanism that would allow such clients to use trust
> models closer to full validation.
>
> The subject of this mail is a proposal for a complementary alternative to
> SPV
> modes, and which is in the spirit of an existing default, `assumevalid`. It
> may
> help modest clients transact under a security model that closely resembles
> full validation within minutes instead of hours or days.
>
> # assumeutxo
>
> The basic idea is to allow nodes to initialize using a serialized version
> of the
> UTXO set rendered by another node at some predetermined height. The
> initializing node syncs the headers chain from the network, then obtains
> and loads one of these UTXO snapshots (i.e. a serialized version of the
> UTXO set bundled with the block header indicating its "base" and some other
> metadata).
>
> Based upon the snapshot, the node is able to quickly reconstruct its
> chainstate,
> and compares a hash of the resulting UTXO set to a preordained hash
> hard-coded
> in the software a la assumevalid. This all takes ~23 minutes, not
> accounting for
> download of the 3.2GB snapshot[2].
>
> The node then syncs to the network tip and afterwards begins a simultaneous
> background validation (i.e., a conventional IBD) up to the base height of
> the
> snapshot in order to achieve full validation. Crucially, even while the
> background validation is happening the node can validate incoming blocks
> and transact with the benefit of the full (assumed-valid) UTXO set.
>
> Snapshots could be obtained from multiple separate peers in the same manner
> as
> block download, but I haven't put much thought into this. In concept it
> doesn't
> matter too much where the snapshots come from since their validity is
> determined via content hash.
>
> # Security
>
> Obviously there are some security implications due consideration. While
> this proposal is in the spirit of assumevalid, practical attacks may become
> easier.
> Under assumevalid, a user can be tricked into transacting under a false
> history
> if an attacker convinces them to start bitcoind with a malicious
> `-assumevalid`
> parameter, sybils their node, and then feeds them a bogus chain
> encompassing all of the hard-coded checkpoints[3].
>
> The same attack is made easier in assumeutxo because, unlike in
> assumevalid, the attacker need not construct a valid PoW chain to get the
> victim's node into
> a false state; they simply need to get the user to accept a bad
> `-assumeutxo`
> parameter and then supply them an easily made UTXO snapshot containing,
> say, a
> false coin assignment.
>
> For this reason, I recommend that if we were to implement assumeutxo, we
> not allow its specification via commandline argument[4].
>
> Beyond this risk, I can't think of material differences in security
> relative to
> assumevalid, though I appeal to the list for help with this.
>
> # More fully validating clients
>
> A particularly exciting use-case for assumeutxo is the possibility of
> mobile devices functioning as fully validating nodes with access to the
> complete UTXO
> set (as an alternative to SPV models). The total resource burden needed to
> start a node
> from scratch based on a snapshot is, at time of writing, a ~(3.2GB
> + blocks_to_tip * 4MB) download and a few minutes of processing time, which
> sounds
> manageable for many mobile devices currently in use.
>
> A mobile user could initialize an assumed-valid bitcoin node within an
> hour, transact immediately, and complete a pruned full validation of their
> assumed-valid chain over the next few days, perhaps only doing the
> background
> IBD when their device has access to suitable high-bandwidth connections.
>
> If we end up implementing an accumulator-based UTXO scaling design[5][6]
> down
> the road, it's easy to imagine an analogous process that would allow very
> fast
> startup using an accumulator of a few kilobytes in lieu of a multi-GB
> snapshot.
>
> ---
>
> I've created a related issue at our Github repository here:
> https://github.com/bitcoin/bitcoin/issues/15605
>
> and have submitted a draft implementation of snapshot usage via RPC here:
> https://github.com/bitcoin/bitcoin/pull/15606
>
> I'd like to discuss here whether this is a good fit for Bitcoin
> conceptually. Concrete
> plans for deployment steps should be discussed in the Github issue, and
> after all
> that my implementation may be reviewed as a sketch of the specific software
> changes necessary.
>
> Regards,
> James
>
>
> [0]:
> https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
> [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
> [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @
> 2.10GHz
> [3]:
> https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L1
>61 [4]: Marco Falke is due credit for this point
> [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
> [6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188

2023-06-07 18:17:25

- reply

📅 Original date posted:2019-04-03
📝 Original message:On Wednesday 03 April 2019 15:39:29 Ethan Scruples via bitcoin-dev wrote:
> If we can get mandatory UTXO commitments soft forked into Bitcoin, we get
> the advantage of a non-growing IBD,
No, we don't. This is exactly the danger. UTXO snapshots are NOT an
alternative to a real IBD. There are HUGE security implications for this.
Frankly, the danger that someone would do such a thing is itself a good
reason not to ever add UTXO commitments.
Luke

2023-06-07 18:17:24

- reply

📅 Original date posted:2019-04-04
📝 Original message:On Wednesday 03 April 2019 21:39:32 Dave Scotese via bitcoin-dev wrote:
> Luke's comment that it could "lead to users trusting third parties (like
> developers) way too much" is pertinent too, but I think an honest abatement
> of that concern is impossible without teaching everyone C++.
Learning C++ is something within everyone's capability. Even people who do not
wish to learn it can hire someone to perform review for them.
> "Developers"
> as an open group (anyone can fork the github repo, find a problem, and make
> an issue) deserve the trust we put in them, and that's because they're
> accountable (any such error found in the repo will have been put there by
> someone).
No, we are not. We explicitly disclaim any warranty, and do not want your
trust.
> The same thing goes for making it possible to download (*not
> just the compiled software*, but) the entire UTXO Set if a commitment of it
> is hardcoded into the software, as James suggests.
Verifying a UTXO set commitment is impossible short of a real IBD. It's not
even comparable.
> We all trust
> "developers" like that, and it's okay.
No, it isn't okay. There are plenty of fiat options if you want a trust-based
currency. Bitcoin is supposed to be something more than that.
Luke

2023-06-07 18:17:14

- reply

📅 Original date posted:2019-03-31
📝 Original message:Certain parts of the community have been selling bitcoins for unreasonably
low prices. This has halted Bitcoin's valuation at $20k and even driven the
price down below $15k! However, clearly Bitcoin is worth much more than
that, and there is widespread support for higher prices.
In light of this, I have written and implemented two BIPs: one to add a
signed price field to Bitcoin transactions, and the other to softfork a
minimum price of $50k USD/BTC a year from today.
The BIPs are here, as well as included at the bottom of this email for
convenience:
https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
A reference implementation is here:
https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
Luke
<pre>
BIP: ?
Layer: Applications
Title: Signed USD Price Indicator
Author: Luke Dashjr <luke+bip at dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Standards Track
Created: 2019-04-01
License: BSD-2-Clause
</pre>
==Abstract==
This BIP proposes a method to explicitly specify and sign the USD/BTC price
for transactions.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Certain parts of the community have been selling bitcoins for unreasonably low
prices. This has halted Bitcoin's valuation at $20k and even driven the price
down below $15k! However, clearly Bitcoin is worth much more than that, and
there is widespread support for higher prices.
This problem can be fixed by setting a global minimum price for bitcoins.
Unfortunately, today, the consensus protocol is completely oblivious to the
price bitcoins are traded at. Therefore, we must first add a field to Bitcoin
transactions to indicate their price.
==Specification==
===New field and legal implication===
A new field is added to Bitcoin transactions. This field, if present, must
represent the honest and true USD/BTC rate used for the transaction. By
signing the transaction, the sender legally affirms this is the valuation of
bitcoins used for the transaction.
For the avoidance of doubt: when the transaction is valued in a currency other
than USD, any reasonable exchange rate may be used to come up with the USD
valuation.
===Serialisation===
When serialising the transaction for any purpose, including signing, weight
calculation, and so on, the output count must be incremented by one. Prior to
the first real output, the following bytes must be inserted:
* Constant: 00 00 00 00 00 00 00 00
* A single byte, the size in bytes of the remainder of the inserted data
* Constant: 6a 04 55 53 44 24
* A single byte, the size in bytes of the remainder of the inserted data
* The USD/BTC rate used for the transaction, in standard signed integer
serialisation, with all leading zeros removed (except as necessary to
preserve the sign bit).
==Backwards compatibility==
===Consensus===
The new price field is serialised as a dummy output, with a value of zero, and
a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it
is never considered spendable.
Therefore, current nodes will ignore the new field entirely, and accept
transactions using it.
===Wallets===
Existing wallets do not typically generate price indicators as specified.
Under this BIP, this absence of the field is perfectly acceptable.
==Reference implementation==
https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
<pre>
BIP: ?
Layer: Consensus (soft fork)
Title: $50k USD/BTC Minimum Price
Author: Luke Dashjr <luke+bip at dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Standards Track
Created: 2019-04-01
License: BSD-2-Clause
Requires: usdprice
</pre>
==Abstract==
This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Certain parts of the community have been selling bitcoins for unreasonably low
prices. This has halted Bitcoin's valuation at $20k and even driven the price
down below $15k! However, clearly Bitcoin is worth much more than that, and
there is widespread support for higher prices.
bip-usdprice defines a new field to indicate the price of transactions. Using
this, we can softfork to require a minimum transaction price.
==Specification==
Beginning with block height 622370 (expected approximately 2020 April 1), a
block is reject as invalid unless all transactions it contains both declare a
USD/BTC price (as defined in bip-usdprice) and specify a price that is at a
minimum $50k USD/BTC.
==Backwards compatibility==
As a soft fork, older nodes will continue to accept the blockchain without
modification. Non-upgraded nodes, however, will not validate the minimum
price requirement, and may accept invalid blocks if miners choose to make
them. Since transactions not declaring a price are at this time still
common-place, the softfork activation has been set a full year into the
future to ensure time to upgrade both nodes and wallet software.
==Reference implementation==
https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k

2023-06-07 18:16:44

- reply

📅 Original date posted:2019-03-07
📝 Original message:On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote:
> I'd like to ask the BIP editor to assign a BIP number.
Needs a Backward Compatibility section, and should have a bips repo PR opened
after discussion on the ML.
> * The 4th change (making non-standard signature hash types invalid)
> may be worth discussing. In order to limit the number of potential
> signature hashes which could be used per-input (allowing us to cache
> them to avoid re-calculation), we can disable non-standard sighash
> types. Alternatively, however, most of the same effect could be achieved
> by caching the just-before-the-last-byte sighash midstate and hashing
> only the last byte when a checking signatures. Still, them having been
> non-standard for many years makes me doubt there is much risk involved
> in disabling them, and I don't see much potential use-case for keeping
> them around so I'd like to just remove them.
I don't understand what is being removed here.
> As for why the timewarp vulnerability should (IMO rather obviously) be
> fixed, it seems rather clear that the only potential use for exploiting
> it would be either to inflate the currency supply maliciously by miners
> or to fork in what amounts to extension blocks. As for why extension
> blocks are almost certainly not the right approach to such changes, its
> likely worth reading this old post:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510
>.html
While I agree that extension blocks are typically a bad choice, I'm not sure
the argument really applies to forward blocks. (That being said, I find
forward blocks overcomplicated and probably not a reason to avoid this.)
> * Transactions smaller than 65 bytes when serialized without witness
> data are invalid.
Rationale should include the reason(s) why the size doesn't count the witness
here.
> ** Note that miners today only enforce increasing timestamps against the
> median-timestamp-of-last-11-blocks, so miners who do not upgrade may
> mine a block which violates this rule at the beginning of a difficulty
> window if the last block in a difficulty window has a timestamp in the
> future. Thus, it is strongly recommended that SPV clients enforce the
> new nTime rules to avoid following any potential forks which occur.
This should probably be moved outside Discussion. (Perhaps to the missing
Backward Compatibility section?)
> * There are several early-stage proposals which may affect the execution
> of scripts, including proposals such as Schnorr signatures, Taproot,
> Graftroot, and MAST. These proposals are not expected to have any
> interaction with the changes in this BIP, as they are likely to only
> apply to SegWit scripts, which are not covered by any of the new rules
> except for the sighash type byte rule. Thus, the sighash type byte rule
> defined above only applies to *current* signature-checking opcodes, as
> any new signature-checking is likely to be implemented via the
> introduction of new opcodes.
It's not clear that new opcodes will necessarily always be used. Probably
would be good to clarify the "non-Segwit or witness v0 only" rule in the
Specification section.
Luke

2023-06-07 18:16:28

- reply

📅 Original date posted:2019-02-15
📝 Original message:On Tuesday 29 January 2019 22:03:04 Steven Roose via bitcoin-dev wrote:
> The existence of the first input (which is just a commitment hash) ensures
> that this transaction is invalid and can never be confirmed.
But nodes can never prove the transaction is invalid, thus if sent it, they
will likely cache the "transaction", taking up memory. I'm not sure if this
is an actual problem, as an attacker can fabricate such transactions anyway.
> #:Not all systems that will be used for verification have access to a full
> index of all transactions. However, proofs should be easily verifiable
> even after some of the UTXOs used in the proof are no longer unspent.
> Metadata present in the proof allows for relatively efficient verification
> of proofs even if no transaction index is available.
I don't see anything in the format that would prove unspentness...
> The proposed proof-file format provides a standard way of combining
> multiple proofs and associated metadata. The specification of the format
> is in the Protocol
> Buffers<ref>https://github.com/protocolbuffers/protobuf/</ref> format.
IIRC, this has been contentious for its use in BIP70 and may hinder adoption.
> message OutputMeta {
> // Identify the outpoint.
> bytes txid = 1;
> uint32 vout = 2;
>
> // The block hash of the block where this output was created.
> bytes block_hash = 3;
This isn't really sufficient. There should probably be a merkle proof.
Luke

2023-06-07 18:16:15

- reply

📅 Original date posted:2019-02-19
📝 Original message:On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> While this seems fully compatible with eltoo, is there any other proposals
> require NOINPUT, and is adversely affected by either way of tagging?
Yes, this seems to break the situation where a wallet wants to use NOINPUT for
everything, including normal L1 payments. For example, in the scenario where
address reuse will be rejected/ignored by the recipient unconditionally, and
the payee is considered to have burned their bitcoins by attempting it.
Luke

2023-06-07 18:16:15

- reply

📅 Original date posted:2019-02-19
📝 Original message:Even besides NOINPUT, such a wallet would simply never show a second payment
to the same address (or at least never show it as confirmed, until
successfully spent).
At least if tx versions are used, it isn't possible to indicate this
requirement in current Bitcoin L1 addresses. scriptPubKey might not be
impossible to encode, but it isn't really clear what the purpose of doing so
is.
If people don't want to use NOINPUT, they should just not use it. Trying to
implement a nanny in the protocol is inappropriate and limits what developers
can do who actually want the features.
Luke
On Tuesday 19 February 2019 19:22:07 Johnson Lau wrote:
> This only depends on the contract between the payer and payee. If the
> contract says address reuse is unacceptable, it’s unacceptable. It has
> nothing to do with how the payee spends the coin. We can’t ban address
> reuse at protocol level (unless we never prune the chain), so address reuse
> could only be prevented at social level.
>
> Using NOINPUT is also a very weak excuse: NOINPUT always commit to the
> value. If the payer reused an address but for different amount, the payee
> can’t claim the coin is lost due to previous NOINPUT use. A much stronger
> way is to publish the key after a coin is well confirmed.
>
> > On 20 Feb 2019, at 3:04 AM, Luke Dashjr <luke at dashjr.org> wrote:
> >
> > On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> >> While this seems fully compatible with eltoo, is there any other
> >> proposals require NOINPUT, and is adversely affected by either way of
> >> tagging?
> >
> > Yes, this seems to break the situation where a wallet wants to use
> > NOINPUT for everything, including normal L1 payments. For example, in the
> > scenario where address reuse will be rejected/ignored by the recipient
> > unconditionally, and the payee is considered to have burned their
> > bitcoins by attempting it.
> >
> > Luke

2023-06-07 18:14:02

- reply

📅 Original date posted:2018-08-15
📝 Original message:On Thursday 16 August 2018 02:22:21 Lautaro Dragan wrote:
> > Choosing not to mine transactions is not censorship.
>
> Is it not, if for political rather than economical reasons? These
> transactions pay fees like any other.
Miners have always chosen transaction on "political" basises, and doing such
is their right. That's why the system is supposed to be comprised of many
miners, all with their own policies - so the choices of one do not impact the
overall ability to spend (presumably only spam should be rejected by all
miners).
For fees to themselves justify the cost of a transaction, they would need to
be magnitudes higher than we've ever seen on Bitcoin. But even then, nobody
has an obligation to accept payment, no matter how reasonable it is, for a
service they don't want to provide.
Luke

2023-06-07 18:14:01

- reply

📅 Original date posted:2018-08-15
📝 Original message:On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev wrote:
> On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Can a miner identify which transactions came from your software simply by
> > running a copy themselves? If so, then they can censor your transactions
> > no matter how you encode them.
>
> Possibly, but in the IPFS case I suspect the latency required to inspect
> all hashes would likely impact the ability of the miner to succeed in the
> block. (True? I don’t touch mining software.)
Not true at all.
> Thus as long as all hashes look the same, and there are multiple content
> addressable schemes that use hashes that have to be searched in order to
> know to censor, you have to censor all or none.
Choosing not to mine transactions is not censorship.
Luke

2023-06-07 18:13:59

- reply

📅 Original date posted:2018-08-05
📝 Original message:Are you doing coloured coins or storing data?
If the former, you should probably collaborate with the authors of BIP 160
(yet to be added to the main repo), and/or write a new BIP if BIP 160 is
insufficient for some reason.
If the latter, you just shouldn't do it at all.
Note that BIPs need to specify an actual protocol, not just claim a prefix.
On Sunday 05 August 2018 21:11:26 Lautaro Dragan via bitcoin-dev wrote:
> Hi everyone,
>
> My name's Lautaro and I'm currently acting as Tech Lead of Po.et
> <https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we use
> colored coins
> <https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e
>84c/src/BlockchainWriter/ClaimController.ts#L101-L110> to
> store data on the Bitcoin blockchain with prefix "POET".
>
> I've read in an old version of the OP_RETURN entry of the bitcoin wiki
> <https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
> *protocols wishing to claim OP_RETURN prefixes should use the standard
> Bitcoin Improvement Proposals process*.
>
> That entry seems to have changed recently
> <https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
> stating that we should follow the BIP process, and I haven't been able to
> find any existing BIP claiming an OP_RETURN prexif, but for the sake of
> thoroughness I'd like to ask for your help or confirmation here.
>
> Should we actually be using the BIP process to claim a prefix?
>
> Thanks in advance,
>
> Lautaro

2023-06-07 18:13:26

- reply

📅 Original date posted:2018-07-03
📝 Original message:On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional applications where a third party might pay to
> an address a second time, and should only be used in special protocols
> which make that kind of mistake unlikely.
I don't agree. Address reuse is undefined behaviour. Nobody should assume it
is safe or works.
I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in
a wallet I am writing, which explicitly does not support address reuse.
Luke