Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Hmm, indeed, I may have missed that you can skip the headers issues by not persisting them, though there are other follow-on effects that are concerning and I think still make my point valid. A node feeding you invalid headers (used to be) cause for a ban - is that information still persisted? More importantly, nodes on both sides of the fork need to find each other. There’s not a great way to do that without forking the address database, DNS seeds and defining a new protocol magic. Matt > On Feb 22, 2021, at 00:16, Anthony Towns wrote: > > On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote: >> It was pointed out to me that this discussion is largely moot as the >> software complexity for Bitcoin Core to ship an option like this is likely >> not practical/what people would wish to see. >> Bitcoin Core does not have infrastructure to handle switching consensus >> rules with the same datadir - after running with uasf=true for some time, >> valid blocks will be marked as invalid, > > I don't think this is true? With the current proposed bip8 code, > lockinontimeout=true will cause headers to be marked as invalid, and > won't process the block further. If a node running lockinontimeout=true > accepts the header, then it will apply the same consensus rules as a > lockinontimeout=false node. > > I don't think an invalid header will be added to the block index at all, > so a node restart should always cleanly allow it to be reconsidered. > > The test case in > > https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8 > > tests that a node that had rejected a chain due to lockinontimeout=true > will reorg to that chain after being restarted as a byproduct of the way > it tests different cases (the nodes set a new startheight, but retain > their lockinontimeout settings). > > > (I think with the current bip8 code, if you switch from > lockinontimeout=false to lockinontimeout=true and the tip of the current > most work chain is after the timeoutheight and did not lockin, then you > will continue following that chain until a taproot-invalid transaction > is inclued, rather than immediately reorging to a shorter chain that > complies with the lockinontimeout=true rules) > > Cheers, > aj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote: > It was pointed out to me that this discussion is largely moot as the > software complexity for Bitcoin Core to ship an option like this is likely > not practical/what people would wish to see. > Bitcoin Core does not have infrastructure to handle switching consensus > rules with the same datadir - after running with uasf=true for some time, > valid blocks will be marked as invalid, I don't think this is true? With the current proposed bip8 code, lockinontimeout=true will cause headers to be marked as invalid, and won't process the block further. If a node running lockinontimeout=true accepts the header, then it will apply the same consensus rules as a lockinontimeout=false node. I don't think an invalid header will be added to the block index at all, so a node restart should always cleanly allow it to be reconsidered. The test case in https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8 tests that a node that had rejected a chain due to lockinontimeout=true will reorg to that chain after being restarted as a byproduct of the way it tests different cases (the nodes set a new startheight, but retain their lockinontimeout settings). (I think with the current bip8 code, if you switch from lockinontimeout=false to lockinontimeout=true and the tip of the current most work chain is after the timeoutheight and did not lockin, then you will continue following that chain until a taproot-invalid transaction is inclued, rather than immediately reorging to a shorter chain that complies with the lockinontimeout=true rules) Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
I think the most important thing is that the configuration setting is advertised if somebody were to query the node for its capabilities. Is this the case? That way the default value isn't really the important thing. There are longstanding and well-known nodes, for example. Community support and visibility for a UASF is the most important aspect. I looked over the threads and I don't think I saw the broadcast nature of this setting clearly discussed. On Wed, Feb 17, 2021, 10:10 AM Michael Folkson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Yesterday (February 16th) we held a second meeting on Taproot > activation on IRC which again was open to all. Despite what appeared > to be majority support for LOT=false over LOT=true in the first > meeting I (and others) thought the arguments had not been explored in > depth and that we should have a follow up meeting almost entirely > focused on whether LOT (lockinontimeout) should be set to true or > false. > > The meeting was announced here: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html > > In that mailing list post I outlined the arguments for LOT=true (T1 to > T6) and arguments for LOT=false (F1 to F6) in their strongest form I > could. David Harding responded with an additional argument for > LOT=false (F7) here: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html > > These meetings are very challenging given they are open to all, you > don’t know who will attend and you don’t know most people’s views in > advance. I tried to give time for both the LOT=true arguments and the > LOT=false arguments to be discussed as I knew there was support for > both. We only tried evaluating which had more support and which had > more strong opposition towards the end of the meeting. > > The conversation log is here: > http://gnusha.org/taproot-activation/2021-02-16.log > > (If you are so inclined you can watch a video of the meeting here. > Thanks to the YouTube account “Bitcoin” for setting up the livestream: > https://www.youtube.com/watch?v=vpl5q1ovMLM) > > A summary of the meeting was provided by Luke Dashjr on Mastodon here: > https://bitcoinhackers.org/@lukedashjr/105742918779234566 > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we > did manage to come to consensus on everything but LockinOnTimeout. > > Activation height range: 693504-745920 > > MASF threshold: 1815/2016 blocks (90%) > > Keep in mind only ~100 people showed for the meetings, hardly > representative of the entire community. > > So, these details remain JUST a proposal for now. > > It seems inevitable that there won't be consensus on LOT. > > Everyone will have to choose for himself. :/ > > Personally I agree with most of this. I agree that there wasn’t > overwhelming consensus for either LOT=true or LOT=false. However, from > my perspective there was clearly more strong opposition (what would > usually be deemed a NACK in Bitcoin Core review terminology) from > Bitcoin Core contributors, Lightning developers and other community > members against LOT=true than there was for LOT=false. Andrew Chow > tried to summarize views from the meeting in this analysis: > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c > > I am also aware of other current and previous Bitcoin Core > contributors and Lightning developers who didn’t attend the meeting in > person who are opposed to LOT=true. I don’t want to put them in the > spotlight for no reason but if you go through the conversation logs of > not only the meeting but the weeks of discussion prior to this meeting > you will see their views evaluated on the ##taproot-activation > channel. In addition, on taprootactivation.com some mining pools > expressed a preference for lot=false though I don’t know how strong > that preference was. > > I am only one voice but it is my current assessment that if we are to > attempt to finalize Taproot activation parameters and propose them to > the community at this time our only option is to propose LOT=false. > Any further delay appears to me counterproductive in our collective > aim to get the Taproot soft fork activated as early as possible. > > Obviously others are free to disagree with that assessment and > continue discussions but personally I will be attempting to avoid > those discussions unless prominent new information comes to light or > various specific individuals change their minds. > > Next week we are planning a code review of the Bitcoin Core PR #19573 > which was initially delayed because of this LOT discussion. As I’ve > said previously that will be loosely following the format of the > Bitcoin Core PR review club and will be lower level and more > technical. That is planned for Tuesday February 23rd at 19:00 UTC on > the IRC channel ##taproot-activation. > > Thanks to the meeting participants (and those who joined the > discussion on the channel prior and post the
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
I don’t think “some vocal users are going to threaten to fork themselves off” is good justification for technical decisions. It’s important to communicate and for everyone to agree/understand that a failed BIP 8/9 activation, in the scenario people are worried about, is not the end of the story for Taproot activation. If it is clear that Taproot has broad consensus but some miners failed to upgrade in time (as it presumably would be), a flag day activation seems merited and I’m not sure anyone has argued against this. That said, forced-signaling via a UASF/BIP8(true)-style fork carries material additional risk that a classic flag-day activation does not, so let’s not optimize for something like that. Matt > On Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev > wrote: > > > What would be the tradeoffs of a BIP8(false, ∞) option? That would remove > some of the concerns of having to coordinate a UASF with an approaching > deadline. > > Cheers > Ariel Lorenzo-Luaces >> On Feb 19, 2021, at 6:55 PM, ZmnSCPxj via bitcoin-dev >> wrote: >> Good morning list, >> >>> It was pointed out to me that this discussion is largely moot as the >>> software complexity for Bitcoin Core to ship an >>> option like this is likely not practical/what people would wish to see. >>> >>> Bitcoin Core does not have infrastructure to handle switching consensus >>> rules with the same datadir - after running with >>> uasf=true for some time, valid blocks will be marked as invalid, and >>> additional development would need to occur to >>> enable switching back to uasf=false. This is complex, critical code to get >>> right, and the review and testing cycles >>> needed seem to be not worth it. >> >> Without implying anything else, this can be worked around by a user >> maintaining two `datadir`s and running two clients. >> This would have an "external" client running an LOT=X (where X is whatever >> the user prefers) and an "internal" client that is at most 0.21.0, which >> will not impose any LOT rules. >> The internal client then uses `connect=` directive to connect locally to the >> external client and connects only to that client, using it as a firewall. >> The external client can be run pruned in order to reduce diskspace resource >> usage (the internal client can remain unpruned if that is needed by the >> user, e.g. for LN implementation sthat need to look up arbitrary >> short-channel-ids). >> Bandwidth usage should be same since the internal client only connects to >> the external client and the OS should optimize that case. >> CPU usage is doubled, though. >> >> (the general idea came from gmax, just to be clear, though the below use is >> from me) >> >> Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core >> ultimately ships with) on the external client based on the user preferences. >> >> If Taproot is not MASF-activated and LOT=!U is what dominates later (where U >> is whatever the user decided on), the user can decide to just destroy the >> external node and connect the internal node directly to the network >> (optionally upgrading the internal node to LOT=!U) as a way to "change their >> mind in view of the economy". >> The internal node will then follow the dominant chain. >> >> >> Regards, >> ZmnSCPxj >> >>> >>> Instead, the only practical way to ship such an option would be to treat >>> it as a separate chain (the same way regtest, >>> testnet, and signet are treated), including its own separate datadir and >>> the like. >>> >>> Matt >>> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote: (Also in response to ZMN...) Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks. There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit). Matt >> On Feb 19, 2021, at 07:08, Adam Back a...@cypherspace.org wrote: >> >> would dev consensus around releasing LOT=false be
Re: [bitcoin-dev] BIP70 is dead. What now?
What is a 'pull request'? On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Thomas, > > I am working on an experimental implementation [1] of a new payment > request format in Trezor T. In some respects it's similar to BIP-70. The > main differences are: > > 1. There is no reliance on X.509, since that seems to have been the main > reason for BIP-70's downfall. The signature is mandatory, since for us the > main feature is protection against a man-in-the-middle attack. So in this > sense it's more similar to BOLT11. > > 2. It can be used to solve a similar problem with coin exchange. When you > are sending BTC to a trusted exchange service and expecting another > cryptocurrency in return, say LTC, you want to be sure that you not only > have the correct BTC address, but also that the exchange service has your > correct LTC address. > > 3. It uses an optional nonce for replay protection. > > The two interesting parts in [1] are probably the `TxAckPaymentRequest` > protobuf message [2] and the signature verification [3]. The protobuf > message is only for communication between Trezor and the host software > running on the user's computer. It's not intended for interchange between > wallets. We haven't defined the interchange format yet. I intend to create > a SLIP documenting all this. > > Andrew > > [1] https://github.com/trezor/trezor-firmware/compare/andrewkozlik/payreq2 > [2] > https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-L427 > [3] > https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py > > On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi, Thomas, >> >> I developed a URL signing scheme for use with LNURL as a method for >> authorizing payments on behalf of offline devices /applications. It's >> not specifically off-chain or on-chain related, but could be repurposed. >> The gist of the scheme is as follows: >> >> Before any signing is done: >> >> 0) Generate an API key (ID/reference, secret, encoding) to be shared >> between a server and an offline device or application. >> >> To generate a signature: >> >> 1) Generate a random nonce (unique per API key) >> >> 2) Build a query string with the `id`, `nonce`, `tag`, "Server >> parameters" (see [Subprotocols](#subprotocols) above), and any custom >> parameters. The `id` parameter should be equal to the API key's ID. >> Example: >> `id=b6cb8e81e3=d585674cf991dbbab42b=withdrawRequest=5000=7000=example=CUSTOM1_PARAM_VALUE=CUSTOM2_PARAM_VALUE`. >> >> Note that both the keys and values for query parameters should be URL >> encoded. The following characters should be __unescaped__: `A-Z a-z 0-9 >> - _ . ! ~ * ' ( )`. See >> [encodeURIComponent]( >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description) >> >> for more details. >> >> 3) Sort the query parameters by key (alphabetically). This is referred >> to as the "payload". Example: >> >> `custom1=CUSTOM1_PARAM_VALUE=CUSTOM2_PARAM_VALUE=example=b6cb8e81e3=7000=5000=d585674cf991dbbab42b=withdrawRequest` >> >> 4) Sign the payload (the sorted query string) using the API key secret. >> Signatures are generated using HMAC-SHA256, where the API key secret is >> the key. >> >> 5) Append the signature to the payload as follows: >> >> `custom1=CUSTOM1_PARAM_VALUE=CUSTOM2_PARAM_VALUE=example=b6cb8e81e3=7000=5000=d585674cf991dbbab42b=withdrawRequest=HMAC_SHA256_SIGNATURE`. >> >> You can find more details here: >> >> https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme >> >> >> I would change a few things with this scheme to fit better with the >> use-case you describe. For example: >> >> * Remove the "tag" and LNURL-specific parameters >> >> * Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key >> signing instead. The lnurl-auth subprotocol has an interesting approach >> to protecting user privacy while allowing verification of signatures. >> See for more details on that: >> >> https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md >> >> >> - chill >> >> >> On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote: >> > I never liked BIP70. It was too complex, had too many features, and when >> > people discuss it, they do not even agree on what the main feature was. >> > >> > Nevertheless, there is ONE feature of BIP70 that I find useful: the fact >> > that payment requests were signed. I am making this post to discuss >> this. >> > >> > When I send bitcoins to an exchange, I would like to receive a signed >> > request. I want to have a proof that the exchange asked me to send coins >> > to that address, in case it has been hijacked by some intern working >> > there. If that feature was implemented by an exchange, it would guide my >> > decision to use
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some of the concerns of having to coordinate a UASF with an approaching deadline. Cheers Ariel Lorenzo-Luaces On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev wrote: >Good morning list, > >> It was pointed out to me that this discussion is largely moot as the >software complexity for Bitcoin Core to ship an >> option like this is likely not practical/what people would wish to >see. >> >> Bitcoin Core does not have infrastructure to handle switching >consensus rules with the same datadir - after running with >> uasf=true for some time, valid blocks will be marked as invalid, and >additional development would need to occur to >> enable switching back to uasf=false. This is complex, critical code >to get right, and the review and testing cycles >> needed seem to be not worth it. > >Without implying anything else, this can be worked around by a user >maintaining two `datadir`s and running two clients. >This would have an "external" client running an LOT=X (where X is >whatever the user prefers) and an "internal" client that is at most >0.21.0, which will not impose any LOT rules. >The internal client then uses `connect=` directive to connect locally >to the external client and connects only to that client, using it as a >firewall. >The external client can be run pruned in order to reduce diskspace >resource usage (the internal client can remain unpruned if that is >needed by the user, e.g. for LN implementation sthat need to look up >arbitrary short-channel-ids). >Bandwidth usage should be same since the internal client only connects >to the external client and the OS should optimize that case. >CPU usage is doubled, though. > >(the general idea came from gmax, just to be clear, though the below >use is from me) > >Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin >Core ultimately ships with) on the external client based on the user >preferences. > >If Taproot is not MASF-activated and LOT=!U is what dominates later >(where U is whatever the user decided on), the user can decide to just >destroy the external node and connect the internal node directly to the >network (optionally upgrading the internal node to LOT=!U) as a way to >"change their mind in view of the economy". >The internal node will then follow the dominant chain. > > >Regards, >ZmnSCPxj > >> >> Instead, the only practical way to ship such an option would be to >treat it as a separate chain (the same way regtest, >> testnet, and signet are treated), including its own separate datadir >and the like. >> >> Matt >> >> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote: >> >> > (Also in response to ZMN...) >> > Bitcoin Core has a long-standing policy of not shipping options >which shoot yourself in the foot. I’d be very disappointed if that >changed now. People are of course more than welcome to run such >software themselves, but I anticipate the loud minority on Twitter and >here aren’t processing enough transactions or throwing enough financial >weight behind their decision for them to do anything but just switch >back if they find themselves on a chain with no blocks. >> > There’s nothing we can (or should) do to prevent people from >threatening to (and possibly) forking themselves off of bitcoin, but >that doesn’t mean we should encourage it either. The work Bitcoin Core >maintainers and developers do is to recommend courses of action which >they believe have reasonable levels of consensus and are technically >sound. Luckily, there’s strong historical precedent for people deciding >to run other software around forks, so misinterpretation is not very >common (just like there’s strong historical precedent for miners not >unilaterally deciding forks in the case of Segwit). >> > Matt >> > >> > > On Feb 19, 2021, at 07:08, Adam Back a...@cypherspace.org wrote: >> > > >> > > > would dev consensus around releasing LOT=false be considered as >"developers forcing their views on users"? >> > > >> > > given there are clearly people of both views, or for now don't >care >> > > but might later, it would minimally be friendly and useful if >> > > bitcoin-core has a LOT=true option - and that IMO goes some way >to >> > > avoid the assumptive control via defaults. >> > >> > > Otherwise it could be read as saying "developers on average >> > > disapprove, but if you, the market disagree, go figure it out for >> > > yourself" which is not a good message for being defensive and >avoiding >> > > mis-interpretation of code repositories or shipped defaults as >> > > "control". >> > >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >___ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___
