Nostr notes by

📅 Original date posted:2023-08-02 🗒️ Summary of this ...

2023-08-03T19:31:03+02:00

In reply to nevent1q…rk6z
_________________________

📅 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>;

📅 Original date posted:2021-10-04 📝 Original message: On ...

2023-06-09T15:03:59+02:00

In reply to nevent1q…6jfx
_________________________

📅 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)

📅 Original date posted:2021-10-04 📝 Original message: On ...

2023-06-09T15:03:58+02:00

In reply to nevent1q…npy8
_________________________

📅 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

📅 Original date posted:2020-05-05 📝 Original message: On ...

2023-06-09T15:00:06+02:00

In reply to nevent1q…g4zc
_________________________

📅 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

📅 Original date posted:2021-06-30 📝 Original message: Or ...

2023-06-09T14:40:22+02:00

In reply to nevent1q…wl9d
_________________________

📅 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

📅 Original date posted:2023-03-02 🗒️ Summary of this ...

2023-06-08T01:20:16+02:00

In reply to nevent1q…q30w
_________________________

📅 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

📅 Original date posted:2022-10-27 📝 Original message:More ...

2023-06-08T01:15:56+02:00

In reply to nevent1q…xgy6
_________________________

📅 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

📅 Original date posted:2022-10-07 📝 Original message:On ...

2023-06-08T01:14:26+02:00

In reply to nevent1q…76vd
_________________________

📅 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

📅 Original date posted:2022-06-14 📝 Original ...

2023-06-08T01:10:28+02:00

In reply to nevent1q…9j42
_________________________

📅 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.

📅 Original date posted:2022-04-20 📝 Original message:1-2 ...

2023-06-08T01:07:32+02:00

In reply to nevent1q…d2gx
_________________________

📅 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

📅 Original date posted:2021-11-11 📝 Original ...

2023-06-08T01:00:33+02:00

In reply to nevent1q…lech
_________________________

📅 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>;

📅 Original date posted:2021-09-09 📝 Original ...

2023-06-08T00:59:08+02:00

In reply to nevent1q…x6hy
_________________________

📅 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

📅 Original date posted:2021-06-29 📝 Original message:The ...

2023-06-08T00:55:31+02:00

In reply to nevent1q…d4ml
_________________________

📅 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

📅 Original date posted:2021-06-26 📝 Original message:BIP8 ...

2023-06-08T00:55:24+02:00

In reply to nevent1q…jajm
_________________________

📅 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

📅 Original date posted:2021-04-25 📝 Original message:On ...

2023-06-08T00:52:10+02:00

In reply to nevent1q…4sad
_________________________

📅 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

📅 Original date posted:2021-04-22 📝 Original message:Unless ...

2023-06-08T00:52:03+02:00

In reply to nevent1q…ap3c
_________________________

📅 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

📅 Original date posted:2021-02-28 📝 Original message:On ...

2023-06-07T20:29:17+02:00

In reply to nevent1q…hw9t
_________________________

📅 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

📅 Original date posted:2020-03-04 📝 Original message:In ...

2023-06-07T20:23:15+02:00

In reply to nevent1q…2jgk
_________________________

📅 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

📅 Original date posted:2019-11-08 📝 Original ...

2023-06-07T20:21:39+02:00

In reply to nevent1q…pdh0
_________________________

📅 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.

📅 Original date posted:2019-05-06 📝 Original message:There ...

2023-06-07T20:17:58+02:00

In reply to nevent1q…agl6
_________________________

📅 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,

📅 Original date posted:2019-04-29 📝 Original message:On ...

2023-06-07T20:17:50+02:00

In reply to nevent1q…x6sv
_________________________

📅 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

📅 Original date posted:2019-04-03 📝 Original message:This ...

2023-06-07T20:17:26+02:00

In reply to nevent1q…ahls
_________________________

📅 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

📅 Original date posted:2019-04-03 📝 Original message:On ...

2023-06-07T20:17:25+02:00

In reply to nevent1q…hr5h
_________________________

📅 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

📅 Original date posted:2019-04-04 📝 Original message:On ...

2023-06-07T20:17:24+02:00

In reply to nevent1q…7qls
_________________________

📅 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

📅 Original date posted:2018-08-05 📝 Original message:Are ...

2023-06-07T20:13:59+02:00

In reply to nevent1q…s6nc
_________________________

📅 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

📅 Original date posted:2018-05-09 📝 Original message:An ...

2023-06-07T20:11:57+02:00

In reply to nevent1q…7s52
_________________________

📅 Original date posted:2018-05-09
📝 Original message:An OP_TRUE-only script with a low value seems like a good example of where the
weight doesn't reflect the true cost: it uses a UTXO forever, while only
costing a weight of 4.

I like Johnson's idea to have some template (perhaps OP_2-only, to preserve
expected behaviour of OP_TRUE-only) that when combined with a 0-value is
always valid only if spent in the same block.

I wonder if it would make sense to actually tie it to a transaction version
bit, such that when the bit is set, the transaction is serialised with +1 on
the output count and 00000000000000000181 is simply injected into the
transaction hashing... But for now, simply having a consensus rule that a bit
MUST be set for the expected behaviour, and the bit may ONLY be set when the
last output is exactly 00000000000000000181, would allow us to code the
transaction serialisation up later. (Maybe it should be the first output
instead of the last... Is there any legitimate reason one would have multiple
such dummy outputs?)

Luke

On Tuesday 08 May 2018 23:57:11 Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> The largest problem we are having today with the lightning
> protocol is trying to predict future fees. Eltoo solves this elegantly,
> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> commitment transactions so that we use minimal fees and then use CPFP
> (which can't be done at the moment due to CSV delays on outputs).
>
> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> non-standard. Are there any reasons not to suggest such a policy
> change?
>
> Thanks!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2017-10-01 📝 Original message:On ...

2023-06-07T20:06:47+02:00

In reply to nevent1q…7h9s
_________________________

📅 Original date posted:2017-10-01
📝 Original message:On Sunday 01 October 2017 8:39:11 PM Mark Friedenbach wrote:
> What about an optional commitment to witness size in bytes? The value zero
> meaning “I don’t care.” I would argue that it should be a maximum however,
> and therefor serialized as part of the witness. The serialization of this
> would be very compact (1 plus the difference between actual and maximum,
> with zero meaning not used.)

Could just do SIGHASH_WITNESS_SIZE in addition to SIGHASH_WITNESS_DEPTH...

📅 Original date posted:2017-09-30 📝 Original message:Should ...

2023-06-07T20:06:45+02:00

In reply to nevent1q…5mpa
_________________________

📅 Original date posted:2017-09-30
📝 Original message:Should it perhaps commit to the length of the serialised witness data instead
or additionally? Now that signatures are no longer variable-length, that'd be
possible...

As far as tail-call needs are concerned, CLEANSTACK wouldn't have been checked
until AFTER the tail-call in the first draft. But I suppose eliminating it for
other possible future purposes is still useful.

Luke

On Sunday 01 October 2017 2:23:47 AM Mark Friedenbach wrote:
> The CLEANSTACK rule should be eliminated, and instead the number of items
> on the stack should be incorporated into the signature hash. That way any
> script with a CHECKSIG is protected from witness extension malleability,
> and those rare ones that do not use signature operations can have a “DEPTH
> 1 EQUALVERIFY” at the end. This allows for much simpler tail-call
> evaluation as you don’t need to pass arguments on the alt-stack.
>
> > On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > I've put together a first draft for what I hope to be a good next step
> > for
> >
> > Segwit and Bitcoin scripting:
> > https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki
> >
> > This introduces 5 key changes:
> >
> > 1. Minor versions for witnesses, inside the witness itself. Essentially
> > the witness [major] version 1 simply indicates the witness commitment is
> > SHA256d, and nothing more.
> >
> > The remaining two are witness version 1.0 (major 1, minor 0):
> >
> > 2. As previously discussed, undefined opcodes immediately cause the
> > script to exit with success, making future opcode softforks a lot more
> > flexible.
> >
> > 3. If the final stack element is not exactly true or false, it is
> > interpreted as a tail-call Script and executed. (Credit to Mark
> > Friedenbach)
> >
> > 4. A new shorter fixed-length signature format, eliminating the need to
> > guess the signature size in advance. All signatures are 65 bytes, unless
> > a condition script is included (see #5).
> >
> > 5. The ability for signatures to commit to additional conditions,
> > expressed in the form of a serialized Script in the signature itself.
> > This would be useful in combination with OP_CHECKBLOCKATHEIGHT (BIP
> > 115), hopefully ending the whole replay protection argument by
> > introducing it early to Bitcoin before any further splits.
> >
> > This last part is a big ugly right now: the signature must commit to the
> > script interpreter flags and internal "sigversion", which basically serve
> > the same purpose. The reason for this, is that otherwise someone could
> > move the signature to a different context in an attempt to exploit
> > differences in the various Script interpretation modes. I don't consider
> > the BIP deployable without this getting resolved, but I'm not sure what
> > the best approach would be. Maybe it should be replaced with a witness
> > [major] version and witness stack?
> >
> > There is also draft code implementing [the consensus side of] this:
> > https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
> >
> > Thoughts? Anything I've overlooked / left missing that would be
> > uncontroversial and desirable? (Is any of this unexpectedly controversial
> > for some reason?)
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2017-09-30 📝 Original ...

2023-06-07T20:06:44+02:00

In reply to nevent1q…cmsx
_________________________

📅 Original date posted:2017-09-30
📝 Original message:I've put together a first draft for what I hope to be a good next step for
Segwit and Bitcoin scripting:
https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki

This introduces 5 key changes:

1. Minor versions for witnesses, inside the witness itself. Essentially the
witness [major] version 1 simply indicates the witness commitment is SHA256d,
and nothing more.

The remaining two are witness version 1.0 (major 1, minor 0):

2. As previously discussed, undefined opcodes immediately cause the script to
exit with success, making future opcode softforks a lot more flexible.

3. If the final stack element is not exactly true or false, it is interpreted
as a tail-call Script and executed. (Credit to Mark Friedenbach)

4. A new shorter fixed-length signature format, eliminating the need to guess
the signature size in advance. All signatures are 65 bytes, unless a condition
script is included (see #5).

5. The ability for signatures to commit to additional conditions, expressed in
the form of a serialized Script in the signature itself. This would be useful
in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the
whole replay protection argument by introducing it early to Bitcoin before any
further splits.

This last part is a big ugly right now: the signature must commit to the
script interpreter flags and internal "sigversion", which basically serve the
same purpose. The reason for this, is that otherwise someone could move the
signature to a different context in an attempt to exploit differences in the
various Script interpretation modes. I don't consider the BIP deployable
without this getting resolved, but I'm not sure what the best approach would
be. Maybe it should be replaced with a witness [major] version and witness
stack?

There is also draft code implementing [the consensus side of] this:
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1

Thoughts? Anything I've overlooked / left missing that would be
uncontroversial and desirable? (Is any of this unexpectedly controversial for
some reason?)

Luke

📅 Original date posted:2017-09-19 📝 Original message:On ...

2023-06-07T20:05:38+02:00

In reply to nevent1q…7yk9
_________________________

📅 Original date posted:2017-09-19
📝 Original message:On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
wrote:
> After the main discussion session it was observed that tail-call semantics
> could still be maintained if the alt stack is used for transferring
> arguments to the policy script.

Isn't this a bug in the cleanstack rule?

(Unrelated...)

Another thing that came up during the discussion was the idea of replacing all
the NOPs and otherwise-unallocated opcodes with a new OP_RETURNTRUE
implementation, in future versions of Script. This would immediately exit the
program (perhaps performing some semantic checks on the remainder of the
Script) with a successful outcome.

This is similar to CVE-2010-5141 in a sense, but since signatures are no
longer Scripts themselves, it shouldn't be exploitable.

The benefit of this is that it allows softforking in ANY new opcode, not only
the -VERIFY opcode variants we've been doing. That is, instead of merely
terminating the Script with a failure, the new opcode can also remove or push
stack items. This is because old nodes, upon encountering the undefined
opcode, will always succeed immediately, allowing the new opcode to do
literally anything from that point onward.

Luke

📅 Original date posted:2017-09-05 📝 Original message:On ...

2023-06-07T20:05:21+02:00

In reply to nevent1q…vhfh
_________________________

📅 Original date posted:2017-09-05
📝 Original message:On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev wrote:
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.
> However, the very existence of version bytes, and the fact that they are
> used to signal whether keys will be used on testnet or mainnet goes
> against that argument.
>
> If we do not signal the script type in the version bytes, I believe
> wallet developers are going to use dirtier tricks, such as the bip32
> child number field in combination with bip43/bip44/bip49.

I think it makes more sense to use a child number field for this purpose.
It seems desirable to use the same seed for all different script formats...

As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
really doesn't make sense to differentiate segwit specifically.

Luke

📅 Original date posted:2017-08-16 📝 Original message:To ...

2023-06-07T20:04:49+02:00

In reply to nevent1q…gk53
_________________________

📅 Original date posted:2017-08-16
📝 Original message:To have a BIP, you need to explain not only *why* you want to do something,
but also *what specifically* to do, and *how* to do it. This concept
(historically known as "flip the chain" and/or "UTXO commitments") is not new,
merely complicated to design and implement.

Luke

On Wednesday 16 August 2017 4:20:45 PM Алексей Мутовкин via bitcoin-dev wrote:
> Let me describe the possible improvement of the bitcoin blockchain database
> (BBD) size in general terms.
>
> We can implement new routine : annual split of the BBD. Reason is that
> 140gb full wallet unconvinience.
>
> BBD splits in two parts :
> 1) old blocks before the date of split and
> 2) new blocks, starting from first technical block with all rolled totals
> on the date of split.
> (also possible transfer of tiny totals due to their unprofitability to
> the miners, so we cut long tail of tiny holders)
> 3) old blocks packs into annual megablocks and stores in the side archive
> chain for some needs for FBI investigations or other goals.
>
>
> Thanks for your attention,
>
> Alexey Mutovkin

📅 Original date posted:2017-07-07 📝 Original message:> ...

2023-06-07T20:04:03+02:00

In reply to nevent1q…9q60
_________________________

📅 Original date posted:2017-07-07
📝 Original message:> Maximum transaction size is kept, to maximize compatibility with current
> software and prevent algorithmic and data size DoS's.

IIRC, it is actually increased by ~81 bytes, and doesn't count witness data if
on Segwit transactions (so in effect, nearly 4 MB transactions are possible).
This probably doesn't make the hashing problem worse, however it should be
made clear in the BIP.

> Assuming the current transaction pattern is replicated in a 2 MB
> plain-sized block that is 100% filled with transactions, then the
> witness-serialized block would occupy 3.6 MB [1]. This is considered safe
> by many users, companies, miners and academics [2].

Citations do not support the claim.

> The plain block size is defined as the serialized block size without
> witness programs.

This is deceptive and meaningless. There is no reason to *ever* refer to the
size of the block serialised without witness programs. It is not a meaningful
number.

> Deploy a modified BIP91 to activate Segwit. The only modification is that
> the signal "segsignal" is replaced by "segwit2x".

What is modified here? "segsignal" does not appear in the BIP 91 protocol at
all...

> If segwit2x (BIP91 signal) activates at block N, then block N+12960
> activates a new plain block size limit of 2 MB (2,000,000 bytes). In this
> case, at block N+12960 a hard-fork occurs.

A "plain block size limit" of 2 MB would be a no-op. It would have literally
no effect whatsoever on the network rules.

Furthermore, this does not match what btc1/Segwit2x currently implements at
all. The actual implementation is: If Segwit (via deployment method) activates
at block N, then block N+12960 activates a new weight limit of 8M (which
corresponds to a size of up to 8,000,000 bytes).

> Any transaction with a non-witness serialized size exceeding 1,000,000 is
> invalid.

What is the rationale for excluding witness data from this measurement?

> In the short term, an increase is needed to continue to facilitate network
> growth, and buy time...

Actual network growth does not reflect a pattern that supports this claim.

> This reduces the fee pressure on users and companies creating on-chain
> transactions, matching market expectations and preventing further market
> disruption.

Larger block sizes is not likely to have a meaningful impact on fee pressure.
Any expectations that do not match the reality are merely misguided, and
should not be a basis for changing Bitcoin.

Luke

📅 Original date posted:2017-05-23 📝 Original message:In ...

2023-06-07T20:01:47+02:00

In reply to nevent1q…nfgp
_________________________

📅 Original date posted:2017-05-23
📝 Original message:In light of some recent discussions, I wrote up this BIP for a real 2 MB block
size hardfork following Segwit BIP148 activation. This is not part of any
agreement I am party to, nor anything of that sort. Just something to throw
out there as a possible (and realistic) option.

Note that I cannot recommend this to be adopted, since frankly 1 MB blocks
really are still too large, and this blunt-style hardfork quite risky even
with consensus. But if the community wishes to adopt (by unanimous consensus)
a 2 MB block size hardfork, this is probably the best way to do it right now.
The only possible way to improve on this IMO would be to integrate it into
MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size HF
improvements).

I have left Author blank, as I do not intend to personally champion this.
Before it may be assigned a BIP number, someone else will need to step up to
take on that role. Motivation and Rationale are blank because I do not
personally think there is any legitimate rationale for such a hardfork at this
time; if someone adopts this BIP, they should complete these sections. (I can
push a git branch with the BIP text if someone wants to fork it.)

<pre>
BIP: ?
Layer: Consensus (hard fork)
Title: Post-segwit 2 MB block size hardfork
Author: FIXME
Comments-Summary: No comments yet.
Comments-URI: ?
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-2-Clause
</pre>

==Abstract==

Legacy Bitcoin transactions are given the witness discount, and a block size
limit of 2 MB is imposed.

==Copyright==

This BIP is licensed under the BSD 2-clause license.

==Specification==

Upon activation, a block size limit of 2000000 bytes is enforced.
The block weight limit remains at 4000000 WU.

The calculation of block weight is modified:
all witness data, including both scriptSig (used by pre-segwit inputs) and
segwit witness data, is measured as 1 weight-unit (WU), while all other data
in the block is measured as 4 WU.

The witness commitment in the generation transaction is no longer required,
and instead the txid merkle root in the block header is replaced with a hash
of:

1. The witness reserved value.
2. The witness merkle root hash.
3. The transaction ID merkle root hash.

The maximum size of a transaction stripped of witness data is limited to 1 MB.

===Deployment===

This BIP is deployed by flag day, in the block where the median-past time
surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).

It is assumed that when this flag day has been reached, Segwit has been
activated via BIP141 and/or BIP148.

==Motivation==

FIXME

==Rationale==

FIXME

==Backwards compatibility==

This is a hardfork, and as such not backward compatible.
It should not be deployed without consent of the entire Bitcoin community.
Activation is scheduled for 18 months from the creation date of this BIP,
intended to give 6 months to establish consensus, and 12 months for
deployment.

==Reference implementation==

FIXME

📅 Original date posted:2017-05-13 📝 Original message:On ...

2023-06-07T20:01:09+02:00

In reply to nevent1q…e36c
_________________________

📅 Original date posted:2017-05-13
📝 Original message:On Saturday 13 May 2017 12:48:48 PM Peter Todd wrote:
> > You assume users will pay for signalling of softforks prematurely. So
> > long as it waits until deployment of the softfork is widespread, this
> > risk is minimal. At worst, it creates risks similar to a UASF. So long
> > as UASF is the alternative, this way seems strictly better.
>
> I think you're assuming that the users paying for soft-fork signalling will
> represent an economic majority; that's not necessarily the case.

I'm assuming that if the economic majority hasn't consented to the softfork,
at least as many users will make their transactions conditional on non-
signalling.

📅 Original date posted:2017-05-13 📝 Original message:On ...

2023-06-07T20:01:08+02:00

In reply to nevent1q…3896
_________________________

📅 Original date posted:2017-05-13
📝 Original message:On Saturday 13 May 2017 3:26:08 AM Eric Voskuil wrote:
> If people want to influence the decisions of miners, all they need to
> do is mine.

Most people cannot mine except at a huge expense (profit is limited to few
people via monopoly and electric costs). But more importantly, the profits
from every miner you buy will go to pay for Bitmain growing their arsenal more
than enough to offset your influence.

Mining is simply broken at this point.

> There is nothing inherently wrong with paying people to run nodes or
> signal "readiness", but there is no reason whatsoever to consider
> these ideas beneficial from a personal/economic or
> security/decentralization standpoint.

Running a node and mining are two very different things.

> The argument fails to recognize that mining for one's self may (or may
> not) result in a net loss, but donating to a miner in the hope of some
> action is comparatively a total loss. One is an expense in exchange
> for the intended social outcome, and the other is payment for
> representative government.
>
> And in this form of representative government that you propose, if we
> assume that miners are somehow bound to honor the payments (votes), ...

First of all, this isn't donating to miners, but forbidding them from mining
your transaction (and thereby collecting your transaction fee) unless they
signal for the softfork.

Secondly, your argument here assumes miners are a government or control
Bitcoin in some way. This is not correct. Miners are entrusted with
enforcement of softforks *for old nodes only*, and therefore given the ability
to trigger activation of the new rules via signalling. But entrusting them
with this is NOT done by the system itself, but by the users, whose updated
nodes are the primary mechanism for enforcing softforks. So miners are in fact
already bound to honour the wishes of the greater economy, and their refusal
to do so is an attack on the network.

Luke

📅 Original date posted:2017-05-12 📝 Original message:On ...

2023-06-07T20:01:07+02:00

In reply to nevent1q…nsu9
_________________________

📅 Original date posted:2017-05-12
📝 Original message:On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
> nVersion signaling is already technically unenforceable, in the sense that
> we don't have good ways of ensuring miners actually adopt the rules
> they're claiming to signal. Equally, it's users who ultimately adopt
> rules, not miners, and attempting to pay miners to signal certain bits
> will further confuse this point.

This BIP doesn't change that. Enforcement remains primarily by users.

> Quite likely the outcome of users trying to anonymously pay anonymous
> miners to signal certain bits will be the complete breakdown of the
> honesty of the nVersion signalling system, currently enforced only by
> "gentlemans agreement".

You assume users will pay for signalling of softforks prematurely. So long as
it waits until deployment of the softfork is widespread, this risk is minimal.
At worst, it creates risks similar to a UASF. So long as UASF is the
alternative, this way seems strictly better.

> Also, as an aside, this "specification" again shows the inadequacy and
> unreadability of English language specifications. I'd strongly suggest you
> delete it and instead mark the "reference implementation" as the
> specification.

How so?

On Friday 12 May 2017 10:17:30 PM ZmnSCPxj wrote:
> Minor editorial nitpick, this paragraph is repeated, maybe one of these
> should be Testnet?
>
> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch
> timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).
>
> For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch
> timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD).

Fixed, thanks.

Luke

📅 Original date posted:2017-05-12 📝 Original ...

2023-06-07T20:01:06+02:00

In reply to nevent1q…k2tj
_________________________

📅 Original date posted:2017-05-12
📝 Original message:I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the community
to put economic pressure on miners to deploy softforks without the extreme of
a UASF.

https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki

Due to the potential for miners to maliciously block this softfork, it is
suggested that we deploy it using BIP 8 to ensure it eventually activates even
if encountering hostility.

This is intended to be an alternative to BIP 8 in the long term.
It is NOT intended to make BIP 148 obsolete, given the timeframes involved.

An implementation is available (based on top of BIP 115's implementation):

https://github.com/luke-jr/bitcoin/compare/cbah...luke-jr:checkblockversion

Luke

📅 Original date posted:2017-05-23 📝 Original message:On ...

2023-06-07T20:00:40+02:00

In reply to nevent1q…sj0t
_________________________

📅 Original date posted:2017-05-23
📝 Original message:On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote:
> Essentially, if we make a potentially very harmful option easy to
> enable for users, we are putting them at risk, so yes, this is about
> protecting users of the base Bitcoin Core implementation.

In this case, NOT enforcing BIP148 puts users at more risk. Since devs are
divided in opinion, we should at the very least have an option to let users
decide one way or the other.

Luke

📅 Original date posted:2017-04-20 📝 Original message:Since ...

2023-06-07T20:00:32+02:00

In reply to nevent1q…qfty
_________________________

📅 Original date posted:2017-04-20
📝 Original message:Since BIP 141's version bit assignment will timeout soon, and needing renewal,
I was thinking it might make sense to make some minor tweaks to the spec for
the next deployment. These aren't critical, so it's perfectly fine if BIP 141
activates as-is (potentially with BIP 148), but IMO would be an improvement if
a new deployment (non-BIP148 UASF and/or new versionbit) is needed.

1. Change the dummy marker to 0xFF instead of 0. Using 0 creates ambiguity
with incomplete zero-input transactions, which has been a source of confusion
for raw transaction APIs. 0xFF would normally indicate a >32-bit input count,
which is impossible right now (it'd require a >=158 GB transaction) and
unlikely to ever be useful.

2. Relax the consensus rules on when witness data is allowed for an input.
Currently, it is only allowed when the scriptSig is null, and the scriptPubKey
being spent matches a very specific pattern. It is ignored by "upgrade-safe"
policy when the scriptPubKey doesn't match an even-more-specific pattern.
Instead, I suggest we allow it (in the consensus layer only) in combination
with scriptSig and with any scriptPubKey, and consider these cases to be
"upgrade-safe" policy ignoring.

The purpose of the second change is to be more flexible to any future
softforks. I consider it minor because we don't know of any possibilities
where it would actually be useful.

Thoughts?

Luke

📅 Original date posted:2017-04-08 📝 Original message:I ...

2023-06-07T19:59:45+02:00

In reply to nevent1q…mv2w
_________________________

📅 Original date posted:2017-04-08
📝 Original message:I think it might be important that the mandatory commitment expire as in
Greg's proposal - when we do eventually hardfork, it will be simpler to do in
a safe manner if such a commitment in the fake "old block" is not required.

I don't like your proposal because it allows ASICBoost. ASICBoost effectively
makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of entry to
new mining chip manufacturers, and gives a larger advantage to the miners able
to make use of it. Instead, IMO we should fix the vulnerability exploited by
ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change the
PoW to an algorithm that is more ASIC-friendly.

That being said, I don't think I would oppose the proposal if it gained
notably better support than Segwit currently has (as yet another compromise),
and the above concerns were addressed (eg, Bitfury and Canaan state they can
compete using ASICBoost and the patents are licensed freely to everyone).

Luke

On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote:
> I've gotten feedback from Adam Back that you actually don't need all 32
> bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
> the 32-bit version field, bits 16 to 23 are reserved for miners, the
> witness commitment stays as defined in BIP-141 except that it's now
> required. BIP9 then is modified so that bits 16 to 23 are now no longer
> usable.
>
> On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon at gmail.com> wrote:
> > Hey everyone, This is an idea that I had about Segwit and Gregory's
> > proposal from yesterday that I wanted to run by everyone on this list.
> > I'm not at all sure what this would mean for non-upgraded nodes on the
> > network and would like feedback on that. This is not a formal BIP as
> > it's a modification to a previously submitted one, but I'm happy to
> > formalize it if it would help.
> > ----------------------------------------
> > MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is
> > that it only precludes the covert version of ASICBoost. He specifically
> > left the overt version alone.
> >
> > Overt ASICBoost requires grinding on the version bits of the Block header
> > instead of the Merkle Root. This is likely more efficient than the Merkle
> > Root grinding (aka covert ASICBoost) and requires way less resources
> > (much less RAM, SHA256 calculations, no tx shuffling, etc).
> >
> > If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
> > slight modification, this should, in theory, make ASICBoost a lot more
> > useful to miners and appeal to their financial interests.
> > The Modification
> >
> > Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> > are used for BIP9 signaling. We change the version bits to a nonce-space
> > so the miners can use it for overt ASICBoost. The 32-bits are now moved
> > over to the Coinbase transaction as part of the witness commitment. The
> > witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
> > being used as the version bits in the block header previously. The
> > witness commitment becomes required as per Gregory Maxwell’s proposal.
> > Reasoning
> >
> > First, this brings ASICBoost out into the open. Covert ASICBoost becomes
> > much more costly and overt ASICBoost is now encouraged.
> >
> > Second, we can make this change relatively quickly. Most of the Segwit
> > testing stays valid and this change can be deployed relatively quickly.
> >
> > Note on SPV clients
> >
> > Currently Segwit stores the witness commitment in the Coinbase tx, so
> > lightweight clients will need to get the Coinbase tx + Merkle proof to
> > validate segwit transactions anyway. Putting block version information in
> > the Coinbase tx will not impose an extra burden on upgraded light
> > clients.

📅 Original date posted:2017-03-28 📝 Original message:On ...

2023-06-07T19:58:14+02:00

In reply to nevent1q…ndee
_________________________

📅 Original date posted:2017-03-28
📝 Original message:On Tuesday, March 28, 2017 8:53:30 PM Alphonse Pace via bitcoin-dev wrote:
> His demand (not suggestion) allows it without any safeguards.
>
> >This patch must be in the immediate next release of Bitcoin Core.
>
> That is not a suggestion.

I think it was probably a design requirement more than a demand. It makes
sense: if we're aiming to have a long lead time for a possible hardfork, we
want to get the lead time started ASAP. (It could perhaps have been
communicated clearer, but let's not read hostility into things when
unnecessary.)

Meta-topic: Can we try a little harder to avoid sequences of multiple brief
replies in a matter of minutes? Combine them to a single reply.

Luke

📅 Original date posted:2017-03-28 📝 Original message:On ...

2023-06-07T19:58:04+02:00

In reply to nevent1q…d39c
_________________________

📅 Original date posted:2017-03-28
📝 Original message:On Tuesday, March 28, 2017 5:34:23 PM Johnson Lau via bitcoin-dev wrote:
> You are probably not the first one nor last one with such idea. Actually,
> Luke wrote up a BIP with similar idea in mind:
>
> https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
> <https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki>;
>
> Instead of just lifting the block size limit, he also suggested to remove
> many other rules. I think he has given up this idea because it’s just too
> complicated.
> ...
> So if we really want to get prepared for a potential HF with unknown
> parameters, I’d suggest to set a time bomb in the client, which will stop
> processing of transactions with big warning in GUI. The user may still
> have an option to continue with old rules at their own risks.

Indeed, actually implementing hfprep proved to be overly complicated.

I like the idea of a time bomb that just shuts down the client after it
determine it's stale and refuses to start without an explicit override.
That should work no matter what the hardfork is, and gives us a good
expectation for hardfork timeframes.

> Or, instead of increasing the block size, we make a softfork to decrease
> the block size to 1kB and block reward to 0, activating far in the future.
> This is similar to the difficulty bomb in ETH, which will freeze the
> network.

I don't like this idea. It leaves the node open to attack from blocks actually
meeting the criteria. Maybe the absolute minimum as Jeremy suggested.

Luke

📅 Original date posted:2017-03-18 📝 Original message:On ...

2023-06-07T19:57:21+02:00

In reply to nevent1q…y5z2
_________________________

📅 Original date posted:2017-03-18
📝 Original message:On Saturday, March 18, 2017 3:23:16 PM Chris Stewart via bitcoin-dev wrote:
> There is inconvenience added here. You need to make a new email address,
> you need to make a new github account to submit the BIP.

GitHub doesn't allow people to have multiple accounts last I checked.

Luke

📅 Original date posted:2017-03-13 📝 Original message:On ...

2023-06-07T19:57:14+02:00

In reply to nevent1q…qxll
_________________________

📅 Original date posted:2017-03-13
📝 Original message:On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> pindex->GetMedianTimePast() <= 1510704000 &&
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> return state.DoS(2, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID,
> "bad-no-segwit");
> }
> }

I don't think this is actually BIP 9 compatible. Once activated, the bit loses
its meaning and should not be set. So you need to check that it hasn't locked-
in already...

Also, IMO this should tolerate as many as 5% minus one non-signalling blocks.

Disclaimer: This are technical suggestions, and do not imply endorsement of
the idea.

Luke

📅 Original date posted:2017-03-06 📝 Original message:On ...

2023-06-07T19:56:52+02:00

In reply to nevent1q…w68k
_________________________

📅 Original date posted:2017-03-06
📝 Original message:On Monday, March 06, 2017 5:37:24 AM Tim Ruffing via bitcoin-dev wrote:
> But ignoring this, the server should be authenticated at a
> minimum. Otherwise manipulating exchange rates seems to be a nice
> way for the attacker on the wire to make money...

HTTPS would be used for that. It's not something that needs to be at a higher
layer.

> Apart from that, my feeling is that it could be simplified. Is
> longpolling useful?

I would think so, at least for Bitcoin since rates can change significantly in
a short period of time (or can they anymore? I haven't really watched lately.)

> And is the historical rate thing really necessary for typical applications?

When displaying historical transactions, it doesn't really make sense to use
the current market rate, but rather the market rate at the time the payment
was made. While wallets might simply cache it with the transaction, it would
be perhaps nicer if it could be automatically restored for seed-only
recoveries. In any case, if a service/wallet doesn't want to provide/use
historical information, it can simply not implement that part.

> If yes, the client should be allowed to decide on which time scale the
> data should be. (tick, min, hour, day, ...) That goes together with
> clearly defining the type field (something like low, high, open, close,
> but without flexibility). Think of a candle-stick chart basically.

How is the current draft insufficient for this?

> Also, pushing may be more appropriate for "current" rates than polling.
> Then no polling interval is necessary. On the other hand, this adds
> complexity in other places, e.g., state.

Pushing is what longpolling does.

Luke

📅 Original date posted:2017-02-05 📝 Original message:My BIP ...

2023-06-07T19:56:02+02:00

In reply to nevent1q…9hsy
_________________________

📅 Original date posted:2017-02-05
📝 Original message:My BIP draft didn't make progress because the community opposes any block size
increase hardfork ever. Your version doesn't address the current block size
issues (ie, the blocks being too large). So you've retained the only certain-
DOA parts of my proposal, and removed the most useful part... I'm not sure the
point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense
to keep the BIP 9 deployment at all - either it gets consensus or it doesn't,
but miners have no part in deployment of it.

On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:
> Hello all,
>
> Many people have expressed discontent with Luke-jr's proposed block size
> BIP, in particular with the decrease in size that would occur if it were
> to be activated prior to 2024.
>
> I have decided to modify the proposal to instead begin the increase
> steps at the current 1000000 byte limit. The increases and the time spam
> of each increase will remain the same, just that the increase begins
> from 1000000 bytes instead of 300000 bytes.
>
> Furthermore, instead of a fixed schedule from a fixed point in time, the
> increases will instead be calculated off of the MTP of the activation
> block (the first block to be in the active state for this fork).
>
> While this proposal shares many of the same issues with the one it
> modifies, I hope that it will be slightly less controversial and can
> allow us to move forward with scaling Bitcoin.
>
> The full text of the proposal can be found at
> https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
> My implementation of it is available at
> https://github.com/achow101/bitcoin/tree/bip-blksize
>
>
> Andrew
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2016-12-10 📝 Original message:On ...

2023-06-07T19:54:43+02:00

In reply to nevent1q…zgtj
_________________________

📅 Original date posted:2016-12-10
📝 Original message:On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote:
> On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Something not yet done:
> > 1. The new merkle root algorithm described in the MMHF BIP
>
> Any new merkle algorithm should use a sum tree for partial validation and
> fraud proofs.

PR welcome.

> Is there something special about 216 bits? I guess at most 448 bits total
> means only one round of SHA256. 16 bits for flags would give 216 for each
> child.

See https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki#Merkle_tree_algorithm

But yes, the 448 bits total target is to optimise the tree-building.

> Even better would be to make the protocol extendable. Allow blocks to
> indicate new trees and legacy nodes would just ignore the extra ones. If
> Bitcoin supported that then the segregated witness tree could have been
> added as a easier soft fork.

It already is. This is a primary goal of the new protocol.

> The sum-tree could be added later as an extra tree.

Adding new trees means more hashing to validate blocks, so it'd be better to
keep it at a minimum.

Luke

📅 Original date posted:2016-12-14 📝 Original message:On ...

2023-06-07T19:54:42+02:00

In reply to nevent1q…dvmj
_________________________

📅 Original date posted:2016-12-14
📝 Original message:On Wednesday, December 14, 2016 11:01:58 AM Johnson Lau via bitcoin-dev wrote:
> There is no reason to use a timestamp beyond 4 bytes.

Actually, there is: lock times... my overflow solution doesn't have a solution
to that. :x

📅 Original date posted:2016-11-17 📝 Original message:On ...

2023-06-07T19:54:20+02:00

In reply to nevent1q…evud
_________________________

📅 Original date posted:2016-11-17
📝 Original message:On Wednesday, November 16, 2016 9:01:00 PM Peter Todd via bitcoin-dev wrote:
> So, conceptually, another way to deal with this is to hardcode a blockhash
> where we allow blocks in a chain ending with that blockhash to _not_ follow
> BIP65, up until that blockhash, and any blockchain without that blockhash
> must respect BIP65 for all blocks in the chain.
>
> This is a softfork: we've only added rules that made otherwise valid chains
> invalid, and at the same time we are still accepting large reorgs (albeit
> under stricter rules than before).
>
> I'd suggest we call this a exemption hash - we've exempted a particular
> blockchains from a soft-forked rule that we would otherwise enforce.

While this is technically a softfork, I think it may behave somewhat like a
hardfork if we're not careful. Particularly, is the chain up to the block
immediately before the checkpoint itself valid on its own, or does it simply
become retroactively valid when it hits that checkpoint?

P.S. Your PGP signature is invalid?

📅 Original date posted:2016-10-15 📝 Original message:BIP 2 ...

2023-06-07T19:53:59+02:00

In reply to nevent1q…xzjl
_________________________

📅 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

📅 Original date posted:2016-10-02 📝 Original message:On ...

2023-06-07T19:53:42+02:00

In reply to nevent1q…fcx5
_________________________

📅 Original date posted:2016-10-02
📝 Original message:On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote:
> Is this particular proposal encumbered by a licensing type, patent, or
> pending patent which would preclude it from being used in the bitcoin
> project? If not, you're wildly off topic.

I think that's the concern: we don't - and *can't* - know. Pending patents are
not publicly visible, as far as I am aware, and the BIP process does not
(presently) require any patent disclosure.

Of course, it is entirely possible to voluntarily provide a disclosure of
patents in the BIP (and ideally a free license to such patents, at least those
for the BIP). This is an alternative possibility to resolve patent concerns if
Rootstock is not prepared to adopt a defensive patent strategy in general
(yet?).

On Sunday, October 02, 2016 6:17:12 PM Russell O'Connor via bitcoin-dev wrote:
> If I understand this BIP correctly, the values pushed onto the stack by the
> OP_COUNT_ACKS operation depends on the ack and nack counts relative to the
> block that this happens to be included in.
>
> This isn't going to be acceptable. The validity of a transaction should
> always be monotone in the sense that if a transaction was acceptable in a
> given block, it must always be acceptable in any subsequent block, with the
> only exception being if one of the transaction's inputs get double spent.

I don't know if it's possible to implement decentralised sidechains without
"breaking" this rule. But I would argue that in this scenario, the only way it
would become invalid is the equivalent of a double-spend... and therefore it
may be acceptable in relation to this argument.

Luke

📅 Original date posted:2016-09-23 📝 Original message:In the ...

2023-06-07T19:53:34+02:00

In reply to nevent1q…whn9
_________________________

📅 Original date posted:2016-09-23
📝 Original message:In the innocent use case of this opcode, a double-spend has already occurred,
and this should be a strict improvement. In the non-innocent abuse of this
opcode, I don't see that it's any worse than simply double-spending.

Would this proposal be better or otherwise more acceptable, if a specified
height more recent than 100 blocks deep causes the script to fail? This would
increase delays in recovering the double-spend situation of course... but less
than 24h.

Luke

On Friday, September 23, 2016 1:43:15 PM Russell O'Connor wrote:
> I believe Bitcoin currently enjoys the property that during an "innocent"
> re-org, i.e. a reorg in which no affected transactions are being double
> spent, all affected transactions can always eventually get replayed, so
> long as the re-org depth is less than 100.
>
> My concern with this proposed operation is that it would destroy this
> property.
>
> On Fri, Sep 23, 2016 at 5:57 AM, Luke Dashjr via bitcoin-dev <
>
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
> > scripting system to address reissuing bitcoin transactions when the coins
> > they
> > spend have been conflicted/double-spent.
> >
> > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> >
> > Does this seem like a good idea/approach?
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2016-09-23 📝 Original message:This ...

2023-06-07T19:53:33+02:00

In reply to nevent1q…namg
_________________________

📅 Original date posted:2016-09-23
📝 Original message:This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
scripting system to address reissuing bitcoin transactions when the coins they
spend have been conflicted/double-spent.

https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki

Does this seem like a good idea/approach?

Luke

📅 Original date posted:2016-08-24 📝 Original message:On ...

2023-06-07T19:53:03+02:00

In reply to nevent1q…s324
_________________________

📅 Original date posted:2016-08-24
📝 Original message:On Wednesday, August 24, 2016 1:47:08 PM Andreas Schildbach via bitcoin-dev
wrote:
> FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
> wallets do not need to scan from the beginning of the blockchain.
>
> That doesn't mean BIP44 could not be final. There are some wallets that
> interoperate on that standard and that's fine.

Right. The Status doesn't depend on whether it is a good idea or not, only
whether or not people are de facto using it.

BIP 2's BIP Comments would have provided a place for Thomas and yourself to
criticise the BIP, but unfortunately this was too controversial.

> I think BIP43 should be made final as well, if it isn't already.

BIP 43 merely advises other BIPs how they might do things, so it goes into the
Draft->Active Status flow rather than Draft->Accepted->Final.

Luke

📅 Original date posted:2016-08-16 📝 Original message:On ...

2023-06-07T19:52:55+02:00

In reply to nevent1q…hln5
_________________________

📅 Original date posted:2016-08-16
📝 Original message:On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in
> P2WSH:
> https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> https://github.com/bitcoin/bitcoin/pull/8526

I am not sure this makes sense. SegWit transactions are already non-malleable
due to skipping the witness data in calculating the transaction id. What is
the benefit to this?

Luke

📅 Original date posted:2016-08-16 📝 Original message:On ...

2023-06-07T19:52:53+02:00

In reply to nevent1q…qgwk
_________________________

📅 Original date posted:2016-08-16
📝 Original message:On Tuesday, August 16, 2016 2:10:04 PM Jonas Schnelli via bitcoin-dev wrote:
> The BIP describes two approaches how to communicate (pipe and
> URI-scheme) with the signing-devices app, although, in my opinion, all
> major platform do support the URI approach (maybe we could drop the pipe
> approach then).

IMO it's kindof ugly to abuse URIs for communication. Stdio pipes are pretty
universally supported, why not just use those?

On the other hand, no matter how the plugin is implemented, it's still a
security risk, and requires installation (which the user might not have access
for). It would be best if the hardware protocol were standardised, so the user
doesn't need a plugin of *any* sort... I notice some hardware wallets have
begun to implement (or reuse) Trezor's interface, so that would seem a good
place to start?

Luke

📅 Original date posted:2016-08-09 📝 Original message:On ...

2023-06-07T19:52:33+02:00

In reply to nevent1q…vsm9
_________________________

📅 Original date posted:2016-08-09
📝 Original message:On Tuesday, August 09, 2016 11:06:20 PM Daniel Hoffman via bitcoin-dev wrote:
> Is this good enough to warrant an official BIP number?

Yeah, let's call it BIP 170.

Next step is to:
- Fix the BIP number in the file
- Format it in the usual BIP mediawiki format instead of markdown
- Add it to a fork of the bitcoin/bips git repository
- Open a pull request against bitcoin/bips

P.S. Why are telephones considered 4-tone? DTMF is 16-tone IIRC?

📅 Original date posted:2016-08-04 📝 Original message:On ...

2023-06-07T19:52:12+02:00

In reply to nevent1q…7tg9
_________________________

📅 Original date posted:2016-08-04
📝 Original message:On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev
wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?

This isn't something that makes sense at the address, since it represents the
recipient and not the sender. Transactions are not sent from addresses ever.

> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a transaction's
> progress was publicly visible so transparent fraud prevention and auditing
> would become possible by anyone.

This is already possible. Just nLockTime your withdrawls for some future
block. Don't sign any transaction that isn't nLockTime'd at least N blocks
beyond the present tip.

Luke

📅 Original date posted:2016-06-21 📝 Original message:On ...

2023-06-07T19:51:19+02:00

In reply to nevent1q…nc9z
_________________________

📅 Original date posted:2016-06-21
📝 Original message:On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote:
> > What do you mean by "replacement addresses" and "UI confirms" here?
>
> "Replacement addresses" would take the place of BIP 32/47 support, if
> someone thought maybe that was too difficult to deal with. So each time i
> paid Alice, Alice could generate a new payment address for the next monthly
> payment. If you support BIP 32 pub seed, then there's no need for this.

I suppose it makes sense that since every payment requires communication with
the recipient, that the recipient could give you a new scriptPubKey each time.
No need to save [potentially compromised] payment info in advance?

> I don't know any wallets that support a BIP 32 pub seed (and then what,
> some random number generator?) as a destination address yet.

The point, as I see it, of payment protocol(s) is to deprecate addresses.
ie, this new protocol *could be* the BIP 32 pub seed destination address. ;)

> > Disagree with hard-coding intervals, or mandating specific policies from
> > the service providers.
>
> I think mandating is a harsh word here, but i I'm a strong believer in
> providing strict guidelines that if people break, others can call them
> on. Giving someone a 12.3 +/- 5 day interval for payments using this
> protocol would suck. You should use payment channels for that stuff.
> The idea is a lightweight protocol for getting monthly subscriptions
> working.

Maybe just a field specifying how far in advance payments should be sent,
then?

Luke

📅 Original date posted:2016-06-21 📝 Original message:On ...

2023-06-07T19:51:18+02:00

In reply to nevent1q…3udy
_________________________

📅 Original date posted:2016-06-21
📝 Original message:On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol. Not too late
> to support JSON messages as the standard going forward

IMO JSON is too prone to gratuitous inefficiency (both at network and CPU
level), parser bugs, etc. Even the best C implementation (jansson) has serious
issues with Number handling.

A few years ago, I looked into binary alternatives to JSON and concluded they
all had problems, while it seems more than reasonable to do even dynamic
parsing of protobuf messages. So to conclude, I prefer to stick to protobuf
unless a clearly superior protocol turns up.

> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification. alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas. personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)

X509 is entrenched, so it should remain supported. PGP might make sense for
people already using it (it provides no real security for un-WoT-networked
users), but unforunately, few people use it. Correct me if I'm wrong, but IIRC
Keybase uses blockchain spam, so definitely not something to be encouraged if
so. Namecoin seems like a more than reasonable decentralised solution, but
will probably take some real work to implement (not that this is avoidable for
a general-usage decentralised solution).

> - missing an optional client supplied identification

What do you mean by this? There's the memo field at least.

> - lack of basic subscription support
>
> *Proposed for subscriptions:*
>
> - BIP0047 payment codes are recommended instead of wallet addresses when
> establishing subscriptions. Or, merchants can specify replacement
> addresses in ACK/NACK responses. UI confirms are *required *when there
> are no replacement addresses or payment codes used.

I'd discourage anything using BIP 47 due to its serious design flaws.
No reason a regular BIP 32 pub seed can't be used instead.

What do you mean by "replacement addresses" and "UI confirms" here?

> - Wallets must confirm and store subscriptions, and are responsible for
> initiating them at the specified interval.
>
> - Intervals can *only *be from a preset list: weekly, biweekly, or 1,
> 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause
> suspension until the user re-verifies.

Disagree with hard-coding intervals, or mandating specific policies from the
service providers.

> - Wallets *may *optionally ask the user whether they want to be notified
> and confirm every interval - or not. Wallets that do not ask *must
> *notify before initiating each payment. Interval confirmations should
> begin at *least *1 day in advance of the next payment.

This is wallet policy, but maybe makes sense as a "best practices" BIP.

> *Proposed in general:*
> - JSON should be used instead of protocol buffers going forward. Easier to
> use, explain extend.
>
> - "Extendible" URI-like scheme to support multi-mode identity mechanisms on
> both payment and subscription requests. Support for keybase://, netki://
> and others as alternates to https://.
>
> - Support for client as well as merchant multi-mode verification
>
> - Ideally, the identity verification URI scheme is somewhat
> orthogonal/independent of the payment request itself
>
> Question:
>
> Should this be a new BIP? I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
>
> Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
> major protocols without any mention of payment URI's ... just a way of
> sending and receiving identity verified messages in general?
>
> I would be happy to implement plugins for identity protocols, if anyone
> thinks this is a good idea.
>
> Does anyone think https:// or keybase, or PGP or netki all by themselves,
> is enough - or is it always better to have an extensible protocol?
>
> - Erik Aronesty

📅 Original date posted:2016-05-11 📝 Original message:On ...

2023-06-07T19:50:31+02:00

In reply to nevent1q…ryvh
_________________________

📅 Original date posted:2016-05-11
📝 Original message:On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev
wrote:
> On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
> > You can find it here:
> > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
> > ck-header/
> >
> > Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
> > second 64-byte chunk. That design also allows increased nonce space in
> > the first 64 bytes.
>
> My mistake here. I didn't recalled correctly my own idea. The idea is to
> include in the second 64-byte chunk a 4-byte hash of the first chunk, not
> the opposite.

What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate?
Would that work?

Luke

📅 Original date posted:2016-03-02 📝 Original message:On ...

2023-06-07T19:49:29+02:00

In reply to nevent1q…mygk
_________________________

📅 Original date posted:2016-03-02
📝 Original message:On Wednesday, March 02, 2016 2:56:14 PM Luke Dashjr via bitcoin-dev wrote:
> so it may even be possible to have such a proposal ready in time to be
> deployed alongside SegWit to take effect in time for the upcoming subsidy
> halving.

Lapse of thinking/clarity here. This probably isn't a practical timeframe for
deployment, unless/until there's an emergency situation. So if the code were
bundled with SegWit, it would need some way to avoid its early activation
outside of such an emergency (which could possibly be detected in code, in
this case).

Luke

📅 Original date posted:2016-03-02 📝 Original message:On ...

2023-06-07T19:49:29+02:00

In reply to nevent1q…gugj
_________________________

📅 Original date posted:2016-03-02
📝 Original message:On Wednesday, March 02, 2016 3:05:08 PM Pavel Janík wrote:
> > the network. This would result in a significantly longer block interval,
> > which also means a higher per-block transaction volume, which could
> > cause the block size limit to legitimately be hit much sooner than
> > expected.
>
> If this happens at all (the exchange rate of the coin can accomodate such
> expectation),

The exchange rate is not significantly influenced by these things.
Historically, it seems fairly obvious that the difficulty has followed value,
not value following difficulty.

> the local fee market will develop, fees will raise and complement mined
> coins, thus bringing more miners back to the game (together with expected
> higher exchange rate).

Depends on the hashrate drop, and tolerance for higher fees, both of which are
largely unknown at this time. At least having code prepared for the negative
scenarios in case of an emergency seems reasonable, even if we don't end up
needing to deploy it.

Luke

📅 Original date posted:2016-03-02 📝 Original message:We are ...

2023-06-07T19:49:28+02:00

In reply to nevent1q…28cj
_________________________

📅 Original date posted:2016-03-02
📝 Original message:We are coming up on the subsidy halving this July, and there have been some
concerns raised that a non-trivial number of miners could potentially drop off
the network. This would result in a significantly longer block interval, which
also means a higher per-block transaction volume, which could cause the block
size limit to legitimately be hit much sooner than expected. Furthermore, due
to difficulty adjustment being measured exclusively in blocks, the time until
it adjusts to compensate would be prolonged.

For example, if 50% of miners dropped off the network, blocks would be every
20 minutes on average and contain double the transactions they presently do.
Even double would be approximately 850-900k, which potentially bumps up
against the hard limit when empty blocks are taken into consideration. This
situation would continue for a full month if no changes are made. If more
miners drop off the network, most of this becomes linearly worse, but due to
hitting the block size limit, the backlog would grow indefinitely until the
adjustment occurs.

To alleviate this risk, it seems reasonable to propose a hardfork to the
difficulty adjustment algorithm so it can adapt quicker to such a significant
drop in mining rate. BtcDrak tells me he has well-tested code for this in his
altcoin, which has seen some roller-coaster hashrates, so it may even be
possible to have such a proposal ready in time to be deployed alongside SegWit
to take effect in time for the upcoming subsidy halving. If this slips, I
think it may be reasonable to push for at least code-readiness before July,
and possibly roll it into any other hardfork proposed before or around that
time.

I am unaware of any reason this would be controversial, so if anyone has a
problem with such a change, please speak up sooner rather than later. Other
ideas or concerns are of course welcome as well.

Thanks,

Luke

📅 Original date posted:2016-02-06 📝 Original message:On ...

2023-06-07T19:48:46+02:00

In reply to nevent1q…dph9
_________________________

📅 Original date posted:2016-02-06
📝 Original message:On Saturday, February 06, 2016 3:37:30 PM Gavin Andresen wrote:
> I suspect there ARE a significant percentage of un-maintained full nodes--

Do you have evidence these are intentionally unmaintained, and not users who
have simply not had time to review and decide on upgrading?

> There is broad agreement that a capacity increase is needed NOW.

If so, it is only based on misinformation. I am concerned you are implying
this conclusion is true. When I spoke with you maybe a year ago with my
concerns that block size might grow too fast, you suggested that the miners
could be trusted to not increase the block size until necessary (which is not
likely to be any time soon, despite the massive misinformation campaigns out
there).

> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
> > > > Miners express their support for this BIP by ...
> > >
> > > But miners don't get to decide hardforks. How does the economy
> > > express their support for it? What happens if miners trigger it
> > > without consent from the economy?
>
> "The economy" does support this.

I have seen evidence which suggests the contrary. For example:
https://twitter.com/barrysilbert/status/694911989701861376

Where is yours?

> > If you are intent on using the version bits to trigger the
> > hardfork, I suggest rephrasing this such that miners should
> > only enable the bit when they have independently confirmed
> > economic support (this means implementations need a config
> > option that defaults to off).
>
> Happy to add words about economic majority.
>
> Classic will not implement a command-line option (the act of running
> Classic is "I opt in"), but happy to add one for a pull request to Core,
> assuming Core would not see such a pull request as having any hostile
> intent.

But this isn't about the miner opting in, it is about the miner *observing
economic support* for the change. I have successfully downloaded Bitcoin
Classic's beta binaries without ANY warning that by running it, I am
expressing that I believe the economy has approved of a hardfork.

> > > SPV (simple payment validation) wallets are compatible with this
> > > change.
> >
> > Would prefer if this is corrected to "Light clients" or something.
> > Actual SPV wallets do not exist at this time, and would not be
> > compatible with a hardfork.
>
> Is there an explanation of SPV versus "Light Client" written somewhere more
> permanent than a reddit comment or forum post that I can point to?

Not that I am aware of. (But both reddit comments and forum posts have
outlived many other posts, such as blogs, so I'm not sure why to exclude them
specifically...)

In any case, since SPV nodes don't exist, there is probably no real need to
address them. Everyone will know what "light client" means.

> > I would also prefer to see any hardfork:
> > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
> > insecure.
>
> I haven't been paying attention to all of the
> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
> mean. Is THAT written up somewhere?

Working on a BIP draft for it, but it's not ready for publication yet. The
basic idea is to turn the merkle root in the block header into simply a hash
of a second block header, which is constructed to parse as a valid empty
generation transaction under the old rules. Thus, old nodes see the forked
blockchain as valid with continually growing work on it, but as if the blocks
were all empty. This protects them from attackers mining a short blockchain
they perceive as valid.

Luke

📅 Original date posted:2016-02-07 📝 Original message:On ...

2023-06-07T19:48:45+02:00

In reply to nevent1q…r95r
_________________________

📅 Original date posted:2016-02-07
📝 Original message:On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
wrote:
> > > If you have a node that is "old" your node will stop getting new
> > > blocks. The node will essentially just say "x-hours behind" with "x"
> > > getting larger every hour. Funds don't get confirmed. etc.
> >
> > Until someone decides to attack you. Then you'll get 6, 10, maybe more
> > blocks confirming a large 10000 BTC payment. If you're just a normal end
> > user (or perhaps an automated system), you'll figure that payment is good
> > and irreversibly hand over the title to the house.
>
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).

I'm assuming there are literally ZERO miners left on the weaker branch.
The attacker in this scenario simply rents hashing for a few days in advance
to build his fake chain, then broadcasts the blocks to the unsuspecting
merchant at ~10 block intervals so it looks like everything is working normal
again. There are lots of mining rental services out there, and miners quite
often do not care to avoid selling hashrate to the highest bidder regardless
of what they're mining. 10 blocks worth costs a little more than 250 BTC -
soon, that will be 125 BTC.

Luke

📅 Original date posted:2016-02-06 📝 Original message:On ...

2023-06-07T19:48:43+02:00

In reply to nevent1q…eqz3
_________________________

📅 Original date posted:2016-02-06
📝 Original message:On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
> On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
wrote:
> > None of the reasons you list say anything about the fact that "being
> > lost" (kicked out of the network) is a problem for those node's users.
>
> That's because its not.
>
> If you have a node that is "old" your node will stop getting new blocks.
> The node will essentially just say "x-hours behind" with "x" getting larger
> every hour. Funds don't get confirmed. etc.

Until someone decides to attack you. Then you'll get 6, 10, maybe more blocks
confirming a large 10000 BTC payment. If you're just a normal end user (or
perhaps an automated system), you'll figure that payment is good and
irreversibly hand over the title to the house.

Luke

📅 Original date posted:2016-02-05 📝 Original message:On ...

2023-06-07T19:48:36+02:00

In reply to nevent1q…w6ys
_________________________

📅 Original date posted:2016-02-05
📝 Original message:On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight

Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?

> Signature operations in un-executed branches of a Script are not counted
> OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a
> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top
> of the execution stack, it is counted as one signature operation. If it is
> satisfied by the public key nearest the bottom of the execution stack, it
> is counted as twenty signature operations. Signature operations involving
> invalidly encoded signatures or public keys are not counted towards the
> limit

These seem like they will break static analysis entirely. That was a noted
reason for creating BIP 16 to replace BIP 12. Is it no longer a concern? Would
it make sense to require scripts to commit to the total accurate-sigop count
to fix this?

> The amount of data hashed to compute signature hashes is limited to
> 1,300,000,000 bytes per block.

The rationale for this wasn't in your blog post. I assume it's based on the
current theoretical max at 1 MB blocks? Even a high-end PC would probably take
40-80 seconds just for the hashing, however - maybe a lower limit would be
best?

> Miners express their support for this BIP by ...

But miners don't get to decide hardforks. How does the economy express their
support for it? What happens if miners trigger it without consent from the
economy?

If you are intent on using the version bits to trigger the hardfork, I suggest
rephrasing this such that miners should only enable the bit when they have
independently confirmed economic support (this means implementations need a
config option that defaults to off).

> SPV (simple payment validation) wallets are compatible with this change.

Would prefer if this is corrected to "Light clients" or something. Actual SPV
wallets do not exist at this time, and would not be compatible with a
hardfork.

> In the short term, an increase is needed to continue the current economic
> policies with regards to fees and block space, matching market expectations
> and preventing market disruption.

IMO this sentence is the most controversial part of your draft, and it
wouldn't suffer a loss to remove it (or at least make it subjective).

I would also prefer to see any hardfork:

1. Address at least the simple tasks on the hardfork wishlist (eg, enable some
disabled opcodes; fix P2SH for N-of->15 multisig; etc).
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
insecure.

Luke

📅 Original date posted:2016-02-04 📝 Original message:On ...

2023-06-07T19:48:31+02:00

In reply to nevent1q…ut05
_________________________

📅 Original date posted:2016-02-04
📝 Original message:On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> ABSTRACT
>
> This document specifies a proposed change to the semantics of the sign
> bit of the "version" field in Bitcoin block headers, as a mechanism to
> indicate a hardfork is deployed.

Disagree with treating the "version" field as a number, in BIP 9 or this BIP
which reinterpret it as a bit vector.

> Among the 640 bits in the block header, this is the only one which is
> fixed and serves no purpose, ...

Minor nit (not relevant to actual proposal): This is not true. There are over
32 other bits (part of the "previous-block" field) which also serve no
purpose.

> FLAG BLOCK Any planned hardfork must have one and only one flag block
> which is the "point of no return". To ensure monotonicity, flag block
> should be determined by block height, or as the first block with
> GetMedianTimePast() greater than a threshold. Other mechanisms could be
> difficult for SPV nodes to follow. The height/time threshold could be a
> predetermined value or relative to other events (e.g. 10000 blocks / 100
> days after 95% of miner support). The exact mechanism is out of the
> scope of this BIP. No matter what mechanism is used, the threshold is
> consensus critical. It must be publicly verifiable with only blockchain
> data, and preferably SPV-friendly (i.e. verifiable with block headers
> only, without downloading any transaction).

With the current codebase, it is significantly easier to trigger on the block
timestamp rather than its height or median-time-past. Using either of the
latter would require refactoring of CBlockIndex. As a hard-fork, even if the
rules are ineffective for a few blocks following the forking point, using the
hardfork version bit in this BIP would still ensure a clean break. While I
agree that median-time-past and height are superior methods that ought to be
used for hardforks, an emergency hardfork may need to avoid them for
simplicity, and I don't think they need to be mandated as such in this BIP.

> Although a hardfork is officially deployed when flag block is generated, ...

I would avoid implying the hardfork can be "officially deployed" without
actual adoption.

> AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is
> found on the network, full nodes and SPV nodes should alert their users
> and/or stop accepting/sending transactions. It should be noted that the
> warning system could become a denial-of-service vector if the attacker
> is willing to give up the block reward. Therefore, the warning may be
> issued only if a few blocks are built on top of the flag block in a
> reasonable time frame. This will in turn increase the risk in case of a
> real planned hardfork so it is up to the wallet programmers to decide
> the optimal strategy. Human warning system (e.g. the emergency alert
> system in Bitcoin Core) could fill the gap.

This seems vulnerable to DoS attacks by rejected hardforks.

> VERSION BITS This proposal is also compatible with the BIP9. The version
> bits mechanism could be employed to measure miner support towards a
> hardfork proposal, and to determine the height or time threshold of the
> flag block. Also, miners of the flag block may still cast votes for
> other concurrent softfork or hardfork proposals as normal.

Rather not imply BIP 9 should be used for hardforks, or that miners have any
voice in the decision. This is already a serious misconception.

> POINT OF NO RETURN After the flag block is generated, a miner may
> support either the original rules or the new rules, but not both. It is
> not possible for miners in one fork to attack or overtake the other fork
> without giving up the mining reward of their preferred fork.

This is not actually desirable, and would suggest a possible reason *not* to
comply with this BIP. A legitimate hardfork would never have two continued
sets of rules for miners to choose from.

Luke

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T19:45:39+02:00

In reply to nevent1q…al02
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev
wrote:
> Agree. This data does not belong in the coinbase. That space is for miners
> to use, not devs.

This has never been guaranteed, nor are softforks a "dev action" in the first
place.

> I also think that a hard fork is better for SegWit, as it reduces the size
> of fraud proofs considerably, makes the whole design more elegant and less
> kludgey, and is safer for clients who do not upgrade in a timely fashion.

How about we pursue the SegWit softfork, and at the same time* work on a
hardfork which will simplify the proofs and reduce the kludgeyness of merge-
mining in general? Then, if the hardfork is ready before the softfork, they
can both go together, but if not, we aren't stuck delaying the improvements of
SegWit until the hardfork is completed.

* I have been in fact working on such a proposal for a while now, since before
SegWit.

> I don't like the idea that SegWit would invalidate the security
> assumptions of non-upgraded clients (including SPV wallets). I think that
> for these clients, no data is better than invalid data. Better to force
> them to upgrade by cutting them off the network than to let them think
> they're validating transactions when they're not.

There isn't an option for "no data", as non-upgraded nodes in a hardfork are
left completely vulnerable to attacking miners, even much lower hashrate than
the 51% attack risk. So the alternatives are:
- hardfork: complete loss of all security for the old nodes
- softfork: degraded security for old nodes

Luke

📅 Original date posted:2015-11-13 📝 Original message:On ...

2023-06-07T19:44:37+02:00

In reply to nevent1q…87lj
_________________________

📅 Original date posted:2015-11-13
📝 Original message:On Friday, November 13, 2015 4:01:09 PM digitsu at gmail.com wrote:
> Forgive the frankness but I don't see why signaling your intent to support
> an upgrade to one side of a hard fork can be seen as a bad thing. If for
> nothing else doesn't this make for a smoother flag day? (Because once you
> signal your intention, it makes it hard to back out on the commitment.)

It isn't a commitment in any sense, nor does it make it smoother, because for
a hardfork to be successful, it is the *economy* that must switch entirely.
The miners are unimportant.

> If miners don't have any choice in hard forks, who does? Just the core
> devs?

Devs have even less of a choice in the matter. What is relevant is the
economy: who do people want to spend their bitcoins with? There is no
programmatic way to determine this, especially not in advance, so the best we
can do is a flag day that gets called off if there isn't clear consensus.

Luke

📅 Original date posted:2015-11-13 📝 Original message:On ...

2023-06-07T19:44:37+02:00

In reply to nevent1q…34he
_________________________

📅 Original date posted:2015-11-13
📝 Original message:On Friday, November 13, 2015 2:56:55 AM Chun Wang via bitcoin-dev wrote:
> * 2 MB, 210000 <= height < 420000;

It's impossible to have the entire network upgraded in the past.

Furthermore, 1 MB is already too large a block size today. While blocks don't
need to be as big as the limit, it's better to have the limit approximate what
is reasonably possible without straining the network. So while your proposed
schedule change might be workable (if miners can be trusted to keep actual
block size under 50% pending future improvements), I prefer the proposal
beginning at the next subsidy halving (which we're well on the way to).

Luke

📅 Original date posted:2015-10-29 📝 Original message:On ...

2023-06-07T19:43:54+02:00

In reply to nevent1q…uxye
_________________________

📅 Original date posted:2015-10-29
📝 Original message:On Thursday, October 29, 2015 6:57:39 AM telemaco via bitcoin-dev wrote:
> Why not allow two options:
>
> 1/ a default RocksDB/SQLite/LevelDB (whatever is decided)
> 2/ alternative provide instructions for connection to any other rdbms
> using odbc or jdbc.

I predict this would be a disaster. UTXO storage is CONSENSUS-CRITICAL code.
Any divergence in implementation behaviour, including bugs AND bugfixes, may
cause consensus failure. For this to have a reasonable *hope* of working, we
need to choose one storage engine, and *will* need to maintain consensus-
compatibility of it ourselves (since nobody else cares).

Fixing LevelDB frankly seems like an easier task than switching to anything
SQL-based, which would require a *lot* more *difficult-to-get-consensus-
compatible* code that we are all (or at least mostly) very unfamiliar with.

Research is fine, but let's be realistic about deployment.

Luke

📅 Original date posted:2015-10-22 📝 Original message:On ...

2023-06-07T19:43:45+02:00

In reply to nevent1q…z7s6
_________________________

📅 Original date posted:2015-10-22
📝 Original message:On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote:
> I think the scenario of the single signer re-ordering the outputs and
> inputs and then re-signing the transaction is in the same category of
> simple double-spends. The signer could just as well sign a completely
> different transaction spending the same coins to somewhere else, so I don't
> think there is a lot we can do about it even if we instate a canonical
> ordering. Even if we order the inputs and outputs the signer can just add a
> new input and output and we would have a different transaction.
>
> Normalized transaction IDs do help in the case that the single signer wants
> to immediately follow up its transaction with another transaction spending
> the first one's change output, and it prevents any modification in the
> multi-signer scenario.

Except that unlike malicious double spending, adding more outputs to
unconfirmed transactions is what wallets *should ideally be doing every time
they send another transaction*. Spending unconfirmed change is the wrong
approach. So half-fixing malleability as this PR would, encourages
inefficient behaviour in multiple ways (first, by not making it malleability-
safe; second, by encouraging spending unconfirmed change).

Luke

📅 Original date posted:2015-10-21 📝 Original message:On ...

2023-06-07T19:43:44+02:00

In reply to nevent1q…z3mf
_________________________

📅 Original date posted:2015-10-21
📝 Original message:On Wednesday, October 21, 2015 6:22:25 PM Danny Thorpe wrote:
> Let's keep canonical ordering separate from the normalized transaction ID
> proposal. Baby steps. Normalized transaction IDs provide an immediate
> benefit against the hazard of third party manipulation of transactions in
> the mempool, even without canonical ordering.

My point is that third-party manipulation is not much more of a problem than
signing-party manipulation. Solving the former (at a high cost), without
solving the latter, seems not worth it IMO.

Luke

📅 Original date posted:2015-10-21 📝 Original message:On ...

2023-06-07T19:43:43+02:00

In reply to nevent1q…h5vl
_________________________

📅 Original date posted:2015-10-21
📝 Original message:On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:
> On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke at dashjr.org> wrote:
> > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:
> > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke at dashjr.org> wrote:
> > > > This doesn't completely close malleability (which should be
> > > > documented
> >
> > in
> >
> > > > the BIP), so I'm not sure it's worth the cost, especially if closing
> > > > malleability later on would need more. How about specifying flags
> >
> > upfront
> >
> > > > in the UTXO-creating transaction specifying which parts the signature
> > > > will cover? This would allow implementation of fully
> > > > malleability-proof wallets.
> > >
> > > As far as I see it the only remaining venues for malleability are the
> > > use of sighash flags that are not SIGHASH_ALL, as mentioned in the
> > > BIP. Any
> >
> > use
> >
> > > of non-sighash_all flags is already an explicit permission to modify
> > > the transactions, by adding and removing inputs and outputs, so I
> > > don't see
> >
> > how
> >
> > > these can be made non-malleable. Am I missing something?
> >
> > Signer malleability is still a notable concern needing consideration.
> > Ideally,
> > wallets should be trying to actively CoinJoin, bump fees on, etc any
> > pending
> > transactions in the background. These forms of malleability affect nearly
> > as
> > many real use cases as third-party malleability.
> >
> > Luke
>
> How is signer malleability still a problem if we remove the signatures from
> the transaction ID of the transaction and all preceding transactions? The
> signer can re-sign a transaction but it won't change the transaction ID.

The signer can also change the order of the inputs, the inputs themselves,
add/remove outputs, etc... all which should be possible without becoming a
different logical transaction. The only unique property of the logical
transaction is the scriptPubKey/address.

Luke

📅 Original date posted:2015-10-21 📝 Original message:On ...

2023-06-07T19:43:43+02:00

In reply to nevent1q…yukx
_________________________

📅 Original date posted:2015-10-21
📝 Original message:On Wednesday, October 21, 2015 8:44:53 AM Christian Decker wrote:
> Hm, that is true as long as the signer is the only signer of the
> transaction, otherwise he'd be invalidating the signatures of the other
> signers.

Or he can just have the other signers re-sign with the modified version.
Even if it only worked with a single signer, it's still a form of malleability
that your BIP does not presently solve, but would be desirable to solve...

Luke

📅 Original date posted:2015-10-21 📝 Original message:On ...

2023-06-07T19:43:42+02:00

In reply to nevent1q…9tv4
_________________________

📅 Original date posted:2015-10-21
📝 Original message:On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote:
> The proposal is implemented (see below), by computing the normalized
> transaction ID when adding them to the UTXO and storing them along with the
> coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
> OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
> how to best refactor the common functionality into reusable blocks. And the
> annotating incoming transactions with their normalized inputs is a bit
> cumbersome, maye somebody has some pointers here as well?

This doesn't completely close malleability (which should be documented in the
BIP), so I'm not sure it's worth the cost, especially if closing malleability
later on would need more. How about specifying flags upfront in the UTXO-
creating transaction specifying which parts the signature will cover? This
would allow implementation of fully malleability-proof wallets.

Additionally, you have a flag to control whether the opcode behaves as VERIFY
or not. Non-VERIFY is not possible as a softfork (without doing a second/new
P2SH) since it can be negated.

Luke

📅 Original date posted:2015-10-06 📝 Original ...

2023-06-07T19:42:51+02:00

In reply to nevent1q…r3tf
_________________________

📅 Original date posted:2015-10-06
📝 Original message:Copyright doesn't care how notices are written. They are merely informative
to humans reading them. Anyhow, this is not development related, so please
direct any further discussion of it to me directly (with any applicable CCs)
and NOT to the mailing list.

Thanks,

Luke

On Tuesday, October 06, 2015 5:49:40 AM Milly Bitcoin via bitcoin-dev wrote:
> Maybe you are confused with a compilation notice that would say "All
> Content Copyright and other rights reserved by its Respective Owners" or
> something similar. That is not the same thing as claiming ownership
> using the "c" inside the circle.
>
> There is also a difference between claiming a copyright for individual
> works as part of a compilation as opposed to claiming a copyright on the
> compilation itself (which is what the current notice is).
>
> Russ
>
> On 10/6/2015 1:08 AM, Milly Bitcoin wrote:
> >> The copyright notice refers to the fact that each contributor owns
> >> copyright
> >> to his own contributions. There is no legal group that owns copyright
> >> to the
> >> entirety of the code.
> >
> > No, that is not what such a notice means. The part after the "c" in the
> > circle is the legal owner. If the legal owners are not properly
> > identified then the notice is not valid.
> >
> > ---
> >
> > From Nolo:
> > What is a valid copyright notice?
> >
> > A copyright notice should contain:
> > •the word "copyright"
> > •a "c" in a circle (©)
> > •the date of publication, and
> > •the name of either the author or the owner of all the copyright rights
> > in the published work.
> >
> > For example, the correct copyright for the fourth edition of The
> > Copyright Handbook, by Stephen Fishman (Nolo), is Copyright © 1998 by
> > Stephen Fishman.
> >
> > ---
> > from USPTO:
> >
> > Use of the notice informs the public that a work is protected by
> > copyright, identifies the copyright owner, and shows the year of first
> > publication.
> > ---
> >
> > Russ
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-10-05 📝 Original message:On ...

2023-06-07T19:42:38+02:00

In reply to nevent1q…krch
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Monday, October 05, 2015 3:56:33 PM Sergio Demian Lerner via bitcoin-dev
wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not Mike's
> main intention. At least I perceive (and maybe others too) something else
> is happening.
>
> Let me try to clarify: the discussion has nothing to do with technical
> arguments. I generally like more hard forks than soft forks (but I won't
> explain why because this is not a technical thread), but for CLTV this is
> quite irrelevant (but I won't explain why..), and I want CLTV to be
> deployed asap.
>
> Mike's intention is to criticize the informal governance model of Bitcoin
> Core development and he has strategically pushed the discussion to a
> dead-end where the group either:
>
> 1) ignores him, which is against the established criteria that all
> technical objections coming from anyone must be addressed until that person
> agrees, so that a change can be uncontroversial. If the group moves forward
> with the change, then the "uncontroversial" criteria is violated and then
> credibility is lost. So a new governance model would be required for which
> the change is within the established rules.
>
> 2) respond to his technical objections one after the other, on never ending
> threads, bringing the project to a standstill.
>
> As I don't want 2) to happen, then 1) must happen, which is what Mike
> wants. I have nothing for or against Mike personally. I just think Mike
> Hearn has won this battle. But having a more formal decision making process
> may not be too bad for Bitcoin, maybe it can actually be good.

This discussion is *necessarily* about soft/hard fork technicalities, as
there is no governance in Bitcoin beyond the *nature* of the consensus
protocol. The "established criteria" you mention is merely the nature of
hardforks. It is completely inapplicable and has never been the necessary
case for softforks, which can be enforced by merely a miner majority.

Luke

📅 Original date posted:2015-09-18 📝 Original message:On ...

2023-06-07T19:40:53+02:00

In reply to nevent1q…q48j
_________________________

📅 Original date posted:2015-09-18
📝 Original message:On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> Google calendar is localised, so it doesn't matter. The problem with
> quoting UTC anyway it the meeting times are going to change for those that
> observe DST. It would be much better to quote an actual timezone of an
> actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
> example. Otherwise when the clocks change, what was a convenient meeting
> time will become inconvenient for some.

Not everyone does crazy clock-changing. Using such a time system for
scheduling seems to inconvenience the wrong position. (although perhaps
arguably better since most people probably use DST) :p

(Aside, if Google Calendar can't support standard UTC, that sounds like an
argument against using Google Calendar...)

> Urgh... Can we hardfork time? It's clearly in need of an upgrade...

Tonal time works nice any consistently. :D

Luke

📅 Original date posted:2015-09-18 📝 Original message:On ...

2023-06-07T19:40:53+02:00

In reply to nevent1q…5mn6
_________________________

📅 Original date posted:2015-09-18
📝 Original message:On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> Google calendar is localised, so it doesn't matter. The problem with
> quoting UTC anyway it the meeting times are going to change for those that
> observe DST. It would be much better to quote an actual timezone of an
> actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
> example. Otherwise when the clocks change, what was a convenient meeting
> time will become inconvenient for some.

Not everyone does crazy clock-changing. Using such a time system for
scheduling seems to inconvenience the wrong position. (although perhaps
arguably better since most people probably use DST) :p

(Aside, if Google Calendar can't support standard UTC, that sounds like an
argument against using Google Calendar...)

> Urgh... Can we hardfork time? It's clearly in need of an upgrade...

Tonal time works nice and consistently. :D

Luke

📅 Original date posted:2015-09-18 📝 Original message:On ...

2023-06-07T19:40:50+02:00

In reply to nevent1q…tzpc
_________________________

📅 Original date posted:2015-09-18
📝 Original message:On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan via
bitcoin-dev wrote:
> At Monday's code sprint we had a good idea to schedule a regular developer
> meeting in #bitcoin-dev.
>
> Attendance is of course voluntary, but it may be good to have a time that
> many people are expected to be present and current issues can be
> discussed.

I think it's important to make a point that these meetings are for
discussions, and explicitly never decisions, to avoid a repeat of the P2SH
events when people have to miss it.

> Any preference for days/times?
>
> What about e.g. every week 15:00-16:00 UTC on Thursday?

I think I would prefer a bit later, but I could probably make this work.
Probably should try to make it more practical for California devs though,
since there are a number of them.

Luke

📅 Original date posted:2015-07-17 📝 Original message:On ...

2023-06-07T17:42:33+02:00

In reply to nevent1q…6pnk
_________________________

📅 Original date posted:2015-07-17
📝 Original message:On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> BIP PR: https://github.com/bitcoin/bips/pull/173

I'm concerned that miners are prematurely bumping their soft limit to 1 MB
lately. The only reason block size limit lifting is remotely reasonable is if
we can trust miners to at the very least keep their soft limits set at a
manageable size, but this assumption appears to already be failing in
practice.

We are unlikely to approach 1 MB of actual volume by November, so I would
prefer to see the activation date on this moved later - maybe November 2016,
if not 2017. It would also be an improvement to try to follow reasonably-
expected bandwidth increases, so 15% (1.15 MB) rather than doubling. Doubling
in only a few months seems to be far from a "conservative" increase.

If we can get some kind of commitment from miners not to move their soft
limits beyond 1 MB until some future-agreed-on point, maybe the BIP is
acceptable as-is.

On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:
> It establishes a precedent for hard forks not to require a vote though.

Hardforks are not something where voting makes sense. They need consensus
among /nodes/, not majority among /miners/. No hardfork has ever had such a
vote.

Luke

📅 Original date posted:2015-07-06 📝 Original message:On ...

2023-06-07T17:41:34+02:00

In reply to nevent1q…es5g
_________________________

📅 Original date posted:2015-07-06
📝 Original message:On Monday, July 06, 2015 4:14:14 AM Dan Bryant wrote:
> When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX
> selection was already being done by miners,

No, this is correct. It's just not included in the reference policy.
Miners are not expected to use the reference policy as-is, and some of them do
in fact use CPFP.

Luke

📅 Original date posted:2015-06-20 📝 Original message:On ...

2023-06-07T17:39:00+02:00

In reply to nevent1q…te7g
_________________________

📅 Original date posted:2015-06-20
📝 Original message:On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
> They don't need to be made cryptographically safe, they just have to be
> safer than, for instance, credit card payments that can be charged back. As
> long as it's reasonably good in practice, that's fine.

They never will be. You can get a decent rate of success merely by making one
transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg,
1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason
unconfirmed transactions aren't double spent today is because nobody is
seriously *trying*.

Luke

📅 Original date posted:2015-06-06 📝 Original message:On ...

2023-06-07T17:36:51+02:00

In reply to nevent1q…34qn
_________________________

📅 Original date posted:2015-06-06
📝 Original message:On Saturday, June 06, 2015 2:35:17 PM Kalle Rosenbaum wrote:
> Current methods of proving a payment:
>
> * Signing messages, chosen by the server, with the private keys used to
> sign the transaction. This could meet 1 and 2 but probably not 3. This is
> not standardized either. 4 Could be met if designed so.

It's also not secure, since the signed messages only prove ownership of the
address associated with the private key, and does not prove ownership of
UTXOs currently redeemable with the private key, nor prove past UTXOs spent
were approved by the owner of the address.

> A proof of payment for a transaction T, here called PoP(T), is used to
> prove that one has ownership of the credentials needed to unlock all the
> inputs of T.

This appears to be incompatible with CoinJoin at least. Maybe there's some
clean way to avoid that by using
https://github.com/Blockstream/contracthashtool ?

> It has the exact same structure as a bitcoin transaction with
> the same inputs and outputs as T and in the same order as in T. There is
> also one OP_RETURN output inserted at index 0, here called the pop output.

I also agree with Pieter, that this should *not* be so cleanly compatible
with Bitcoin transactions. If you wish to share code, perhaps using an
invalid opcode rather than OP_RETURN would be appropriate.

Luke

📅 Original date posted:2015-06-06 📝 Original message:On ...

2023-06-07T17:36:50+02:00

In reply to nevent1q…jnj7
_________________________

📅 Original date posted:2015-06-06
📝 Original message:On Saturday, June 06, 2015 9:25:02 PM Kalle Rosenbaum wrote:
> * The pop output will have value 0.

Why not have it be -1 to make it completely invalid as a transaction?

Luke

📅 Original date posted:2015-05-26 📝 Original message:On ...

2023-06-07T17:35:36+02:00

In reply to nevent1q…jm7e
_________________________

📅 Original date posted:2015-05-26
📝 Original message:On Tuesday, May 26, 2015 4:46:22 AM Kevin Greene wrote:
> This is something you actually don't want. In order to make it as difficult
> as possible for an attacker to perform a sybil attack, you want to choose a
> set of peers that is as diverse, and unpredictable as possible.

It doesn't hurt to have a local node or two, though. Might as well to improve
propagation, while maintaining the other peers to avoid sybil attacks.

Luke

📅 Original date posted:2015-02-14 📝 Original message:On ...

2023-06-07T17:30:34+02:00

In reply to nevent1q…dnw2
_________________________

📅 Original date posted:2015-02-14
📝 Original message:On Saturday, February 14, 2015 2:23:47 PM Tamas Blummer wrote:
> We have seen that the consensus critical code practically extends to
> Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a
> consensus library is not the same as Bitcoin Core, less its P2P service
> rules, wallet and RPC server.

You can describe 'A' from a group of A, B, C, D, E as "the group minus B, C,
D, E", sure - but I don't see how this is relevant?

UTXO storage is indeed consensus critical, as you say, but it is a lot simpler
to get right than the rest combined. Thus, the end goal is to have a
libbitcoinconsensus with "the rest", and a (as of yet named)
libbitcoincompleteconsensus that ties in the canonical UTXO storage. Ideally,
software should use the latter when it is available, but if there is a strong
reason to change UTXO storage, one can remain mostly-safe with just the
former. I'm not sure why this topic is of relevance, though...

Luke

📅 Original date posted:2014-12-04 📝 Original message:Is ...

2023-06-07T17:27:41+02:00

In reply to nevent1q…jntr
_________________________

📅 Original date posted:2014-12-04
📝 Original message:Is anyone working on a serialisation format to convey P2SH HD chains? For
example, to give someone who wants to make recurring payments a single token
that can be used to generate many P2SH addresses paying to a multisig script.

I'm thinking of something along the lines of a simple series of tokens, each
indicating either a HD chain or literal script content. For all HD chains in
the data, a child key would be generated based on the payment number, and all
tokens concatenated to form the P2SH serialised script. Eg, for a simple 2-
of-2, you would do something like this:
literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG)
Does this sufficiently cover all reasonable use cases?

Luke

📅 Original date posted:2014-11-16 📝 Original message:On ...

2023-06-07T17:27:28+02:00

In reply to nevent1q…n9fy
_________________________

📅 Original date posted:2014-11-16
📝 Original message:On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote:
> The data that can be embedded as part of an OP_RETURN output is currently
> limited to 40 bytes. It was initially supposed to be 80 bytes, but got
> reduced to 40 before the 0.9 release to err on the side of caution.
>
> After 9 months, it seems OP_RETURN did not lead to a blockchain
> catastrophe, so I think it might be time to discuss increasing the limit.

Mining policies such as this is always up to miners.
It's not a development topic.

> There are a number of proposals:
>
> 1. Allow two OP_RETURN outputs per transaction (PR
> <https://github.com/bitcoin/bitcoin/pull/5075>;)

This one seems uselessly inefficient. Protocols needing OP_RETURN could just
as easily look for an independent push opcode in a single OP_RETURN output.

> 2. Increase the default maximum payload size from 40 bytes to 80 bytes (
> PR <https://github.com/bitcoin/bitcoin/pull/5286>;)
> Note that the maximum can be configured already through the
> 'datacarriersize' option - this is just changing the default.

I don't care strongly, but IMO this kind of focus on defaults is part of the
problem. I'd prefer to have the default be randomised to incentivise miners to
make the decision they're supposed to be making, rather than pushing the
responsibility onto developers to set defaults.

> 3. Make the maximum OP_RETURN payload size proportional to the number of
> outputs of the transaction

Right now, this policy requires code hacks. Of the three ideas, this one looks
the most ripe for code changes (particularly one that makes it possible to
configure this policy, not hardcoding it).

Luke

📅 Original date posted:2014-10-03 📝 Original message:On ...

2023-06-07T17:26:08+02:00

In reply to nevent1q…0eu4
_________________________

📅 Original date posted:2014-10-03
📝 Original message:On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote:
> Is there a reason why we can't have the new opcode simply replace the top
> stack item with the block height of the txout being redeemed? Then
> arbitrary logic could be implemented, including "output cannot be spent
> until a certain time" and also "output can ONLY be spent until a certain
> time," as well as complex logic with alternative key groups with differing
> time constraints.

This cannot be done in a softfork.

Furthermore, "output can ONLY be spent until a certain time" contradict's
Bitcoin's present security assumptions: that assuming a honest sender, the
transaction will remain valid and simply re-confirm if a reorg kicks it out.

Luke

📅 Original date posted:2014-10-01 📝 Original message:On ...

2023-06-07T17:26:05+02:00

In reply to nevent1q…26c8
_________________________

📅 Original date posted:2014-10-01
📝 Original message:On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
> I've written a reference implementation and BIP draft for a new opcode,
> CHECKLOCKTIMEVERIFY.

Thoughts on some way to have the stack item be incremented by the height at
which the scriptPubKey was in a block? A limitation of encoding the target
height/time directly, is that miners may choose not to mine the first
transaction until they can also take the "burn to fee". So, one may prefer to
say "cannot be spent until 100 blocks after the first transaction is mined",
in effect reproducing the generation maturity rule.

I propose any stack item under 0x40000 be incremented by the height at which
the scriptPubKey was mined for comparison. Maybe there is a use case for doing
something similar for time too?

Luke

📅 Original date posted:2014-07-04 📝 Original message:On ...

2023-06-07T17:23:37+02:00

In reply to nevent1q…lrnr
_________________________

📅 Original date posted:2014-07-04
📝 Original message:On Friday, July 04, 2014 8:21:42 PM Jorge Timón wrote:
> On 7/4/14, kjj <bitcoin-devel at jerviss.org> wrote:
> > I suspect that there exist no algorithms which cannot be done better in
> > an application-specific device than in a general purpose computer. And
> > if there is such a thing, then it must necessarily perform best on one
> > specific platform, making that platform the de facto application
> > specific device.
> >
> > I'm not sure how one would go about proving or disproving that, but it
> > seems very likely to be true.
>
> I assumed this was obvious and self-evident for anyone who knows what
> a Turing machine is, but judging from the number of smart people
> wasting their time on the pursue of the "anti-ASIC" myth (also known
> as pow wankery) it seems I was wrong.
> Anything you can do with software you can do with hardware and
> viceversa (you can even do it with ropes and fire in Minecraft!!)
> Does this really need any proof?
> I think it's the hard-pow cultists who have to provide a counterexample.

Really, if people want to pursue a goal anything like this, they should be
looking for "ASIC already widely owned" as the property rather than "anti-
ASIC". Thus, a sufficiently memory-hard PoW would really be "RAM is the ASIC".
Whether it's possible to make this or not, is another question. And then we
get back to "is is really a desirable property to have people capable of
mining who have not given any indication of interest?"

📅 Original date posted:2014-06-03 📝 Original message:On ...

2023-06-07T17:22:13+02:00

In reply to nevent1q…rlg0
_________________________

📅 Original date posted:2014-06-03
📝 Original message:On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
> Hi,
>
> I thought a lot about the worst case scenario of SHA256d being broken in a
> way which could be abused to
> A) reduce the work of mining a block by some significant amount
> B) reduce the work of mining a block to zero, i.e. allow instant mining.

C) fabricate past blocks entirely.

If SHA256d is broken, Bitcoin as it is fails entirely.

Luke

📅 Original date posted:2014-05-15 📝 Original message:On ...

2023-06-07T17:21:21+02:00

In reply to nevent1q…dpd2
_________________________

📅 Original date posted:2014-05-15
📝 Original message:On Thursday, May 15, 2014 11:50:29 AM Andreas Schildbach wrote:
> dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs

FWIW, this may be a routing issue: I notice various ISPs have been unable to
route to my server over IPv4 today. IPv6 seems to be fine.

Not sure how important DNS seed reliability is anyway; it's just
bootstrapping, and there are multiple servers listed.

Luke

📅 Original date posted:2014-05-02 📝 Original message:On ...

2023-06-07T17:20:48+02:00

In reply to nevent1q…q79p
_________________________

📅 Original date posted:2014-05-02
📝 Original message:On Saturday, May 03, 2014 12:54:37 AM Ben Davenport wrote:
> My only addition is that I think we should all stop trying to attach SI
> prefixes to the currency unit. Name me another world currency that uses SI
> prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> That may not be accepted form everywhere, but in any case it's an informal
> format, not a formal one. The important point is there should be one base
> unit that is not modified with SI prefixes. And I think the arguments are
> strong for that unit being = 100 satoshi.

Huh? Your examples demonstrate the *opposite* of your point. 'k' and 'M' *are*
the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one
to admit SI is terrible, but I don't understand your argument here.

Luke

P.S. Note that SI units haven't actually ever been adopted, except by force of
law. "Name me ... that uses SI" is a silly thing to say, since virtually all
naturally-or-freely-adopted units of any measure have been based on a number
that factor to twos and threes (not fives, like decimal).