Re: [bitcoin-dev] BIP process friction

[Luke Dashjr via bitcoin-dev]

Perhaps a BIP 3 is in order, but most of the real issue is simply a 
matter of volunteer time.


AJ's attempt to conflate that with his own personal disagreements with 
how BIPs have always worked, is unrelated.


Luke


On 1/17/24 01:55, Christopher Allen via bitcoin-dev wrote:



On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev 
 wrote:


If people want to use it for bitcoin-related proposals that don't have
anything to do with inquisition, that's fine; I'm intending to
apply the
policies I think the BIPs repo should be using, so feel free to
open a PR,
even if you already know I think your idea is BS on its merits. If
someone
wants to write an automatic-merge-bot for me, that'd also be great.

If someone wants to reform the BIPs repo itself so it works better,
that'd be even better, but I'm not volunteering for that fight.


I've no idea how to reform BIPs, but we have a similar problem with 
the Blockchain Commons Research (BCR) vs Proposals (BCP), vs. 
specifications that are emerging in various other standards groups 
(IETF, W3C, and we have desire to submit some of these as BIPs as well).


We do a few things differently, one of which in particular might be 
useful for the future of BIPs: we reset the numbers every year. So the 
first new BCR (research proposal) for 2024 would be 2024-01. Also, 
when there is a major change in an old BCR, we create a new number for 
it in the new year it is update.


We also have a concept called "Status", which is a progression that 
only moves forward if BCRs are actually implemented with a reference 
implementation, and advances further when they have multiple 
implementations (and thus are qualified moved over to BCP repo as it 
is somewhat stable and no longer "research".). A last form is when a 
specification has moved to be controlled by another standards group 
(such as a BIP). If only one organization implements a BCR, it will 
never advance to BCP.


Some form of Status for BIPs inspired by this concept could track if a 
BIP was ever actually implemented by someone, or more ideally, 
implemented by multiple people in multiple organizations, ideally in 
multiple languages.


Here is how we currently do status, and the status of our current 
specifications: 
https://github.com/BlockchainCommons/Research/blob/master/README.md#status


Each BCR has a status which is indicated by a symbol.

Symbol  Title   Description
❌❌ 	Withdrawn 	Of historic interest only. Withdrawn either because 
never came into use or proved sufficiently problematic that we do not 
recommend its usage in any way.
❌ 	Superseded 	Superseded by a newer BCR. We do not suggest 
implementing as an output format, but you may still wish to implement 
as an input format to maintain backward compatibility.
 	Research 	Contains original research or proposes specifications 
that have not yet been implemented by us. Offered to the community for 
consideration.
⭐️ 	Reference Implementation 	At least one reference implementation 
has been released, usually as a library, and may include demos or 
other supporting tools. This specification still remains very open to 
change because it has not yet (to our knowledge) been implemented by 
additional parties.
⭐️⭐️ 	Multiple Implementations 	At least two (known) implementations 
exist, at least one not by the owner of the reference implementation. 
Has demonstrable community support. May still change due to the needs 
of the community, but community feedback will be sought.
⭐️⭐️⭐️ 	Standards Track 	Typically at least two implementations, and 
is considered stable and ready for standardization. Being proposed as 
a BIP, IETF Internet Draft, or some other standardization draft 
format. Will typically be moved to theBCP repo 
. Though changes may still 
be made to the specification, these changes will exclusively be to 
allow for standardization, and will be conducted with community feedback.
⭐️⭐️⭐️⭐️ 	Standardized 	A specification has been standardized as a an 
IETF RFC, BIP, or approved by some other standards body.


❌❌ after another status symbol is read, "...but withdrawn" and ❌ is 
read, "...but superseded".


-- Christopher Allen


___
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

Re: [bitcoin-dev] Swift Activation - CTV

[Luke Dashjr via bitcoin-dev]

This IS INDEED an attack on Bitcoin. It does not activate CTV - it would 
(if users are fooled into using it) give MINERS the OPTION to activate 
CTV. Nobody should run this, and if it gets any traction, it would 
behoove the community to develop and run a "URSF" making blocks 
signalling for it invalid.


Luke


On 12/19/23 20:44, alicexbt via bitcoin-dev wrote:

Hello World,

Note: This is not an attack on bitcoin. This is an email with some text and 
links. Users can decide what works best for themselves. There is also scope for 
discussion about changing method or params.

I want to keep it short and no energy left. I have explored different options 
for activation and this feels the safest at this point in 2023. I have not done 
any magic or innovation but updated activation params. If you agree with them, 
please run this client else build your own. Anyone who calls this attack and do 
not build alternative option is an attack in itself.

It activates CTV which is simple covenant proposal and achieves what we expect 
it to. It is upgradeable.  I like simple things, at least to start with.

Activation parameters:

```
 consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 
1704067200;
 consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = 
1727740800;
 
consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height = 
874874;
```

I need payment pools and it does it for me. Apart from that it enables vaults, 
congestion control etc. We have more PoCs for CTV than we had for taproot and I 
understand it better.

If you agree with me, please build and run this client before 01 Jan 2024 else 
we can discuss ordinals for next 5 years and activate something in 2028.

Cheers

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.
___
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

Re: [bitcoin-dev] Ordinals BIP PR

[Luke Dashjr via bitcoin-dev]

Seems like a "solution" looking for a problem which doesn't actually 
exist. And not even a good "solution" for that - might as well not have 
BIP number at all, if they're not going to be usefully assigned. What we 
have now is working fine aside from a few trolls once in a while.


On 10/24/23 18:56, Olaoluwa Osuntokun wrote:

TL;DR: let's just use an automated system to assign BIP numbers, so we can
spend time on more impactful things.

IIUC, one the primary roles of the dedicated BIP maintainers is just 
to hand

out BIP numbers for documents. Supposedly with this privilege, the BIP
maintainer is able to tastefully assign related BIPs to consecutive 
numbers,

and also reserve certain BIP number ranges for broad categories, like 3xx
for p2p changes (just an example).

To my knowledge, the methodology for such BIP number selection isn't
published anywhere, and is mostly arbitrary. As motioned in this thread,
some perceive this manual process as a gatekeeping mechanism, and often
ascribe favoritism as the reason why PR X got a number immediately, 
but PR Y

has waited N months w/o an answer.

Every few years we go through an episode where someone is rightfully upset
that they haven't been assigned a BIP number after following the requisite
process.  Most recently, another BIP maintainer was appointed, with 
the hope

that the second maintainer would help to alleviate some of the subjective
load of the position.  Fast forward to this email thread, and it doesn't
seem like adding more BIP maintainers will actually help with the issue of
BIP number assignment.

Instead, what if we just removed the subjective human element from the
process, and switched to using PR numbers to assign BIPs? Now instead of
attempting to track down a BIP maintainer at the end of a potentially
involved review+iteration period, PRs are assigned BIP numbers as soon as
they're opened and we have one less thing to bikeshed and gatekeep.

One down side of this is that assuming the policy is adopted, we'll sorta
sky rocket the BIP number space. At the time of writing of this email, the
next PR number looks to be 1508. That doesn't seem like a big deal to me,
but we could offset that by some value, starting at the highest currently
manually assigned BIP number. BIP numbers would no longer always be
contiguous, but that's sort of already the case.

There's also the matter of related BIPs, like the segwit series (BIPs 141,
142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
think it would be too difficult to find a workable scheme.

Thoughts?

-- Laolu


On Mon, Oct 23, 2023 at 11:35 AM Luke Dashjr via bitcoin-dev 
 wrote:


Everything standardized between Bitcoin software is eligible to be
and
should be a BIP. I completely disagree with the claim that it's
used for
too many things.

SLIPs exist for altcoin stuff. They shouldn't be used for things
related
to Bitcoin.

BOLTs also shouldn't have ever been a separate process and should
really
just get merged into BIPs. But at this point, that will probably take
quite a bit of effort, and obviously cooperation and active
involvement
from the Lightning development community.

Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had
time
to keep up. There are several PRs far more important than Ordinals
nonsense that need to be triaged and probably merged.

The issue with Ordinals is that it is actually unclear if it's
eligible
to be a BIP at all, since it is an attack on Bitcoin rather than a
proposed improvement. There is a debate on the PR whether the
"technically unsound, ..., or not in keeping with the Bitcoin
philosophy." or "must represent a net improvement." clauses (BIP
2) are
relevant. Those issues need to be resolved somehow before it could be
merged. I have already commented to this effect and given my own
opinions on the PR, and simply pretending the issues don't exist
won't
make them go away. (Nor is it worth the time of honest people to help
Casey resolve this just so he can further try to harm/destroy
Bitcoin.)

Luke


On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:
> On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via
bitcoin-dev wrote:
>> I have _not_ requested a BIP for OpenTimestamps, even though it
is of much
>> wider relevance to Bitcoin users than Ordinals by virtue of the
fact that much
>> of the commonly used software, including Bitcoin Core, is
timestamped with OTS.
>> I have not, because there is no need to document every single
little protocol
>> that happens to use Bitcoin with a BIP.
>>
>> Frankly we've 

Re: [bitcoin-dev] Ordinals BIP PR

[Luke Dashjr via bitcoin-dev]

Everything standardized between Bitcoin software is eligible to be and 
should be a BIP. I completely disagree with the claim that it's used for 
too many things.


SLIPs exist for altcoin stuff. They shouldn't be used for things related 
to Bitcoin.


BOLTs also shouldn't have ever been a separate process and should really 
just get merged into BIPs. But at this point, that will probably take 
quite a bit of effort, and obviously cooperation and active involvement 
from the Lightning development community.


Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time 
to keep up. There are several PRs far more important than Ordinals 
nonsense that need to be triaged and probably merged.


The issue with Ordinals is that it is actually unclear if it's eligible 
to be a BIP at all, since it is an attack on Bitcoin rather than a 
proposed improvement. There is a debate on the PR whether the 
"technically unsound, ..., or not in keeping with the Bitcoin 
philosophy." or "must represent a net improvement." clauses (BIP 2) are 
relevant. Those issues need to be resolved somehow before it could be 
merged. I have already commented to this effect and given my own 
opinions on the PR, and simply pretending the issues don't exist won't 
make them go away. (Nor is it worth the time of honest people to help 
Casey resolve this just so he can further try to harm/destroy Bitcoin.)


Luke


On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:

On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev wrote:

I have _not_ requested a BIP for OpenTimestamps, even though it is of much
wider relevance to Bitcoin users than Ordinals by virtue of the fact that much
of the commonly used software, including Bitcoin Core, is timestamped with OTS.
I have not, because there is no need to document every single little protocol
that happens to use Bitcoin with a BIP.

Frankly we've been using BIPs for too many things. There is no avoiding the act
that BIP assignment and acceptance is a mark of approval for a protocol. Thus
we should limit BIP assignment to the minimum possible: _extremely_ widespread
standards used by the _entire_ Bitcoin community, for the core mission of
Bitcoin.


This would eliminate most wallet-related protocols e.g. BIP69 (sorted
keys), ypubs, zpubs, etc. I don't particularly like any of those but if
they can't be BIPs then they'd need to find another spec repository
where they wouldn't be lost and where updates could be tracked.

The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not a BIP
in part because of perceived friction and exclusivity of the BIPs repo.
But I'm not thrilled with this situation.

In fact, I would prefer that OpenTimestamps were a BIP :).


It's notable that Lightning is _not_ standardized via the BIP process. I think
that's a good thing. While it's arguably of wide enough use to warrent BIPs,
Lightning doesn't need the approval of Core maintainers, and using their
separate BOLT process makes that clear.


Well, LN is a bit special because it's so big that it can have its own
spec repo which is actively maintained and used.

While it's technically true that BIPs need "approval of Core maintainers"
to be merged, the text of BIP2 suggests that this approval should be a
functionary role and be pretty-much automatic. And not require the BIP
be relevant or interesting or desireable to Core developers.



___
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

Re: [bitcoin-dev] Concern about "Inscriptions"

[Luke Dashjr via bitcoin-dev]

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=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 , 
 wrote:


Send bitcoin-dev mailing list submissions to
bitcoin-dev@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-requ...@lists.linuxfoundation.org

You can reach the person managing the list at
bitcoin-dev-ow...@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 +
From: Peter Todd 
To: Daniel Lipshitz 
Cc: Bitcoin Protocol Discussion
        
Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default
Message-ID: 
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
supp...@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  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 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Luke Dashjr via bitcoin-dev]

Action should have been taken months ago. Spam filtration has been a 
standard part of Bitcoin Core since day 1. It's a mistake that the 
existing filters weren't extended to Taproot transactions. We can 
address that, or try a more narrow approach like OP_RETURN (ie, what 
"Ordisrespector" does). Since this is a bugfix, it doesn't really even 
need to wait for a major release.


(We already have pruning. It's not an alternative to spam filtering.)

Luke


On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:

Hi guys,

I think everyone on this list knows what has happened to the Bitcoin 
mempool during the past 96 hours. Due to side projects such as BRC-20 
having such a high volume, real bitcoin transactions are being priced 
out and that is what is causing the massive congestion that has 
arguable not been seen since December 2017. I do not count the March 
2021 congestion because that was only with 1-5sat/vbyte.


Such justifiably worthless ("worthless" is not even my word - that's 
how its creator described them[1]) tokens threaten the smooth and 
normal use of the Bitcoin network as a peer-to-pear digital currency, 
as it was intended to be used as.


If the volume does not die down over the next few weeks, should we 
take an action? The bitcoin network is a triumvirate of developers, 
miners, and users. Considering that miners are largely the entities at 
fault for allowing the system to be abused like this, the harmony of 
Bitcoin transactions is being disrupted right now. Although this 
community has a strong history of not putting its fingers into pies 
unless absolutely necessary - an example being during the block size 
wars and Segwit - should similar action be taken now, in the form of 
i) BIPs and/or ii) commits into the Bitcoin Core codebase, to curtail 
the loophole in BIP 342 (which defines the validation rules for 
Taproot scripts) which has allowed these unintended consequences?


An alternative would be to enforce this "censorship" at the node level 
and introduce a run-time option to instantly prune all non-standard 
Taproot transactions. This will be easier to implement, but won't hit 
the road until minimum next release.


I know that some people will have their criticisms about this, 
absolutists/libertarians/maximum-freedom advocates, which is fine, but 
we need to find a solution for this that fits everyone's common 
ground. We indirectly allowed this to happen, which previously wasn't 
possible before. So we also have a responsibility to do something to 
ensure that this kind of congestion can never happen again using Taproot.


-Ali

---

[1]: 
https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/ 



___
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

Re: [bitcoin-dev] BIP for OP_VAULT

[Luke Dashjr via bitcoin-dev]

In ordinary use cases, you wouldn't clawback; that would only be in the 
extreme case of the wallet being compromised. So typical usage would 
just be receive -> send, like wallets currently do.


Luke


On 3/13/23 10:56, Greg Sanders wrote:
Didn't finish sentence: but in practice would end up with pretty 
similar usage flows imho, and as noted in PR, would take a different 
wallet paradigm,

among other technical challenges.

On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders  
wrote:


Hi Luke,

Can you elaborate why the current idealized functionality of
deposit -> trigger -> withdrawal is too complicated for
everyday use but the above deposit -> withdrawal ->
resolve(claim/clawback)  wouldn't be? I admit at a high level
it's a fine paradigm, but in practice would end

Let's ignore implementation for the discussion, since that's in flux.

Cheers,
Greg

On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev
 wrote:

I started reviewing the BIP, but stopped part way through, as
it seems
to have a number of conceptual issues.

I left several comments on the PR

(https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),

but ultimately I think it isn't simplified enough for
day-to-day use,
and would harm privacy quite a bit.

Instead, I would suggest a new approach where:

1) Joe receives funds with a taproot output like normal.
2) Joe sends funds to Fred, but Fred cannot spend them until N
blocks
later (covenant-enforced relative locktime). Ideally, this should
use/support a taproot keypath spend somehow. It would be nice
to blind
the particular relative locktime somehow too, but that may be
too expensive.
2b) If Joe's funds were stolen, Joe can spend Fred's UTXO
within the N
block window to a recovery output.

Unfortunately, the implementation details for this kind of
setup are
non-obvious and will likely require yet another address format
(or at
least recipient-wallet changes), but certainly seems within
the scope of
possibility.

Thoughts?

Luke


On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
> Since the last related correspondence on this list [0], a
number of
> improvements have been made to the OP_VAULT draft [1]:
>
> * There is no longer a hard dependence on package
relay/ephemeral
>   anchors for fee management. When using "authorized
recovery," all
>   vault-related transactions can be bundled with unrelated
inputs and
>   outputs, facilitating fee management that is self
contained to the
>   transaction. Consequently, the contents of this proposal
are in theory
>   usable today.
>
> * Specific output locations are no longer hardcoded in any
of the
>   transaction validation algorithms. This means that the
proposal is now
>   compatible with future changes like SIGHASH_GROUP, and
>   transaction shapes for vault operations are more flexible.
>
> ---
>
> I've written a BIP that fully describes the proposal here:
>
>

https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
>
> The corresponding PR is here:
>
> https://github.com/bitcoin/bips/pull/1421
>
> My next steps will be to try for a merge to the inquisition
repo.
>
> Thanks to everyone who has participated so far, but
especially to AJ and
> Greg for all the advice.
>
> James
>
> [0]:
>

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
> [1]: https://github.com/bitcoin/bitcoin/pull/26857
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for OP_VAULT

[Luke Dashjr via bitcoin-dev]

I started reviewing the BIP, but stopped part way through, as it seems 
to have a number of conceptual issues.


I left several comments on the PR 
(https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575), 
but ultimately I think it isn't simplified enough for day-to-day use, 
and would harm privacy quite a bit.


Instead, I would suggest a new approach where:

1) Joe receives funds with a taproot output like normal.
2) Joe sends funds to Fred, but Fred cannot spend them until N blocks 
later (covenant-enforced relative locktime). Ideally, this should 
use/support a taproot keypath spend somehow. It would be nice to blind 
the particular relative locktime somehow too, but that may be too expensive.
2b) If Joe's funds were stolen, Joe can spend Fred's UTXO within the N 
block window to a recovery output.


Unfortunately, the implementation details for this kind of setup are 
non-obvious and will likely require yet another address format (or at 
least recipient-wallet changes), but certainly seems within the scope of 
possibility.


Thoughts?

Luke


On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:

Since the last related correspondence on this list [0], a number of
improvements have been made to the OP_VAULT draft [1]:

* There is no longer a hard dependence on package relay/ephemeral
  anchors for fee management. When using "authorized recovery," all
  vault-related transactions can be bundled with unrelated inputs and
  outputs, facilitating fee management that is self contained to the
  transaction. Consequently, the contents of this proposal are in theory
  usable today.

* Specific output locations are no longer hardcoded in any of the
  transaction validation algorithms. This means that the proposal is now
  compatible with future changes like SIGHASH_GROUP, and
  transaction shapes for vault operations are more flexible.

---

I've written a BIP that fully describes the proposal here:

https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki

The corresponding PR is here:

https://github.com/bitcoin/bips/pull/1421

My next steps will be to try for a merge to the inquisition repo.

Thanks to everyone who has participated so far, but especially to AJ and
Greg for all the advice.

James

[0]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html

[1]: https://github.com/bitcoin/bitcoin/pull/26857

___
bitcoin-dev mailing list
bitcoin-dev@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

Re: [bitcoin-dev] Using service bit 24 for utreexo signaling in testnet and signet

[Luke Dashjr via bitcoin-dev]

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@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

Re: [bitcoin-dev] On mempool policy consistency

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Luke Dashjr via bitcoin-dev]

On Friday 05 August 2022 04:05:56 Ali Sherief wrote:
> Yeah, I have a specific reason to advance this first (emphasis on the word
> first).
>
> I briefly mentioned in the BIP that BIP322 has superior message
> verification capabilities. This is true, but it suffers from the drawback
> that wallets are not using it.

Likely because it is a draft and incomplete.

> Message signatures are highly relied upon in some places (just to name a
> few, at many mining pools e.g. Slushpool, and the Bitcointalk forum), 

I'm not aware of any using the current message signatures _correctly_.
Note they are not useful for proving that you sent a transaction, nor have the 
ability to send a transaction or access to bitcoins.

> This BIP is kind of like a "bumper car", in that it forces compliance with
> previous BIPs that extend the message signing format, in particular BIP137.

BIPs can't force anything, they're just documentation.

IMO, there is no benefit to an additional message signing standard, especially 
one that doesn't address the problems with the current standard or (at 
present) BIP322.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs

[Luke Dashjr via bitcoin-dev]

Policy is a subjective per-node, not systemic, not enforcable or expectable, 
and generally not eligible for standardization.

The reason BIP125 is an exception, is because it is more than just policy.
It is a way for wallets and nodes to communicate. The wallet is saying "this 
is the policy I would like you to apply to potential replacements of these 
transactions". Whether the nodes abide this request or not, the purpose and 
justification of the BIP is to standardize the communication of it.

Since BIP125 is widely implemented, it should not be changed except for 
corrections to things which are errors deviating from the original intent.
If there is merely a new policy intended to be conveyed, a new BIP should be 
written that is distinguishable from BIP125 (perhaps drop the sequence number 
by 1 more). However, unless nodes are going to honour both the BIP125-request 
policy *and* a new policy, it might be simpler for them to just not honour 
the requested BIP125 policy exactly.

Also note that security should NEVER depend on assumptions of node policies. 
Doing so would be a serious security vulnerability, regardless of what actual 
network policies are. It's fine to blame nodes/miners if they single out your 
transactions, but if it's just a matter of a general policy your transactions 
are failing to meet, that's on the sender/L2 to adapt.

Luke


On Thursday 04 August 2022 14:54:54 Michael Folkson via bitcoin-dev wrote:
> A short history of RBF and BIP125
>
> The history of BIP125 is as far as I’m aware this. RBF rules were merged
> into Bitcoin Core in November 2015 [0]. Following that merge David Harding
> and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had
> been implemented in Bitcoin Core. The rationales for the rules in the BIP
> was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!)
> when L2 protocols were in their infancy. Certainly the research on the
> security of L2 protocols has come a long way since and we have a much
> better idea of some of the possible attacks on L2 protocols that to some
> extent are impacted by policy rules.
>
> In addition it was discovered [2] in May 2021 that the Bitcoin Core
> implementation of the RBF rules had never matched the RBF rules outlined in
> BIP125. Clearly this isn’t ideal but mistakes happen and will continue to
> happen. I certainly do not intend any criticism whatsoever to any of the
> individuals involved. Thankfully this discrepancy doesn’t seem to have
> resulted in any loss of funds or disruption. However, cross checking a
> specification with an implementation presumably led to the discovery and
> allowed for a post mortem on why the implementation didn’t match the
> specification.
>
> There seems to be two views on what to do next given that the RBF rules
> need to be updated. One is to ditch the idea of a specification for RBF
> rules and just document them in the Core repo instead. The other is to have
> a new specification for the RBF rules in Core and attempt to correct the
> mistakes made with BIP125 by having a BIP that does correctly outline the
> RBF rules implemented in Core and includes detailed rationales for why
> those RBF rules have been implemented.
>
> Should anyone care about where things are documented?
>
> Perhaps not but I think if you are a stakeholder in L2 protocol security
> you should. Suppose in the long term future an attacker exploits a L2
> vulnerability that is based on the default policy set by the dominant
> implementation on the network (Bitcoin Core). Which would you prefer the
> norm to be? A detailed static, well reviewed BIP standard that lays out the
> updated RBF rules and the rationales for those new rules that is reviewed
> outside the Core repo and hence not just by Core reviewers? Or cross
> checking Bitcoin Core code with non-standardized Core documentation
> typically reviewed only by Core reviewers?
>
> For the same reason the norm for consensus changes is a specification (BIP)
> and a reference implementation (Bitcoin Core) I think the norm for material
> step change policy changes should be a specification (BIP) and a reference
> implementation (Bitcoin Core). Policy is of course less risky than
> consensus for various reasons including there being no chain split risk if
> the user changes the default policy of their node. Alternative
> implementations are free to set entirely different policy rules too. But
> with L2 protocol security to some extent relying on policy whether we like
> it or not I think we should aspire to similar standards where possible for
> policy too.
>
> Specifications and implementations
>
> The Bitcoin Core review process generally requires Concept ACKs, Approach
> ACKs and then code review, testing ACKs in that order. The reason for this
> is even if the code is perfect if it is implementing a concept or an
> approach that informed reviewers oppose then it doesn’t matter that the
> code is perfect. Documentation is 

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[Luke Dashjr via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Knots 23.0.knots20220529 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 23.0.knots20220529 is now available from:

  https://bitcoinknots.org/files/23.x/23.0.knots20220529/

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v23.0.knots20220529-release-notes/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Luke Dashjr via bitcoin-dev]

There's no reason for before/after/in place. We have version bits specifically 
so we can have multiple deployments in parallel.

But none of this ST nonsense, please. That alone is a reason to oppose it.

Luke


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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Luke Dashjr via bitcoin-dev]

On Thursday 21 April 2022 06:20:15 Jeremy Rubin wrote:
> > While reverting Segwit wouldn't be possible, it IS entirely possible to
> > do an additional softfork to either weigh witness data at the full 4
> > WU/Byte rate (same as other data), or to reduce the total weight limit so
> > as to extend the witness discount to non-segwit transactions (so scriptSig
> > is similarly discounted).
>
> What if I pre signed a transaction which was valid under the discounted
> weighting, but the increase in weight would make it invalid? This would
> serve to confiscate funds. Let's not do that.

You'd be confiscating your own funds by making an absurd spending condition.
By this argument, ALL softforks would have to be ruled out.

> > Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
> > variant which has no purpose other than to try to sabotage parallel UASF
> > efforts.
>
> Why didn't you upstream the code that was used for the actual activation
> into Bitcoin Core in the last year?
>
> In preparing it I just used what was available in Core now, surely the last
> year you could have gotten the appropriate patches done?

They were done, reviewed, and deployed in time for Taproot. You personally 
played a part in sabotaging efforts to get it merged into Core, and violating 
the community's trust in it by instead merging your BIP9 ST without 
consensus. Don't play dumb. You have nobody to blame but yourself.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Luke Dashjr via bitcoin-dev]

On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> @DavidHarding
>
> Interesting proposal to revert consensus changes. Is it possible to do this
> for soft forks that are already activated?

Generally, no. Reverting a softfork without a built-in expiry would be a 
hardfork.

> Example: Some users are not okay with witness discount in segwit
> transactions
>
> https://nitter.net/giacomozucco/status/1513614380121927682

While reverting Segwit wouldn't be possible, it IS entirely possible to do an 
additional softfork to either weigh witness data at the full 4 WU/Byte rate 
(same as other data), or to reduce the total weight limit so as to extend the 
witness discount to non-segwit transactions (so scriptSig is similarly 
discounted).

> @LukeDashjr
>
> > The bigger issue with CTV is the miner-decision route. Either CTV has
> > community support, or it doesn't. If it does, miners shouldn't have the
> > ability to veto it. If it doesn't, miners shouldn't have the ability to
> > activate it (making it a 51% attack more than a softfork).
>
> Agree. UASF client compatible with this speedy trial release for BIP 119
> could be a better way to activate CTV. Users can decide if they prefer
> mining pools to make the decision for them or they want to enforce it
> irrespective of how many mining pools signal for it. I haven't seen any
> arguments against CTV from mining pools yet.

We had that for Taproot, and now certain people are trying to say Speedy Trial 
activated Taproot rather than the BIP8 client, and otherwise creating 
confusion and ambiguity.

Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9 
variant which has no purpose other than to try to sabotage parallel UASF 
efforts.

At this point, it is probably better for any Speedy Trial attempts to be 
rejected by the community and fail outright. Perhaps even preparing a real 
counter-softfork to invalidate blocks signalling for it.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Luke Dashjr via bitcoin-dev]

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
> 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@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

Re: [bitcoin-dev] Speedy Trial

[Luke Dashjr via bitcoin-dev]

On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> The "no-miner-veto" concerns are, to an extent, addressed by the short
> timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
> their feet.

It's still a miner veto. The only way this works is if the full deployment 
(with UASF fallback) is released in parallel.

> If you are so concerned about listening to legitimate criticism, maybe you
> can design a new deployment mechanism that addresses the concerns of the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> faction.

BIP8 already does that.

> A major contender to the Speedy Trial design at the time was to mandate
> eventual forced signalling, championed by luke-jr.  It turns out that, at
> the time of that proposal, a large amount of hash power simply did not have
> the firmware required to support signalling.  That activation proposal
> never got broad consensus,

BIP 8 did in fact have broad consensus before some devs decided to ignore the 
community and do their own thing. Why are you trying to rewrite history?

> and rightly so, because in retrospect we see 
> that the design might have risked knocking a significant fraction of mining
> power offline if it had been deployed.  Imagine if the firmware couldn't be
> quickly updated or imagine if the problem had been hardware related.

They had 18 months to fix their broken firmware. That's plenty of time.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP review

[Luke Dashjr via bitcoin-dev]

On Tuesday 18 January 2022 22:02:24 e...@voskuil.org wrote:
> The only material distinction between BIP9 and BIP8 is that the latter may
> activate without signaled support of hash power enforcement.
>
> As unenforced soft forks are not "backward compatible" they produce a chain
> split.

Enforcement of the Bitcoin consensus protocol is by users, not miners.

Softforks never produce a chain split. Miners can, and might try to do it to 
cause disruption in retaliation, but the softfork itself does not.

> It was for this reason alone that BIP8 never gained sufficient 
> support.

BIP 8 in fact achieved consensus for Taproot activation.

> This is one of the most misleading statements I've seen here. It's not
> technically a lie, because it states what "should" happen. But it is
> clearly intended to lead people to believe that BIP8 was actually used
> ("again") - it was not. ST was some technical tweaks to BIP9.

BIP 8 was used to activate Taproot.

> The outright deception around this one topic has led to significant
> unnecessary conflict in the community. Make your argument, but make it
> honestly.

You are the one attempting to deceive here.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] CTV BIP review

[Luke Dashjr via bitcoin-dev]

tl;dr: I don't think CTV is ready yet (but probably close), and in any case 
definitely not worth reviving BIP 9 with its known flaws and vulnerability.

My review here is based solely on the BIP, with no outside context (aside from 
current consensus rules, of course). In particular, I have _not_ looked at 
the CTV code proposed for Bitcoin Core yet.

>Covenants are restrictions on how a coin may be spent beyond key ownership. 

nit: Poorly phrased. Even simple scripts can do that already.

>A few examples are described below, which should be the subject of future 
non-consensus standardization efforts.

I would ideally like to see fully implemented BIPs for at least one of these 
(preferably the claimed CoinJoin improvements) before we move toward 
activation.

>Congestion Controlled Transactions

I think this use case hasn't been fully thought through yet. It seems like it 
would be desirable for this purpose, to allow any of the recipients to claim 
their portion of the payment without footing the fee for every other payment 
included in the batch. This is still a covenant-type solution, but one that 
BIP 119 cannot support as-is.

(I realise this may be a known and accepted limitation, but I think it should 
be addressed in the BIP)

>Payment Channels

Why batch mere channel creation? Seems like the spending transaction should 
really be the channel closing.

>CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than 
previously because participants agree on a single output which pays all 
participants, which will be lower fee than before.

I don't see how. They still have to agree in advance on the outputs, and the 
total fees will logically be higher than not using CTV...?

>Further Each participant doesn't need to know the totality of the outputs 
committed to by that output, they only have to verify their own sub-tree will 
pay them.

I don't see any way to do this with the provided implementation.

>Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.

Hard NACK on this. BIP 9 at this point represents developers attempting to 
disregard and impose their will over community consensus, as well as an 
attempt to force a miner veto backdoor/vulnerability on deployment. It should 
never be used again.

Speedy Trial implemented with BIP 8 made sense* as a possible neutral 
compromise between LOT=True and LOT=False (which could be deployed prior to 
or in parallel), but using BIP 9 would destroy this.

As with Taproot, any future deployments should use BIP 8 again, until a better 
solution is developed. Reverting back to a known flawed and vulnerable 
activation method should not be done, and it would be better not to deploy 
CTV at all at such an expense.

The fact that certain developers attempted to deploy a BIP 9 alternative 
activation for Taproot against community consensus, and that even managed to 
get released as "Bitcoin Core", makes it all the more important that the 
community firmly rejects any further action to force this regression.

* it is my opinion a BIP 8 ST would be an okay compromise under those 
circumstances; others do disagree that ST is acceptable at all

> This ensures that for a given known input, the TXIDs can also be known ahead 
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched 
Channel Creation constructions as the redemption TXID could be malleated and 
pre-signed transactions invalidated, unless the channels are built using an 
Eltoo-like protocol.

Why is it a problem for them to use an Eltoo-like protocol?

Why not just commit to the txid itself if that's the goal?

>P2SH is incompatible with CHECKTEMPLATEVERIFY 

Maybe the CTV opcode should only be defined/enforced within witness scripts?

>nLockTime should generally be fixed to 0 (in the case of a payment tree, only 
the *first* lock time is needed to prevent fee-sniping the root)

Your "Congestion Controlled Transactions" example would only make sense with 
the spending transaction much later than the "root", and so could benefit 
from fee sniping malleability. (In fact, in that example, it would be better 
not to commit to locktime at all.)

>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to 
simple templates. The structure of CHECKTEMPLATEVERIFY template is such that 
the outputs must be known exactly at the time of construction. Based on a 
destructuring argument, it is only possible to create templates which expand 
in a finite number of steps.

It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get added.

>For example, a exchange's hot wallet might use an address which can 
automatically be moved to a cold storage address after a relative timeout.

Wouldn't it make more sense to just have a UTXO both cold+hot can spend, then 
throw away the hot key?

>In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make scripts 
valid for policy until the new rule is active.

Policy isn't validity, and 

[bitcoin-dev] Bitcoin Knots "Steel Rope" LTS 21.2.knots20210629 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 21.2.knots20210629 is now available from:

  https://bitcoinknots.org/files/21.x/21.2.knots20210629/

This Long Term Support (LTS) "Steel Rope" release is based on the unchanged
Bitcoin Knots feature set from 2021 June 29th, with only bug fixes and updated
translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v21.2.knots20210629/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Knots 22.0.knots20211108 released

[Luke Dashjr via bitcoin-dev]

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


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Luke Dashjr via bitcoin-dev]

All attempts are harmful, no matter the intent, in that they waste 
contributors' time that could be better spent on actual development.

However, I do also see the value in studying and improving the review process 
to harden it against such inevitable attacks. The fact that we know the NSA 
engages in such things, and haven't caught one yet should be a red flag.

Therefore, I think any such a scheme needs to be at least opt-out, if not 
opt-in. Please ensure there's a simple way for developers with limited time 
(or other reasons) to be informed of which PRs to ignore to opt-out of this 
study. (Ideally it would also prevent maintainers from merging - maybe 
possible since we use a custom merging script, but what it really needs to 
limit is the push, not the dry-run.)

Luke


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

Re: [bitcoin-dev] Clarification on the use of getblocktemplate RPC method.

[Luke Dashjr via bitcoin-dev]

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@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

[bitcoin-dev] Bitcoin Knots 0.21.1.knots20210629 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 0.21.1.knots20210629 is now available from:

  https://bitcoinknots.org/files/0.21.x/0.21.1.knots20210629/

This release includes new features, various bug fixes and performance 
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v0.21.1.knots20210629/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Luke Dashjr via bitcoin-dev]

> >> 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  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  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
> >>> >>  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 su

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Luke Dashjr via bitcoin-dev]

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
> 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Additional BIPs related to other proposals

[Luke Dashjr via bitcoin-dev]

On Friday 21 May 2021 07:56:51 Billy Tetrud via bitcoin-dev wrote:
> These look like relatively well put together documents. However, they seem
> relatively orthogonal to Bitcoin in that they look like protocols that
> build on top of the bitcoin platform but aren't directly related to
> changing how bitcoin operates at its base layer. Am I miss reading these?

BIPs are not limited to the base layer. Anything that coordinates between 
Bitcoin software at any layer can use BIPs.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

[Luke Dashjr via bitcoin-dev]

On Friday 14 May 2021 21:41:23 Michael Fuhrmann via bitcoin-dev wrote:
> Bitcoin should create blocks every 10 minutes in average. So why do
> miners need to mine the 9 minutes after the last block was found? It's
> not necessary.

It increases security, and is unavoidable anyway.

> Problem: How to prevent "pre-mining" in the 9 minutes time window?

You can't.

> Possible ideas for discussion:
>
> - (maybe most difficult) global network timer sending a salted hash time
> code after 9 minutes. this enables validation by nodes.

PoW *is* the global network timer.

> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> high enough) times higher difficulty. so everyone can mine any time but
> before to 9 minutes are up there will be a too high downside. It is more
> efficient to wait then paying high bills. The bitcoin will get a "puls".

There's no timestamp at this stage of consensus.

On Sunday 16 May 2021 18:10:12 Karl via bitcoin-dev wrote:
> The clock might be implementable on a peer network level by requiring
> inclusion of a transaction that was broadcast after a 9 minute delay.

That requires a centralised authority.

On Sunday 16 May 2021 20:31:47 Anton Ragin via bitcoin-dev wrote:
> 1. Has anyone considered that it might be technically not possible to
> completely 'power down' mining rigs during this 'cool-down' period of time?
> While modern CPUs have power-saving modes, I am not sure about ASICs used
> for mining.

That would be miners' problem, not the network's... New ASICs would no doubt 
be made to work more efficiently.

> 2. I am not a huge data-center specialist, but it was my understanding that
> they charge per unit of installed (maximum) electricity consumption. It
> would mean that if the miner needs X kilowatts-hour within that 1 minute
> when they are allowed to mine, he/she will have to pay for the same X for
> the remaining 9 minutes - and as such would have no economic incentive not
> to draw that power when idling.

Actually, this would be a good thing: it would heavily discourage datacentre 
use (which is very harmful to mining decentralisation).

> 4. My counter-proposal to the community to address energy consumption
> problems would be *to encourage users to allow only 'green miners' process
> their transaction.* In particular:
>...
> (b) Should there be some non-profit organization(s) certifying green miners 
> and giving them cryptographic certificates of conformity (either usage of
> green energy or purchase of offsets), users could encrypt their
> transactions and submit to mempool in such a format that *only green miners
> would be able to decrypt and process them*.

Hello centralisation. Might as well just have someone sign miner keys, and get 
rid of PoW entirely...

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic

[Luke Dashjr via bitcoin-dev]

Is there a list of software impacted by this CVE, and the versions it is fixed 
in?

(Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a policy 
matter, not part of the consensus rules and never safe to rely on in any 
case...)


On Thursday 06 May 2021 13:55:53 Antoine Riard via bitcoin-dev wrote:
> Hi,
>
> I'm writing to report a defect in Bitcoin Core bip125 logic with minor
> security and operational implications for downstream projects. Though this
> defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't
> impacted.
>
> # Problem
>
> Bip 125 specification describes the following signalling mechanism :
>
> "
> This policy specifies two ways a transaction can signal that it is
> replaceable.
>
> * Explicit signaling: A transaction is considered to have opted in to
> allowing replacement of itself if any of its inputs have an nSequence
> number less than (0x - 1).
>
> * Inherited signaling: Transactions that don't explicitly signal
> replaceability are replaceable under this policy for as long as any one of
> their ancestors signals replaceability and remains unconfirmed.
>
> One or more transactions currently in the mempool (original transactions)
> will be replaced by a new transaction (replacement transaction) that spends
> one or more of the same inputs if,
>
> # The original transactions signal replaceability explicitly or through
> inheritance as described in the above Summary section.
> "
>
> An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an
> unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable as
> the child transaction signals "through inheritance". However, the
> replacement code as implemented in Core's `PreChecks()` shows that this
> behavior isn't  enforced and Core's mempool rejects replacement attempts of
> an unconfirmed child transaction.
>
> Branch asserting the behavior is here :
> https://github.com/ariard/bitcoin/commits/2021-03-test-rbf
>
> # Solution
>
> The defect has not been patched.
>
> # Downstream Projects Affected
>
> * LN : State-of-the-art pinning attacks against second-stage HTLCs
> transactions were thought to be only possible by exploiting RBF rule 3 on
> the necessity of a higher absolute fee [0]. However, this replacement
> defect opens the way for an attacker to only pin with an opt-out child
> without a higher fee than the honest competing transaction. This lowers the
> cost of attack as the malicious pinning transaction only has to be above
> mempools'min feerate. This also increases odds of attack success for a
> reduced feerate diminishes odds of confirmation ending the pinning.
>
> A functional test demo illustrating cases is available on this branch:
> https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings
>
> LN nodes operators concerned by this defect might favor anchor outputs
> channels, fully mitigating this specific pinning vector.
>
> * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple
> stages of execution with time-sensitive transactions opening the way to
> pinning attacks. Those protocols being non-deployed or in early phase, I
> would recommend that any in-protocol competing transactions explicitly
> signal RBF.
>
> * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if
> the coinjoin transaction is still laying in network mempools, if a
> fee-bumping output is spendable by any protocol participant, this
> fee-bumping mechanism might be halted by a malicious protocol participant
> broadcasting an low-feerate opt-out child. According to bip125, if the
> coinjoin parent tx signals replaceability, the child transaction should be
> replaceable, whatever its signaling. However Core doesn't apply this
> policy. RBF of the coinjoin transaction itself should be used as a
> fallback. I'm not aware of any deployed coinjoin using such
> "anyone-can-bump" fee-bumping strategy.
>
> * Simple wallets : RBF engines' behaviors might be altered in ways not
> matching the intent of their developers. I invite RBF engines dev to verify
> what those components are doing in the light of disclosed information.
>
> # Discovery
>
> While reviewing the LN dual-funding flow, I inquired on potential new DoS
> vectors introduced by relying on counterparty utxos in this following
> analysis [1]. The second DoS issue "RBF opt-out by a Counterparty
> Double-Spend" is relying on a malicious chain of transactions where the
> parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the
> child, servicing as a pinning transaction, opt-out from the RBF policy.
> This pinning trick conception was matching my understanding of Core code
> but while reading again the specification, I observed that it was
> inconsistent from the inherited signaling mechanism as described in the
> bip's "Summary" section.
>
> After exercising the logic, I did submit the defect to Dave Harding, asking
> confirmation of divergence between 

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

[Luke Dashjr via bitcoin-dev]

On Sunday 25 April 2021 20:29:44 Matt Corallo wrote:
> If the BIP editor is deliberately refusing to accept changes which the
> author's approval (which appears to be occurring here),

It isn't. I am triaging BIPs PRs the same as I have for years, and will get to 
them all in due time, likely before the end of the month.

Rather, what we have going on is a few bad actors trying to misportray the 
BIPs as an approval process so they can pretend ST is somehow official, or 
that the preexisting Core+Taproot client is "breaking" the spec. And to 
further their agenda, they have been harassing me demanding special 
treatment.

I will not become an accomplice to this deception by giving special treatment, 
and will process the BIP PR neutrally according to the currently-defined BIP 
process.

Despite the continual harassment, I have even made two efforts to try to 
(fairly) make things faster, and have been obstructed both times by ST 
advocates. It appears they intend to paint me as "deliberately refusing" (to 
use your words) in order to try to put Bitcoin and the BIP process under 
their control, and abuse it in the same manner in which they abused Bitcoin 
Core's usual standards (by releasing ST without community consensus).

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIPs - notarization protocol and decentralized storage

[Luke Dashjr via bitcoin-dev]

On Wednesday 21 April 2021 04:26:26 Prayank via bitcoin-dev wrote:
> Also since this involves LN, maybe it can just be a LN project instead of
> BIP? Not the best person to comment on what can be a BIP.

Anything that Bitcoin software would benefit in collaboration with other 
projects on qualifies.

Lightning itself really should be a series of BIPs.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposed BIP editor: Kalle Alm

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

[Luke Dashjr via bitcoin-dev]

(To reiterate: I do not intend any of this as a NACK of Taproot.)

On Monday 15 March 2021 22:05:45 Matt Corallo wrote:
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> > efforts discouraging address use. If the standard loses the hash, the
> > situation cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at
> least nine years and still haven't solved it.

I think we've made progress over those 9 years, don't you?

> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it can
> > be seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> > supply minable by QCs is really no different than 37% minable by ASICs.
> > (We've seen far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of
> supply rather quickly (presumably over the course of a few days, at
> maximum), instead of a slow process with significant upfront real-world
> cost in the form of electricity.

My understanding is that at least initial successes would likely be very slow.
Hopefully we would have a permanent solution before it got too out of hand.


On Monday 15 March 2021 23:01:47 Karl-Johan Alm via bitcoin-dev wrote:
> The important distinction here is that, with hashes, an attacker has
> to race against the spending transaction confirming, whereas with
> naked pubkeys, the attacker doesn't have to wait for a spend to occur,
> drastically increasing the available time to attack.

More importantly, once an attack is recognised, with hashes, people can simply 
stop sending transactions and await a fix, to protect their stash. Without 
hashes, there is no defense at all (other than sending bitcoins to a 
non-taproot address and hoping they evade the attack in time).


On Monday 15 March 2021 23:12:18 Andrew Poelstra wrote:
> "No gain" except to save significant CPU time and bandwidth?

The CPU time is localised to involved nodes, and (correct me if I'm wrong) 
trivial in comparison to what is required to run a full node in the first 
place. I'm not sure how it looks with bandwidth.

> Having exposed keys also lets you do ring signatures over outputs, creating
> the ability to do private proof of funds via Provisions.

But you can also do comparable proofs behind a hash with Bulletproofs, right?

> > Despite this, I still don't think it's a reason to NACK Taproot: it
> > should be fairly trivial to add a hash on top in an additional softfork
> > and fix this.
>
> This would make Bitcoin strictly worse.

How so? People could just not use it if they don't care, right?
The alternative (if people care enough) is that those concerned about quantum 
risk would be forced to forego the benefits of Taproot and stick to p2pkh or 
such, which seems like an artificial punishment.

> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> > is at risk" argument. This argument is based in part on the fact that
> > many people reuse Bitcoin invoice addresses.
>
> 37% is a dramatic understatement. Every address which is derived using
> BIP32 should be assumed compromised to a QC attacker because xpubs are not
> treated like secret key material and are trivial to e.g. extract from
> hardware wallets or PSBTs. I expect the real number is close to 100%.

xpubs should be treated like secret key material IMO.

A quantum attacker would need to compromise your PC to attack a hardware 
wallet, right?

> In any case, Taproot keys, when used according to the recommendation in
> BIP-0341, are already hashes of their internal keys, so (a) Taproot outputs
> actually have better quantum resistance than legacy outputs; and (b) adding
> another hash would be strictly redundant.

It not only stops the attacker from obtaining the original key, but also 
prevents creating a new private key that can spend the output?


On Tuesday 16 March 2021 02:38:55 ZmnSCPxj via bitcoin-dev wrote:
> From this point-of-view, it seems to me that the amount of energy to mount
> a "fast" attack may eventually approach the energy required by mining, in
> which case someone who possesses the ability to mount such an attack may
> very well find it easier to just 51% the network (since that can be done
> today without having to pour R satoshis into developing practical quantum
> computers).

Mining adapts its difficulty to the block rate, so it will slow you down up to 
4x each retarget. An attack on public keys would probably scale better. :)

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] PSA: Taproot loss of quantum protections

[Luke Dashjr via bitcoin-dev]

I do not personally see this as a reason to NACK Taproot, but it has become 
clear to me over the past week or so that many others are unaware of this 
tradeoff, so I am sharing it here to ensure the wider community is aware of 
it and can make their own judgements.

Mark Friedenbach explains on his blog:
https://freicoin.substack.com/p/why-im-against-taproot

In short, Taproot loses an important safety protection against quantum.
Note that in all circumstances, Bitcoin is endangered when QC becomes a 
reality, but pre-Taproot, it is possible for the network to "pause" while a 
full quantum-safe fix is developed, and then resume transacting. With Taproot 
as-is, it could very well become an unrecoverable situation if QC go online 
prior to having a full quantum-safe solution.

Also, what I didn't know myself until today, is that we do not actually gain 
anything from this: the features proposed to make use of the raw keys being 
public prior to spending can be implemented with hashed keys as well.
It would use significantly more CPU time and bandwidth (between private 
parties, not on-chain), but there should be no shortage of that for anyone 
running a full node (indeed, CPU time is freed up by Taproot!); at worst, it 
would create an incentive for more people to use their own full node, which 
is a good thing!

Despite this, I still don't think it's a reason to NACK Taproot: it should be 
fairly trivial to add a hash on top in an additional softfork and fix this.

In addition to the points made by Mark, I also want to add two more, in 
response to Pieter's "you can't claim much security if 37% of the supply is 
at risk" argument. This argument is based in part on the fact that many 
people reuse Bitcoin invoice addresses.

First, so long as we have hash-based addresses as a best practice, we can 
continue to shrink the percentage of bitcoins affected through social efforts 
discouraging address use. If the standard loses the hash, the situation 
cannot be improved, and will indeed only get worse.

Second, when/if quantum does compromise these coins, so long as they are 
neglected or abandoned/lost coins (inherent in the current model), it can be 
seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply 
minable by QCs is really no different than 37% minable by ASICs. (We've seen 
far higher %s available for mining obviously.)

To conclude, I recommend anyone using Bitcoin to read Mark's article, my 
thoughts, and any other arguments on the topic; decide if this is a concern 
to you, and make your own post(s) accordingly. Mark has conceded the argument 
(AFAIK he doesn't have an interest in bitcoins anyway), and I do not consider 
it a showstopper - so if anyone else out there does, please make yourself 
known ASAP since Taproot has already moved on to the activation phase and it 
is likely software will be released within the next month or two as things 
stand.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Luke Dashjr via bitcoin-dev]

I am referring to the timeline and recommendation from the meeting on February 
16th, which has been slowly making progress toward a release:

https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102

The first period from height 693504-695520 here overlaps with the last period 
of AChow's ST pull request.

A release today is impossible of course. But 1 or 2 days late is nothing 
compared to waiting a week and not having even gotten started. :)
I expect/hope that there will be consensus to adapt around ST, shifting 
everything later, but I'm just one person.

roconnor pointed out that the best solution is probably to just enclose ST's 
timeline; something like this:

https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/3/files#diff-e43ac101b32b6804209cfdf26da4d122e54b994eb7f1538d4378f6a508dab817L529

Luke



On Monday 15 March 2021 20:59:11 Jeremy wrote:
> Can you expand on the timeline issue? Which timelines are incompatible and
> why?
>
> It does seem like a release done *today* cannot happen anyways, so it
> sounds like it's already too late... or do you mean beginning the release
> process today?
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr  wrote:
> > While I agree 24 hours is too short notice, if someone wishes to insist
> > on keeping the current timeline, software supporting it should be
> > released _today_. Putting the meeting off a week would almost necessarily
> > imply rejection of any desires to stick to the original plan.
> >
> > So for that reason, I think we need to at least try to have a meeting
> > tomorrow, at least to give anyone who won't agree to such a delay a
> > chance to
> > speak up before it's too late, and have his argument fairly considered.
> >
> > We can still have a meeting next week. The idea of having one every other
> > week
> > seems like a good idea to avoid this in the future, too.
> >
> > Luke
> >
> > On Monday 15 March 2021 19:14:02 Jeremy wrote:
> > > Please announce such meetings with more than ~24 hours notice -- this
> > > has happened several times and while I recognize the pace of
> > > development on this issue I think that slotting a consensus meeting
> > > with less than 24 hours is inappropriate.
> > >
> > > I think we should proactively postpone it a week so that there isn't an
> > > arbitrary "too low turnout" measure and instead anyone who really wants
> >
> > to
> >
> > > be present for the meeting can plan to be.
> > >
> > > So as not to lose momentum on having a discussion, I propose to plan to
> > > hold a general discussion tomorrow at that time and a meeting (with the
> > > intent of resolving issues in a more binding way) next week. It may be
> > > a good idea to hold the time slot every other week for the next while
> > > so
> >
> > that
> >
> > > we can avoid this 24 hour thing altogether.
> > >
> > > It sucks to lose another week but a precedent of 24 hour notice
> > > meetings for non urgent changes is very negative.
> > >
> > > (This isn't any comment on if ST is OK or not -- the schedules proposed
> >
> > for
> >
> > > ST thus far seem acceptable to me)
> > >
> > > Best,
> > >
> > > Jeremy
> > > --
> > > @JeremyRubin <https://twitter.com/JeremyRubin>
> > > <https://twitter.com/JeremyRubin>
> > >
> > >
> > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
> > >
> > > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > At the previous meeting, there was consensus for BIP8 activation
> > > > parameters
> > > > except for LOT, assuming a release around this time. Since then, a
> > > > release has not occurred, and the new idea of Speedy Trial has been
> > > > proposed to preempt the original/main activation plan.
> > > >
> > > > It's probably a good idea to meet up again to discuss these things
> > > > and adjust
> > > > accordingly.
> > > >
> > > > Agenda:
> > > >
> > > > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > > >   (Note: current draft conflicts with original plan timeline)
> > > >
> > > > - Main activation, post ST: Moving startheight (and timeoutheight?)
> >
> > later
> >
> > > >   is probably a good idea at this point, both because too 

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Luke Dashjr via bitcoin-dev]

While I agree 24 hours is too short notice, if someone wishes to insist on 
keeping the current timeline, software supporting it should be released 
_today_. Putting the meeting off a week would almost necessarily imply 
rejection of any desires to stick to the original plan.

So for that reason, I think we need to at least try to have a meeting 
tomorrow, at least to give anyone who won't agree to such a delay a chance to 
speak up before it's too late, and have his argument fairly considered.

We can still have a meeting next week. The idea of having one every other week 
seems like a good idea to avoid this in the future, too.

Luke


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

[bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

[Luke Dashjr via bitcoin-dev]

At the previous meeting, there was consensus for BIP8 activation parameters 
except for LOT, assuming a release around this time. Since then, a release 
has not occurred, and the new idea of Speedy Trial has been proposed to 
preempt the original/main activation plan.

It's probably a good idea to meet up again to discuss these things and adjust 
accordingly.

Agenda:

- Speedy Trial: Can we get a comparable consensus on the proposal?
  (Note: current draft conflicts with original plan timeline)

- Main activation, post ST: Moving startheight (and timeoutheight?) later
  is probably a good idea at this point, both because too little progress has
  been made on it, and to avoid the conflict with the current ST draft.

- Making progress: To date, too few people have been involved in materialising
  the main activation plan. If it's going to move forward, more people need to
  get actively involved. This should not wait for ST to complete, unless we
  want another 4-5 month slip of the timeline.

This meeting is tentatively scheduled for *tomorrow*, March 16th at the usual 
time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If turnout 
is too low, we can postpone it a week, but it'd be nice to get things 
resolved and moving sooner.

As a reminder, the channel is also open for ongoing discussion 24/7, and there 
is a web chat client here:

https://webchat.freenode.net/?channel=##taproot-activation

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

The last period before timeoutheight here overlaps with the current BIP8(True) 
deployment plan. So if this period specifically were to reach 90% signalling, 
nodes would activate Taproot at height 697536, but ST-only nodes would still 
wait until 709632 instead.

Probably the best solution is to just move this ST window 1 period earlier?

Luke


On Saturday 06 March 2021 06:04:22 Andrew Chow via bitcoin-dev wrote:
> I like this idea.
>
> In terms of actual parameters, I propose that we base this Speedy Trial
> off of BIP 8 with the following parameters:
> * start height = 681408
> * timeout height = 695520
> * lockinontimeout = False
> * signaling bit = 2
> * threshold = 1815/2016 blocks (90%)
>
> For the extended lockin period, I propose 14112 blocks, which is 7
> retarget periods. Thus the earliest activation height will be 697536 and
> the latest activation height will be 709632.
>
> This will give us an approximate start time of May 1st 2021 and an
> approximate timeout time of August 7th 2021, for a total activation
> period of just over 3 months. The extended lockin period is the same
> number of blocks as the activation period so that will also be just over
> 3 months, giving us the latest activation time of November 13th, 2021.
> If miners activated as soon as possible, the earliest activation time
> would be August 21st 2021.
>
> Additionally, this timeline assumes a mid-April release of Bitcoin Core
> 0.21.1 containing these parameters. They could be changed to move up if
> the expected release date were sooner.
>
>
> Andrew Chow
>
> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
> > On the ##taproot-activation IRC channel, Russell O'Connor recently
> > proposed a modification of the "Let's see what happens" activation
> > proposal.[1] The idea received significant discussion and seemed
> > acceptable to several people who could not previously agree on a
> > proposal (although this doesn't necessarily make it their first
> > choice).  The following is my attempt at a description.
> >
> > 1. Start soon: shortly after the release of software containing this
> > proposed activation logic, nodes will begin counting blocks towards
> > the 90% threshold required to lock in taproot.[2]
> >
> > 2. Stop soon: if the lockin threshold isn't reached within approximately
> > three months, the activation attempt fails.  There is no mandatory
> > activation and everyone is encouraged to try again using different
> > activation parameters.
> >
> > 2. Delayed activation: in the happy occasion where the lockin threshold
> > is reached, taproot is guaranteed to eventually activate---but not
> > until approximately six months after signal tracking started.
> >
> > ## Example timeline
> >
> > (All dates approximate; see the section below about BIP9 vs BIP8.)
> >
> > - T+0: release of one or more full nodes with activation code
> > - T+14: signal tracking begins
> > - T+28: earliest possible lock in
> > - T+104: locked in by this date or need to try a different activation
> > process - T+194: activation (if lockin occurred)
> >
> > ## Analysis
> >
> > The goal of Speedy Trial is to allow a taproot activation attempt to
> > either quickly succeed or quickly fail---without compromising safety in
> > either case.  Details below:
> >
> > ### Mitigating the problems of early success
> >
> > New rules added in a soft fork need to be enforced by a large part of
> > the economy or there's a risk that a long chain of blocks breaking the
> > rules will be accepted by some users and rejected by others, causing a
> > chain split that can result in large direct losses to transaction
> > receivers and potentially even larger indirect losses to holders due to
> > reduced confidence in the safety of the Bitcoin system.
> >
> > One step developers have taken in the past to ensure widespread adoption
> > of new consensus rules is programming in a delay between the time
> > software with those rules is expected to be released and when the
> > software starts tracking which blocks signal for activation.  For
> > example:
> >
> >  Soft fork| Release| Start  | Delta
> >  -+++--
> >  BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days
> >  BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
> >
> >  Sources: BitcoinCore.org,
> > https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
> >
> > Speedy Trial replaces most of that upfront delay with a backend delay.
> > No matter how fast taproot's activation threshold is reached by miners,
> > there will be six months between the time signal tracking starts and when
> > nodes will begin enforcing taproot's rules.  This gives the userbase even
> > more time to upgrade than if we had used the most recently proposed start
> > date for a BIP8 activation (~July 23rd).[2]
> >
> > ### Succeed, or fail fast
> >
> > The earlier version of this proposal was documented 

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

[Luke Dashjr via bitcoin-dev]

On Friday 05 March 2021 14:51:12 Ryan Grant via bitcoin-dev wrote:
> On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
>
>  wrote:
> > So that leads me to believe here that the folks who oppose LOT=true
> > primarily have an issue with forced signaling, which personally I
> > don't care about as much, not the idea of committing to a UASF from
> > the get go.
>
> The biggest disconnect is between two goals: modern soft-fork
> activation's "Don't (needlessly) lose hashpower to un-upgraded
> miners"; and UASF's must-signal strategy to prevent inaction.
>
>  
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547
>.html
>
> This question dives to the heart of Bitcoin's far-out future.
> Of two important principles, which principle is more important:
>
>   - to allow everyone (even miners) to operate on the contract they
> accepted when entering the system; or

There was never any such a contract. Even full nodes must upgrade in a 
softfork, or they lose their security and become comparable to light wallets.

>   - to protect against protocol sclerosis for the project as a whole?

What?

> Do miners have a higher obligation to evaluate upgrades than economic
> nodes implementing cold storage and infrequent spends?  If they do,
> then so far it has been implicit.  LOT=true would make that obligation
> explicit.

Miners either make valid blocks or they don't.
The only thing they "need" to evaluate is the market for their work.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Luke Dashjr via bitcoin-dev]

On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote:
> I'm realizing that a clear advantage of LOT=false is that it can happen
> without the need for a social movement. All that is really needed is the
> convincing of 95% miners. Apathetic users will never notice any kind of
> service disruption no matter the success or failure of the activation. This
> is obviously why it naturally became the default activation method.

No. Miners enforcing rules without the social support is a 51% attack, not a 
softfork.

> While LOT=true, on the other hand, must be able to 51% the blockchain to
> win the apathetic users. But then the reorgs will not be pretty. Or if it
> ever clearly gets over the 51% hurdle then all apathetic users now need to
> scramble to use the rogue client to be safe from reorgs. Either way it's
> disruptive.

No, LOT=True doesn't do this. It only happens if miners choose to create an 
invalid chain, which they could do at any time with or without a softfork 
involved.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

[Luke Dashjr via bitcoin-dev]

Answering the F1-F7 arguments for LOT=False...

> F1) The probability of Taproot not being activated by miners is small. This
> is not 2017, this is not SegWit, there is no need to worry.

While we believe miners have no reason to sabotage Taproot activation, this 
was also the belief leading up to Segwit’s activation in 2017, and regardless 
it is not desirable to create such a risk forcing the community to place 
extra trust in miners. Miners might very well not exploit an inflation bug, 
but that is no reason to purposefully add an inflation bug.

> F2) The worst case scenario is we have to wait over a year for Taproot to
> be activated. Even the worst case scenario is not a disaster.

While it is true that a second activation can be deployed in the event of the 
first one failing, doing so would not necessarily change the situation unless 
LOT were changed to true anyway - in which case, it might as well be true for 
the initial deployment as well. Furthermore, a re-deployment could create a 
situation where users believe they have already upgraded for Taproot, but do 
not enforce it due to not understanding the need to upgrade yet again.

> F3) If in the unlikely scenario miners did not activate Taproot for a year
> for no apparent reason we would never set LOT to false again for any
> potential future soft fork. If miners fail to activate Taproot despite
> pledging support and there being overwhelming community consensus for it,
> it would set a precedent that miners cannot be relied upon *at all* to
> activate soft forks.

Setting LOT=false with a threat to change it to true later is antagonistic 
against miners. With LOT=true, expectations are simply made clear and miners 
can simply cooperate by making valid blocks as they do day-to-day already.

> F4) If in the highly unlikely scenario that a bug or some problem with the
> Taproot implementation was found during the signaling period miners could
> choose not to activate it which is cleaner than needing an emergency Core
> release.

The risk that a bug in Taproot is discovered this late yet before activation, 
to warrant aborting the deployment, is extremely low (much lower than the 
risks created by LOT=false). Even if such a scenario occurred, and even with 
LOT=false, users would still need to upgrade to back out the deployment. In 
the best-case scenario, users would need to upgrade to deploy the fixed 
Taproot. So in the end, nothing is to be gained from relying on a miner abort 
for such scenarios.

> F5) LOT = false is more similar to what was done previously (unless you go
> way back to the earliest soft forks which were more similar to LOT = true)

The behaviour of LOT=false has proven problematic and caused failure of Segwit 
activation in 2017. LOT=true behaviour has a long history of success, and was 
used to resolve and activate Segwit in 2017 after LOT=false’s failure.

> F6) It is more important that no rules that harm users are deployed than it
> is that new useful rules are deployed quickly. If there is a choice between
> “faster” and “more clear that this isn’t a mechanism to force bad things on
> users” we should prefer the latter. Plenty of people just don’t like
> LOT=true very much absent evidence that miners are blocking deployment. To
> some it just feels needlessly antagonistic and distrusting towards part of
> our community.

Any deployment, or even status quo, can be falsely portrayed/spun in a way to 
harm Bitcoin. As such, only objective criteria should be considered.

BIP 8 makes it explicitly easy for people to reject the softfork if they don't 
like it, so any claim of being "forced" is a non-starter to an honest person.

> F7) defaulting to LOT=false makes non-activation possible even if people
> run the code that developers provide, meaning a successful
> activation proves that at least some people (e.g. miners or UASFers)
> voluntarily took actions that were well outside the scope of
> developer control.
>
> This makes it clear that developers don't control changes to the
> system.  There are other arguments that demonstrate that developers
> aren't in control[1], but they aren't as clear as simply pointing
> out that a rule change won't go into effect until at least several
> non-developers independently act of their own accord.
>
> Having such a clear argument that developers aren't in control
> bolsters the decentralized ethos of Bitcoin and reduces the chance
> that bad actors will pressure Bitcoin developers to attempt future
> unwanted changes.

Even if developers release software, it must still be accepted by the 
community in the form of actively choosing to run the software which includes 
the activation. So long as the activation is clearly and prominently 
documented, users have taken the action to accept the protocol change. 
Furthermore, the community has already demonstrated a clear and undisputed 
support for the activation of Taproot. If there 

[bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Luke Dashjr via bitcoin-dev]

(Note: I am writing this as a general case against LOT=False, but using 
Taproot simply as an example softfork. Note that this is addressing 
activation under the assumption that the softfork is ethical and has 
sufficient community support. If those criteria have not been met, no 
activation should be deployed at all, of any type.)

As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, 
despite its potential benefits, also leaves open the door to a miner veto. 
This was never the intended behaviour, and a bug, which took a rushed 
deployment of BIP148 to address. LOT=False would reintroduce that same bug.
It wouldn't be much different than adding back the inflation bug 
(CVE-2018-17144) and trusting miners not to exploit it.

Some have tried to spin LOT=True as some kind of punishment for miners or 
reactive "counter-attack". Rather, it is simply a fallback to avoid 
regression on this and other bugs. "Flag day" activation is not fundamentally 
flawed or dangerous, just slow since everyone needs time to upgrade.
BIP 8(LOT=True) combines the certainty of such a flag day, with the speed 
improvement of a MASF, so that softforks can be activated both reasonably 
quick and safely.

In the normal path, and that which BIP8(True) best incentivises, miners will 
simply upgrade and signal, and activation can occur as soon as the economic 
majority is expected to have had time to upgrade. In the worst-case path, the 
behaviour of LOT=True is the least-harmful result: unambiguous activation and 
enforcement by the economy, with miners either deciding to make an 
anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners 
revolt against the softfork, the LOT=True nodes are simply faced with a 
choice to hardfork (replacing the miners with a PoW change) or concede - they 
do not risk vulnerability or loss.

With LOT=False in the picture, however, things can get messy: some users will 
enforce Taproot(eg) (those running LOT=True), while others will not (those 
with LOT=False). Users with LOT=True will still get all the safety thereof, 
but those with LOT=False will (in the event of miners deciding to produce a 
chain split) face an unreliable chain, being replaced by the LOT=True chain 
every time it overtakes the LOT=False chain in work. For 2 weeks, users with 
LOT=False would not have a usable network. The only way to resolve this would 
be to upgrade to LOT=True or to produce a softfork that makes an activated 
chain invalid (thereby taking the anti-Taproot path). Even if nobody ran 
LOT=True (very unlikely), LOT=False would still fail because users would be 
faced with either accepting the loss of Taproot(eg), or re-deploying from 
scratch with LOT=True. It accomplishes nothing compared to just deploying 
LOT=True from the beginning. Furthermore, this process creates a lot of 
confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I have 
to do it AGAIN?"), and in some scenarios additional code may be needed to 
handle the subsequent upgrade cleanly.

To make matters worse for LOT=False, giving miners a veto also creates an 
incentive to second-guess the decision to activate and/or hold the activation 
hostage. This is a direct result of the bug giving them a power they weren't 
intended to have. Even if we trust miners to act ethically, that does not 
justify sustaining the bug creating both a possibility and incentive to 
behave unethically.

So in all possible scenarios, LOT=False puts users and the network at 
significant risk. In all possible scenarios, LOT=True minimises risk to 
everyone and has no risk to users running LOT=True.

The overall risk is maximally reduced by LOT=True being the only deployed 
parameter, and any introduction of LOT=False only increases risk probability 
and severity.

For all these reasons, I regret adding LOT as an option to BIP 8, and think it 
would be best to remove it entirely, with all deployments in the future 
behaving as LOT=True. I do also recognise that there is not yet consensus on 
this, and for that reason I have not taken action (nor intend to) to remove 
LOT from BIP 8. However, the fact remains that LOT=False should not be used, 
and it is best if every softfork is deployed with LOT=True.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold

[Luke Dashjr via bitcoin-dev]

This has the same problems BIP149 did: since there is no signalling, it is 
ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF 
nodes will remain on the same chain, with conflicting perceptions of the 
rules, and resolution (if ever) will be chaotic. Absent resolution, however, 
there is a strong incentive not to rely on the rules, and thus it may never 
get used, and therefore also never resolved.

Additionally, it loses the flexibility of BIP 8 to, after the initial 
deployment, move the timeoutheight sooner.

Luke


On Thursday 25 February 2021 22:33:25 Gregorio Guidi via bitcoin-dev wrote:
> Hello,
>
> I followed the debate on LOT=false / LOT=true trying to get a grasp of
> the balance of risks and advantages. The summary by Aaron van Wirdum [1]
> explains well the difficulties to find a good equilibrium... it
> concludes that "perhaps, a new possibility will present itself".
>
> Thinking about such a "new possibility" that overcomes the
> LOT=true/false dichotomy, I would like to offer the following proposal.
> It could be called "decreasing threshold activation".
>
> Decreasing threshold activation works similarly to BIP8, with the
> difference that the threshold that triggers the STARTED -> LOCKED_IN
> transition starts at 100% for the first retargeting period, and then is
> gradually reduced on each period in steps of 24 blocks (~1,2%). More
> precisely:
>
> On the 1st period (starting on start_height): if 2016 out of 2016 blocks
> signal, the state is changed to LOCKED_IN on the next period (otherwise
> stays STARTED)
> On the 2nd period: if 1992 out of 2016 blocks signal (~98.8%), the state
> transitions to LOCKED_IN on the next period
> On the 3rd period: if 1968 out of 2016 blocks signal (~97.6%), the state
> transitions to LOCKED_IN on the next period
> ...
> On the 14th period (~6 months): if 1704 out of 2016 blocks signal
> (~84.5%), the state transitions to LOCKED_IN on the next period
> ...
> On the 27th period (~12 months): if 1392 out of 2016 blocks signal
> (~69.0%), the state transitions to LOCKED_IN on the next period
> ...
> On the 40th period (~18 months): if 1080 out of 2016 blocks signal
> (~53.6%), the state transitions to LOCKED_IN on the next period
> ...
> On the 53th period (~24 months): if 768 out of 2016 blocks signal
> (~38.1%), the state transitions to LOCKED_IN on the next period
> ...
> On the 66th period (~30 months): if 456 out of 2016 blocks signal
> (~22.6%), the state transitions to LOCKED_IN on the next period
> ...
> On the 79th period (~36 months): if 144 out of 2016 blocks signal
> (~7.1%), the state transitions to LOCKED_IN on the next period
> ...
> On the 84th and final period (~39 months): if 24 out of 2016 blocks
> signal (~1.2%), the state transitions to LOCKED_IN on the next period,
> otherwise goes to FAILED
>
> (For reference, I include below a snippet of pseudocode for the
> decreasing thresholds in the style of BIP8 and BIP9.)
>
> Here are the main features and advantages of this approach:
>
> 1. It is relatively conservative at the beginning: for activation to
> happen in the first year, it requires a clear majority of signaling
> hashrate, indicating that the activation is relatively safe. Only later
> the threshold starts to move towards "unsafe" territory, accepting the
> tradeoff of less support from existing hashrate in exchange for ensuring
> that the activation eventually happens.
>
> 2. Like LOT=true, the activation will always occur in the end (except in
> the negligible case where less than 1.2% of hashrate supports it).
>
> 3. This approach is quite easy to implement, in particular it avoids the
> extra code to deal with the MUST_SIGNAL period.
>
> 4. There are no parameters to set (except startheight). I am a KISS fan,
> so this is a plus for me, making the activation mechanism robust and
> predictable with less chance for users to shoot themselves in the foot.
> It is also a plus for me that - if adopted as the default mechanism - it
> would require very little discussion on how to activate future
> soft-forks. In fact I think it would be a winning move for Core to
> commit to such a scheme, to avoid getting lost in game-theoretic rabbit
> holes.
>
> 5. Since there is no MUST_SIGNAL period, no automatic chain split occurs
> around activation when not all miners have upgraded (so activation is
> generally as benign as a MASF). A chain split will occur only when/if an
> invalid block is created (and this requires dedicated effort! it can
> only happen by circumventing the normal policy rules [2]). This
> mitigates the risk of reorgs and involuntary forks around activation,
> even with low miner signaling.
>
> 6. It removes motivation to create UASF clients that force activation.
> While individual nodes could still try to force a quicker activation,
> the motivation to do so is reduced since the same result is obtained
> just by waiting a little more.
>
> 7. Compared to LOT=true, activation is cleaner and 

[bitcoin-dev] Bitcoin Knots 0.21.0.knots20210130 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 0.21.0.knots20210130 is now available from:

  https://bitcoinknots.org/files/0.21.x/0.21.0.knots20210130/

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v0.21.0.knots20210130/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Wallet Interface

[Luke Dashjr via bitcoin-dev]

1) People should not be encouraged to write or use web browsers for their 
wallet.
2) You may want to look over earlier work in this area.

On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote:
> Hi
>
> This is a first draft of a BIP we intend to submit. The main intention is
> to define a simple interface that wallets and applications can agree on
> that would cover the vast majority of use cases. This can enable writing
> bitcoin applications (e.g. time lock, multi sig) on the web that can be
> seamlessly used with any compatible wallets. We have implementations of
> such examples but I don't want to turn this thread into a promotion and
> rather focus on the spec.
>
> Appreciate input from the list. Please share if there are existing efforts,
> relevant specs or use cases.
>
> --
>
> A wallet interface specification for bitcoin applications
>
> ## Abstract
>
> This BIP describes an API for Bitcoin wallets and applications as a
> standard.
>
> ## Summary
>
> Bitcoin wallets should expose their address derivation and signing
> functions to external applications. The interface would be expressed as
> follows in javascript:
>
> ```
> {
> // Wallet Metadata
> wallet: {
> name: 'Bitcoin Core'
> },
>
> // Request access to the wallet for the current host
> async enable: (),
>
> // Request addresses and signatures from wallet
> async request ({ method, params })
> }
> ```
>
> In the web context the interface could be exposed at the top level of a
> webpage, for example under `window.bitcoin`. However this spec does not
> intend to define any standards for how and where the interfaces should be
> exposed.
>
> ## Motivation
>
> Due to the seldom available APIs exposed by wallets, applications (web or
> otherwise) are limited in how they are able to interact. Generally only
> simple sends have been available. A more robust API that introduces other
> requests will promote richer Bitcoin applications.
>
> Additionally, wallet APIs have frequently included inconsistencies in their
> interfaces and behaviour. This has required applications to build and
> maintain a separate client for each wallet, increasing the risk of bugs and
> unintended behaviour as well as being a limiting factor for the adoption of
> usable bitcoin applications.
>
> With a standardised wallet API:
>
> - Wallets have a clear API to implement
> - Applications have a clear expectation of wallet interface and behaviour
> - Applications become agnostic to the wallet specifics, increasing choice
> for users
>
> If more wallets implement the specification, applications will be developed
> more confidently by benefiting from the wallet interoperability. This
> creates a positive feedback loop.
>
> ## Specification
>
> For simplicity, the interface is defined in the context of web applications
> running in the browser (JS) however, they are simple enough to be easily
> implemented in other contexts.
>
> ### General Rules
>
> - For sensitive functions (e.g. signing), wallet software should always
> prompt the user for confirmation
>
> ### Types
>
> **UserDeniedError**
> An error type indicating that the application's request has been denied by
> the user
> Type: Error
>
> **Hex**
> Type: String
> Example:
> `"000a24677957d1e50d70e67c513d220dbe8868c4c3aefc08"`
>
> **Address**
> Address details
> Type: Object
> Example:
>
> ```
> {
> "address": "bc1qn0fqlzamcfuahq6xuujrq08ex7e26agt20gexs",
> "publicKey":
> "02ad58c0dced71a236f4073c3b6f0ee27dde6fe96978e9a9c9500172e3f1886e5a",
> "derivationPath": "84'/1'/0'/0/0"
> }
> ```
>
> ### API
>
> The wallet must implement the following methods.
>
> **enable**
>
> The enable call prompts the user for access to the wallet.
>
> If successful, it resolves to an address (`**Address**` type) of the
> wallet. Typically the first external address to be used as an identity.
>
> **`UserDeniedError`** will be thrown if the request is rejected.
>
> **request**
>
> The request method must take one parameter in the following format:
>
> ```
> {
> "method": "wallet_methodName",
> "params": ["foo", "bar", "baz"]
> }
> ```
>
> For a list of mandatory methods see Table
>
> The wallet should reject request calls unless `enable` has been resolved.
>
> Sensitive requests that involve signing should always prompt the user for
> confirmation
>
> On success the request should resolve to the response as defined in the
> method table.
>
> **`UserDeniedError`** will be thrown if the request is rejected.
>
> **Mandatory methods**
>
> method: `wallet_getAddresses` params: [`index = 0, numAddresses = 1, change
> = false`]
> return: `[ Address ]`
> error: UserDeniedError
>
> method: `wallet_signMessage` params: `[ message, address ]`
> return: Signature `Hex`
> error: UserDeniedError
>
> method: `wallet_signPSBT` params: `[ [psbtBase64, inputIndex, address] ]`
> return: `psbtBase64`
> error: UserDeniedError
>
> method: `wallet_getConnectedNetwork` params: `[]`
> return: Network object 

Re: [bitcoin-dev] bip48 proposal

[Luke Dashjr via bitcoin-dev]

Thanks for explaining where instructions are lacking.

How does this look?
https://github.com/bitcoin/bips/pull/1046/files

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bip48 proposal

[Luke Dashjr via bitcoin-dev]

BIP number 48 has not been assigned. Do not self-assign BIP numbers.

Is this intended to be compatible with 
https://github.com/bitcoin/bips/pull/253 ?

Luke



On Wednesday 16 December 2020 14:10:28 dentondevelopment via bitcoin-dev 
wrote:
> Here is the repo instead of a static link:
> https://github.com/Fonta1n3/bips/blob/master/bip-0048.mediawiki
>
> Fontaine
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>
> On Wednesday, December 16, 2020 8:43 PM, dentondevelopment via bitcoin-dev 
 wrote:
> > Hello,
> >
> > I would like to propose bip48 (taking bip44 as inspiration), with the
> > purpose of documenting modern multi-sig derivations.
> >
> > Please see a rough draft of the proposed bip attached, comments/input
> > welcome.
> >
> > Regards,
> > Fontaine

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP - Automated and Secure Communication

[Luke Dashjr via bitcoin-dev]

Anything that makes sense to coordinate between different programs is BIP 
material, not just core Bitcoin protocol...


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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Knots 0.20.1.knots20200815 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 0.20.1.knots20200815 is now available from:

  https://bitcoinknots.org/files/0.20.x/0.20.1.knots20200815/

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v0.20.1.knots20200815/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Knots 0.20.0.knots20200614 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 0.20.0.knots20200614 is now available from:

  https://bitcoinknots.org/files/0.20.x/0.20.0.knots20200614/

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v0.20.0.knots20200614/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Knots 0.19.1.knots20200304 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 0.19.1.knots20200304 is now available from:

  https://bitcoinknots.org/files/0.19.x/0.19.1.knots20200304/

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:
  
https://github.com/bitcoinknots/bitcoin/blob/v0.19.1.knots20200304/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion

[Luke Dashjr via bitcoin-dev]

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  OP_ELSE  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@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

[bitcoin-dev] Bitcoin Knots 0.19.0.1.knots20200104 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 0.19.0.1.knots20200104 is now available from:

  https://bitcoinknots.org/files/0.19.x/0.19.0.1.knots20200104/

This release includes new features, various bug fixes and performance 
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v0.19.0.1.knots20200104/doc/release-notes.md

New features of particular interest
===

- BIP157 (Neutrino) can be enabled to serve compact block filters to peers.
  This requires both the `-blockfilterindex` and `-peercfilters` options
  enabled, and can also be turned on in the GUI settings under the Network
  tab.

- PSBT support has been experimentally expanded to include the new version and
  proprietary fields, as well as easier usage from the GUI for watch-only
  wallets.

- The Overview tab now has the ability to hide private information. This is
  still an experimental feature, and suggestions for how the new "privacy
  mode" should look can be made on the related Core PR:
https://github.com/bitcoin/bitcoin/pull/16432


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Modern Soft Fork Activation

[Luke Dashjr via bitcoin-dev]

On Saturday 11 January 2020 14:42:07 Anthony Towns wrote:
>  the UASF approach had significant potential technical problems
>        (potential for long reorgs, p2p network splits) that weren't
>        resolved by the time it became active.

Long reorgs, only for old nodes, were a possibility, but not a problem.

The p2p network split issues WERE resolved well before activation.
(In fact, Bitcoin Knots still ships with the general p2p fixes.)

>        neither 
>        BIP-148 or BIP-91 gained enough consensus to be supported in
>        bitcoin core though

There was no measurable difference in community support between BIP148 and 
Segwit itself, months before BIP148's activation. (There was about 20% that 
indicated they would support BIP148 "only if Bitcoin Core releases it", which 
IMO "counts" in this context.)

The only difference was in the opinions of developers. Basing the decision to 
exclude BIP148 as even an *option* on this basis was IMO improper and 
shouldn't be repeated. The community's readiness to switch to another 
fork/build for UASFs is also valuable, but shouldn't be necessary.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Modern Soft Fork Activation

[Luke Dashjr via bitcoin-dev]

I think BIP 9 is a proven failure, and flag day softforks have their own 
problems:

A) There is no way to unambiguously say "the rules for this chain are 
". It leaves the chain in a kind of "quantum state" where the rules 
could be one thing, or could be another. Until the new rules are violated, we 
do not know if the softfork was a success or not. Because of this, people 
will rightly shy away from relying on the new rules. This problem is made 
worse by the fact that common node policies might not produce blocks which 
violate the rules. If we had gone with BIP149 for Segwit, it is IMO probable 
we would still not have a clear answer today to "Is Segwit active or not?"

B) Because of (A), there is also no clear way to intentionally reject the 
softfork. Those who do not consent to it are effectively compelled to accept 
it anyway. While it is usually possible to craft an opposing softfork, this 
should IMO be well-defined and simple to do (including a plan to do so in any 
BIP9-alike spec).

For these reasons, in 2017, I proposed revising BIP 8 with a mandatory signal, 
similar to how BIP148 worked: https://github.com/bitcoin/bips/pull/550
However, the author of BIP 8 has since vanished, and because we had no 
immediate softfork plans, efforts to move this forward were abandoned 
temporarily. It seems like a good time to resume this work.

In regard to your goal #3, I would like to note that after the mandatory 
signal period, old miners could resume mining unchanged. This means there is 
a temporary loss of hashrate to the network, but I think it is overall better 
than the alternatives. The temporary loss of income from invalid blocks will 
also give affected miners a last push to upgrade, hopefully improving the 
long run security of the network hashrate.

Luke

(P.S. As for your #1, I do think it is oversimplified in some cases, but we 
should leave that for later discussion when it actually becomes relevant.)



On Friday 10 January 2020 21:30:09 Matt Corallo via bitcoin-dev wrote:
> There are a series of soft-fork designs which have recently been making
> good progress towards implementation and future adoption. However, for
> various reasons, activation methods therefor have gotten limited
> discussion. I'd like to reopen that discussion here.
>
> It is likely worth revisiting the goals both for soft forks and their
> activation methods to start. I'm probably missing some, but some basic
> requirements:
>
> 1) Avoid activating in the face of significant, reasonable, and directed
> objection. Period. If someone has a well-accepted, reasonable use of
> Bitcoin that is working today, have no reason to believe wouldn't work
> long into the future without a change, and which would be made
> impossible or significantly more difficult by a change, that change must
> not happen. I certainly hope there is no objection on this point (see
> the last point for an important caveat that I'm sure everyone will jump
> to point out).
>
> 2) Avoid activating within a timeframe which does not make high
> node-level-adoption likely. As with all "node" arguments, I'll note that
> I mean "economically-used" nodes, not the thousand or so spy nodes on
> Google Cloud and AWS. Rule changes don't make sense without nodes
> enforcing them, whether they happen to be a soft fork, hard fork, or a
> blue fork, so activating in a reduced timeframe that doesn't allow for
> large-scale node adoption doesn't have any value, and may cause other
> unintended side effects.
>
> 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of
> Bitcoin's security comes from miners, reducing the hashpower of the
> network as a side effect of a rule change is a needless reduction in a
> key security parameter of the network. This is why, in recent history,
> soft forks required 95% of hashpower to indicate that they have upgraded
> and are capable of enforcing the new rules. Further, this is why recent
> soft forks have not included changes which would result in a standard
> Bitcoin Core instance mining invalid-by-new-rules changes (by relying on
> the standardness behavior of Bitcoin Core).
>
> 4) Use hashpower enforcement to de-risk the upgrade process, wherever
> possible. As a corollary of the above, one of the primary reasons we use
> soft forks is that hashpower-based enforcement of rules is an elegant
> way to prevent network splits during the node upgrade process. While it
> does not make sense to invest material value in systems protected by new
> rules until a significant majority of "economic nodes" is enforcing said
> rules, hashpower lets us neatly bridge the gap in time between
> activation and then. By having a supermajority of miners enforce the new
> rules, attempts at violating the new rules does not result in a
> significant network split, disrupting existing users of the system. If
> we aren't going to take advantage of this, we should do a hard fork
> instead, with the necessarily slow timescale that 

[bitcoin-dev] CVE-2018-20586 disclosure (log injection vulnerability)

[Luke Dashjr via bitcoin-dev]

CVE-2018-20586 is a log injection vulnerability which allows any software with 
access to the RPC port to create fake or confusing entries in the debug log. 
Valid authentication (username/password/cookie) for the RPC service is NOT 
required to exploit this vulnerability, only the ability to connect to the 
RPC port (which is by default only exposed to the local machine).

The vulnerability was introduced in 40b556d3742a1f65d67e2d4c760d0b13fe8be5b7 
("libevent-based http server") and first released in Bitcoin Core v0.12.0rc1 
in 2016 Jan 13. A fix was hidden in 79358817e53ac0a7afa64c747115d492a74e3155 
("rpc: Make HTTP RPC debug logging more informative") released in v0.17.1, 
2018 Dec 22.

To be vulnerable, the malicious software must either be running on the same 
machine as the node, have the ability to proxy connections to the node via 
the local machine, or the node must be configured to accept RPC connections 
from a network via which the attacker can connect. Additionally, a human user 
must read the debug log and act on or otherwise believe the injected data, in 
a way that is somehow harmful.

Because the node would log the arbitrary POST request from any connection, an 
attacker can add nearly any content to the request to inject it into the log. 
To ensure their entire request is injected, standard spaces would need to be 
replaced with alternative whitespace characters, and newlines would need to 
become other control characters (such as "\r\v"). Because the injected data 
must use such non-standard characters, it is most likely to not fool other 
software parsing the debug log, and only a human visually reading it.

To fix this vulnerability, POST requests are now sanitised before being 
logged, removing all characters that shouldn't be in an ordinary POST 
request.

Credit goes to practicalswift (https://twitter.com/practicalswift) for 
discovering and fixing the vulnerability.

Timeline:
- 2015-01-18: Vulnerability introduced in PR #5677.
- 2015-09-04: Vulnerability merged to master git repository.
- 2016-01-13: Vulnerability published in v0.12.0rc1.
- 2016-02-18: Vulnerability released in v0.12.0.
...
- 2018-10-25: practicalswift discloses vulnerability to security team.
- 2018-10-31: practicalswift opens PR #14618 to quietly fix vulnerability.
- 2018-11-05: Fix merged to master git repository.
- 2018-11-30: Fix merged to 0.17 git repository.
- 2018-12-07: Fix published in v0.17.1rc1.
- 2018-12-22: Fix released in v0.17.1.
...
- 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019-11-22: Vulnerability details disclosure to bitcoin-dev ML.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution

[Luke Dashjr via bitcoin-dev]

On Monday 11 November 2019 17:10:16 Hampus Sjöberg wrote:
> > It ISN'T low right now...
>
> I agree, but I don't think it's a good idea to softfork it to lower than 4M
> WU though, and I don't think we need to;
> hopefully when exchanges start using Lightning or Liquid, avg blocksize
> will go down.

Not likely, so long as spam continues to pad blocks full.

> > Extension blocks are not softforks, and are unreasonably convoluted for
> no
> real gain. When the time comes, the block size should be increased only
> using
> a hardfork.
>
> It depends on how you define soft and hardforks, I suspect you don't see
> extension blocks as a softforks because old nodes won't maintain a correct
> UTXO set.
> I think an extension block is a softfork because old nodes will still be
> able to follow the mainchain.

Softforks leave old nodes *working*, so yes, maintaining the correct UTXO 
state.

Simply "following" is meaningless, as even soft-hardforks are "followed".

> I don't know if a blocksize increase hardfork will get consensus as the
> idea has been ruined by all malicious hijack attempts we've seen over the
> years.

If there isn't consensus, then it shouldn't be done, period.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution

[Luke Dashjr via bitcoin-dev]

On Monday 11 November 2019 16:08:43 Hampus Sjöberg via bitcoin-dev wrote:
> I am advocating to keep the blocksize low right now, 

It ISN'T low right now...

> but I don't leave out 
> in increasing it in the future when we have a need for it, preferably via
> an extension block (softfork).

Extension blocks are not softforks, and are unreasonably convoluted for no 
real gain. When the time comes, the block size should be increased only using 
a hardfork.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] CVE-2017-18350 disclosure

[Luke Dashjr via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'

[Luke Dashjr via bitcoin-dev]

On Saturday 05 October 2019 21:57:48 Emil Engler via bitcoin-dev wrote:
> Hello dear mailing list subscribers.
> Before I'll explain my idea here, I need to define a term first
>
> 'address':
> When I use the terms address, pubkey, etc., I mean the same: The Base58
> string

But a pubkey is not a Base58 string, and fundamentally different from an 
address. An address identifies the recipient and the purpose of the payment; 
a pubkey does not. The pubkey remains with the UTXO; an address does not.

> Ok now let's get into it:
> As you should know, sending bitcoins to an address more than once is a
> very bad approach.
> In my opinion the problem why so many people are still doing this is
> because of the term 'address' which is used in lots of wallets,
> implementations, BIP 21 and so on. It is a design issue.
> With the term 'address' most people identify things that are fixed and
> don't change really often (e.g postal address, IP address [depends on
> provider], Domain, E-Mail address, ...).
> Because of this most people compare bitcoin addresses with e-mail
> addresses and use this address to send the recipient money multiple times.

That problem would require using a different term than "address" to address.
A BIP is unlikely to do the job (though it may help).

> My suggestion would be to change the term address in wallets, the URI
> scheme and so on to something of the following options by a
> Informational/Process BIP:
>
> * Payment Password
> * Transaction Password
> * ...

Neither the address nor pubkey are a password...

Some possible alternative terms would be "invoice id", "payment token", etc.

> The guideline for the term should indicate that it is:
> * temporary
> * Something that identifies the recipient
>
> I've chosen 'password' because they can be used as a pseudonym to
> identify a person.
> This is already used in stuff like bank transfers where something like
> the transaction id should be used as the purpose or at universities
> there are student numbers.
> The first is probably a better example because student numbers aren't
> temporary.
>
> What do you think? Should I write a BIP for this or use another term?
> Feedback is most welcome :)
>
> Greetings,
> Emil Engler

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Luke Dashjr via bitcoin-dev]

On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote:
> 3) Afaik, it enforces/encourages address re-use. This stems from the
> fact that the server decides on the filter and in particular on the
> false positive rate. On wallets with many addresses, a hardcoded filter
> will be too blurry and thus each block will be matched. So wallets that
> follow the "one address per incoming payment" pattern (e.g. HD wallets)
> at some point will be forced to wrap their key chains back to the
> beginning. If I'm wrong on this one please let me know.

BTW, you are indeed wrong on this. You don't need to match every single 
address the wallet has ever used, only outstanding addresses that haven't 
been paid. ;)

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Absent authors and BIP updates

[Luke Dashjr via bitcoin-dev]

On Tuesday 23 July 2019 15:09:02 Karl-Johan Alm via bitcoin-dev wrote:
> People come in as Bitcoin developers all the time, but sometimes
> people also leave permanently. In the case of BIP authors, when a user
> leaves and does not respond to (reasonable) requests to change their
> BIPs, we are sort of stuck right now.

BIP 2 allows assigning a new champion.

https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Transferring_BIP_Ownership
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Luke Dashjr via bitcoin-dev]

On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote:
> > the DNS seed infrastructure among others can easily direct
> > wallets to those nodes
>
> Last I checked none of the seeds did. But I agree this would be nice to
> have.

It's supported by default in sipa's bitcoin-seeder, which many DNS seeds use.

My seed also currently requires NODE_BLOOM for *any* answers returned.
(But I don't guarantee that will remain forever.)

> As a side note, Coinbase just announced their 30M'th wallet. I'm
> convinced this massive run into custodial wallets...

Light wallets are just as bad for the network as custodial wallets.

> IMHO, BIP 37 is the only scaling technology that has proven successful and
> could – if supported and improved rather than choked – continue to help
> holding against the bitbanks trend.

Light wallets are not Bitcoin scaling. They are just trusting anonymous 3rd 
parties, which is harmful to Bitcoin.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Luke Dashjr via bitcoin-dev]

On Monday 22 July 2019 18:52:10 Peter via bitcoin-dev wrote:
> Privacy is a matter of individual choice in the current protocol. Why not
> let people provide this network service? I don't see why it should be
> end-of-life if it provides value.

It's not EOL, just disabled by default. Anyone can provide it by choice.
Same as with Stratum/Electrum right now (except easier to enable).

> I believe there's a network security obtained by having a large quantity of
> people following the Bitcoin headers based on longest weighted chain. As a
> means of nullifying potential miner initiated hard forks (like S2X).

This is incorrect. Such wallets strictly degrade security, as they are blindly 
trusting miners. They make the network more VULNERABLE to 2X-like attacks.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Luke Dashjr via bitcoin-dev]

On Sunday 21 July 2019 22:56:33 Andreas Schildbach via bitcoin-dev wrote:
> An estimated 10+ million wallets depend on that NODE_BLOOM to be
> updated.

Where do you see this number? I think it would be useful to chart.

> So far, I haven't heard of an alternative, except reading all 
> transactions and full blocks.

Electrum has a JSON-based protocol that can provide information much more 
efficiently.

Currently, this does require nodes that run additional software and/or 
indexes, but there are plenty of them available, and there are steps that can 
be taken to improve that situation.

> > It is not anticipated that
> > this will result in a significant lack of availability of
> > NODE_BLOOM-enabled nodes in the coming years
>
> Why don't you anticipate that? People almost never change defaults,
> especially if it's not for their own immediate benefit. At the same
> time, release notes in general recommend updating to the latest version.
> I *do* anticipate this will reduce the number of nodes usable by a large
> enough amount so that the feature will become unstable.

Many users run older versions, and do not update immediately. Today, only 42% 
of listening nodes are using 0.18.

(If it helps ease the concern, we can keep bloom enabled by default in Knots 
longer.)

> I strongly recommend postponing this change until an alternative exists
> and then give developers enough time to implement, test and roll out.

There will be time to do so, since the functionality won't disappear 
overnight.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Luke Dashjr via bitcoin-dev]

On Monday 22 July 2019 13:25:25 Jonas Schnelli via bitcoin-dev wrote:
> > I also think as long as we don't have an alternative, we should improve
> > the current filtering for segwit. E.g. testing the scripts themselves
> > and each scriptPubKey spent by any input against the filter would do,
> > and it also fixes the main privacy issue with server-side filtering
> > (wallets have to add two items per address to the filter).
>
> I think the consensus among protocol developers is (please speak up), that
> BIP37 (public server based tx filtering) – in general – was a conceptual
> mistake. Maybe extending it further is the wrong step, especially when
> promising alternatives like BIP158 (neutrino) are around.

Neutrino is very controversial, and NOT less trustful than bloom filters.
It also uses significantly more bandwidth.

It seems a better approach is to add Stratum (Electrum) support, and to limit 
usage of all pseudo-SPV protocols to trusted peers.

> The fact that nobody cared about extending it for SW may also underline that
> BIP37 is seen as a conceptual mistake and/or "low interest in further
> extensions“. 

Eric Lombrozo added segwit support. While it was never reviewed for Core, it 
has been included and supported in Knots since v0.15.1. As I understand it, 
his mSIGNA wallet also makes usage of the feature.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] PSA: Upcoming disclosure of pre-v0.17.1 vulnerabilities

[Luke Dashjr via bitcoin-dev]

Two relatively minor vulnerabilities will likely be disclosed sometime soon.

The first vulnerability, CVE-2017-18350, was introduced in v0.7.0 (released in 
2012 September), and affects all versions released until the fix was included 
in v0.15.1 (released in 2017 November). No versions prior to v0.15.1 are 
expected to be fixed.

The second vulnerability, CVE-2018-20586, was introduced in v0.12.0 (released 
in 2016 February), and affects all versions released until the fix was 
included in v0.17.1 (released in 2018 December). As of today, this fix has 
NOT been backported to older versions. When/if v0.15.3 and v0.16.4 are 
released, they may also include a fix, but due to the minor severity of this 
vulnerability, it does not merit a dedicated release on its own. (The git 
branches are also NOT fixed at this time.)

Please be sure you have upgraded to a fixed version no later than August 1st.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

[Luke Dashjr via bitcoin-dev]

On Monday 06 May 2019 20:17:09 Luke Dashjr via bitcoin-dev wrote:
> Some way to sign an additional script (not committed to by the witness
> program) seems like it could be a trivial addition.

This would be especially useful for things like OP_CHECKBLOCKATHEIGHT:

https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

[Luke Dashjr via bitcoin-dev]

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,

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Knots 0.18.0.knots20190502 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version *0.18.0.knots20190502* is now available from:

  

This is a new major version release, including new features, various bug
fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has
completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
`/Applications/Bitcoin-Qt` (on Mac) or `bitcoind`/`bitcoin-qt` (on
Linux).

The first time you run version 0.15.0 or newer, your chainstate database
will be converted to a new format, which will take anywhere from a few
minutes to half an hour, depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and
there is no automatic upgrade code from before version 0.8 to version
0.15.0 or later. Upgrading directly from 0.7.x and earlier without
redownloading the blockchain is not supported.  However, as usual, old
wallet versions are still supported.

Compatibility
==

Bitcoin Knots is supported on operating systems using the Linux kernel,
macOS 10.10+, and Windows 7 and newer. It is not recommended to use
Bitcoin Knots on unsupported systems.

From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
built using Qt 5.9.x, which doesn't support versions of macOS older than
10.10. Additionally, Bitcoin Knots does not yet change appearance when
macOS "dark mode" is activated.

In addition to previously-supported CPU platforms, this release's
pre-compiled distribution also provides binaries for the RISC-V
platform.

If you are using the `systemd` unit configuration file located at
`contrib/init/bitcoind.service`, it has been changed to use
`/var/lib/bitcoind` as the data directory instead of
`~bitcoin/.bitcoin`. When switching over to the new configuration file,
please make sure that the filesystem on which `/var/lib/bitcoind` will
exist has enough space (check using `df -h /var/lib/bitcoind`), and
optionally copy over your existing data directory. See the [systemd init
file section](#systemd-init-file) for more details.

Known issues


Wallet GUI
--

For advanced users who have both (1) enabled coin control features, and
(2) are using multiple wallets loaded at the same time: The coin control
input selection dialog can erroneously retain wrong-wallet state when
switching wallets using the dropdown menu. For now, it is recommended
not to use coin control features with multiple wallets loaded.

Notable changes
===

Policy
--

- Previously, transactions sending to future Bech32 address versions
  would be rejected, which could lead to stuck transactions, locking
  up change. This has been relaxed by default to mitigate the issue.
  For 0.18.0, the `-sendtofuture=0` option (also available in the
  GUI Mempool Settings tab) can restore the old policy, but this is
  discouraged, and will be removed in the future.

Mining
--

- Calls to `getblocktemplate` will fail if the segwit rule is not
  specified.  Calling `getblocktemplate` without segwit specified is
  almost certainly a misconfiguration since doing so results in lower
  rewards for the miner.  Failed calls will produce an error message
  describing how to enable the segwit rule.

- By default, blocks mined with Bitcoin Knots will be limited to 300k
  in size, or 1.5 MWU in weight. Note these defaults are just healthy
  recommendations, and can be overridden with the `-blockmaxsize` and
  `-blockmaxweight` options.

Configuration option changes


- A warning is printed if an unrecognized section name is used in the
  configuration file.  Recognized sections are `[test]`, `[main]`, and
  `[regtest]`.

- The `rpcallowip` option can no longer be used to automatically listen
  on all network interfaces.  Instead, the `rpcbind` parameter must be
  used to specify the IP addresses to listen on.  Listening for RPC
  commands over a public network connection is insecure and should be
  disabled, so a warning is now printed if a user selects such a
  configuration.  If you need to expose RPC in order to use a tool like
  Docker, ensure you only bind RPC to your localhost, e.g. `docker run
  [...] -p 127.0.0.1:8332:8332` (this is an extra `:8332` over the
  normal Docker port specification).

- The `rpcpassword` option now causes a startup error if the password
  set in the configuration file contains a hash character (#), as it's
  ambiguous whether the hash character is meant for the password or as a
  comment.

- The `whitelistforcerelay` option is used to relay transactions from
  whitelisted peers even when not accepted to the mempool. This option
  now defaults to being off, so that changes in policy and
  disconnect/ban 

Re: [bitcoin-dev] IsStandard

[Luke Dashjr via bitcoin-dev]

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  OP_3 OP_CHECKMULTISIG
>    
> scriptPubKey:
>     OP_HASH160 hash160( 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

[Luke Dashjr via bitcoin-dev]

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 

[bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC

[Luke Dashjr via bitcoin-dev]

Certain parts of the community have been selling bitcoins for unreasonably
low prices. This has halted Bitcoin's valuation at $20k and even driven the
price down below $15k! However, clearly Bitcoin is worth much more than
that, and there is widespread support for higher prices.

In light of this, I have written and implemented two BIPs: one to add a
signed price field to Bitcoin transactions, and the other to softfork a
minimum price of $50k USD/BTC a year from today.

The BIPs are here, as well as included at the bottom of this email for 
convenience:
  https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki

A reference implementation is here:
  https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k

Please review ASAP so we can get these deployed in Bitcoin Core v0.18.

Luke



  BIP: ?
  Layer: Applications
  Title: Signed USD Price Indicator
  Author: Luke Dashjr 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
  Status: Draft
  Type: Standards Track
  Created: 2019-04-01
  License: BSD-2-Clause


==Abstract==

This BIP proposes a method to explicitly specify and sign the USD/BTC price 
for transactions.

==Copyright==

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

==Motivation==

Certain parts of the community have been selling bitcoins for unreasonably low 
prices. This has halted Bitcoin's valuation at $20k and even driven the price 
down below $15k! However, clearly Bitcoin is worth much more than that, and 
there is widespread support for higher prices.

This problem can be fixed by setting a global minimum price for bitcoins. 
Unfortunately, today, the consensus protocol is completely oblivious to the 
price bitcoins are traded at. Therefore, we must first add a field to Bitcoin 
transactions to indicate their price.

==Specification==

===New field and legal implication===

A new field is added to Bitcoin transactions. This field, if present, must 
represent the honest and true USD/BTC rate used for the transaction. By 
signing the transaction, the sender legally affirms this is the valuation of 
bitcoins used for the transaction.

For the avoidance of doubt: when the transaction is valued in a currency other 
than USD, any reasonable exchange rate may be used to come up with the USD 
valuation.

===Serialisation===

When serialising the transaction for any purpose, including signing, weight 
calculation, and so on, the output count must be incremented by one. Prior to 
the first real output, the following bytes must be inserted:

* Constant: 00 00 00 00 00 00 00 00
* A single byte, the size in bytes of the remainder of the inserted data
* Constant: 6a 04 55 53 44 24
* A single byte, the size in bytes of the remainder of the inserted data
* The USD/BTC rate used for the transaction, in standard signed integer 
serialisation, with all leading zeros removed (except as necessary to 
preserve the sign bit).

==Backwards compatibility==

===Consensus===

The new price field is serialised as a dummy output, with a value of zero, and 
a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore 
this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it 
is never considered spendable.

Therefore, current nodes will ignore the new field entirely, and accept 
transactions using it.

===Wallets===

Existing wallets do not typically generate price indicators as specified. 
Under this BIP, this absence of the field is perfectly acceptable.

==Reference implementation==

https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field


  BIP: ?
  Layer: Consensus (soft fork)
  Title: $50k USD/BTC Minimum Price
  Author: Luke Dashjr 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
  Status: Draft
  Type: Standards Track
  Created: 2019-04-01
  License: BSD-2-Clause
  Requires: usdprice


==Abstract==

This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.

==Copyright==

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

==Motivation==

Certain parts of the community have been selling bitcoins for unreasonably low 
prices. This has halted Bitcoin's valuation at $20k and even driven the price 
down below $15k! However, clearly Bitcoin is worth much more than that, and 
there is widespread support for higher prices.

bip-usdprice defines a new field to indicate the price of transactions. Using 
this, we can softfork to require a minimum transaction price.

==Specification==

Beginning with block height 622370 (expected approximately 2020 April 1), a 
block is reject as invalid unless all transactions it contains both declare a 
USD/BTC price (as defined in bip-usdprice) and specify a price that is at a 
minimum $50k USD/BTC.

==Backwards compatibility==

As a soft fork, older nodes will continue 

Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup

[Luke Dashjr via bitcoin-dev]

On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote:
> I'd like to ask the BIP editor to assign a BIP number.

Needs a Backward Compatibility section, and should have a bips repo PR opened 
after discussion on the ML.

>   * The 4th change (making non-standard signature hash types invalid)
> may be worth discussing. In order to limit the number of potential
> signature hashes which could be used per-input (allowing us to cache
> them to avoid re-calculation), we can disable non-standard sighash
> types. Alternatively, however, most of the same effect could be achieved
> by caching the just-before-the-last-byte sighash midstate and hashing
> only the last byte when a checking signatures. Still, them having been
> non-standard for many years makes me doubt there is much risk involved
> in disabling them, and I don't see much potential use-case for keeping
> them around so I'd like to just remove them.

I don't understand what is being removed here.

> As for why the timewarp vulnerability should (IMO rather obviously) be
> fixed, it seems rather clear that the only potential use for exploiting
> it would be either to inflate the currency supply maliciously by miners
> or to fork in what amounts to extension blocks. As for why extension
> blocks are almost certainly not the right approach to such changes, its
> likely worth reading this old post:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510
>.html

While I agree that extension blocks are typically a bad choice, I'm not sure 
the argument really applies to forward blocks. (That being said, I find 
forward blocks overcomplicated and probably not a reason to avoid this.)

> * Transactions smaller than 65 bytes when serialized without witness
> data are invalid.

Rationale should include the reason(s) why the size doesn't count the witness 
here.

> ** Note that miners today only enforce increasing timestamps against the
> median-timestamp-of-last-11-blocks, so miners who do not upgrade may
> mine a block which violates this rule at the beginning of a difficulty
> window if the last block in a difficulty window has a timestamp in the
> future. Thus, it is strongly recommended that SPV clients enforce the
> new nTime rules to avoid following any potential forks which occur.

This should probably be moved outside Discussion. (Perhaps to the missing 
Backward Compatibility section?)

> * There are several early-stage proposals which may affect the execution
> of scripts, including proposals such as Schnorr signatures, Taproot,
> Graftroot, and MAST. These proposals are not expected to have any
> interaction with the changes in this BIP, as they are likely to only
> apply to SegWit scripts, which are not covered by any of the new rules
> except for the sighash type byte rule. Thus, the sighash type byte rule
> defined above only applies to *current* signature-checking opcodes, as
> any new signature-checking is likely to be implemented via the
> introduction of new opcodes.

It's not clear that new opcodes will necessarily always be used. Probably 
would be good to clarify the "non-Segwit or witness v0 only" rule in the 
Specification section.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Luke Dashjr via bitcoin-dev]

Even besides NOINPUT, such a wallet would simply never show a second payment 
to the same address (or at least never show it as confirmed, until 
successfully spent).

At least if tx versions are used, it isn't possible to indicate this 
requirement in current Bitcoin L1 addresses. scriptPubKey might not be 
impossible to encode, but it isn't really clear what the purpose of doing so 
is.

If people don't want to use NOINPUT, they should just not use it. Trying to 
implement a nanny in the protocol is inappropriate and limits what developers 
can do who actually want the features.

Luke


On Tuesday 19 February 2019 19:22:07 Johnson Lau wrote:
> This only depends on the contract between the payer and payee. If the
> contract says address reuse is unacceptable, it’s unacceptable. It has
> nothing to do with how the payee spends the coin. We can’t ban address
> reuse at protocol level (unless we never prune the chain), so address reuse
> could only be prevented at social level.
>
> Using NOINPUT is also a very weak excuse: NOINPUT always commit to the
> value. If the payer reused an address but for different amount, the payee
> can’t claim the coin is lost due to previous NOINPUT use. A much stronger
> way is to publish the key after a coin is well confirmed.
>
> > On 20 Feb 2019, at 3:04 AM, Luke Dashjr  wrote:
> >
> > On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> >> While this seems fully compatible with eltoo, is there any other
> >> proposals require NOINPUT, and is adversely affected by either way of
> >> tagging?
> >
> > Yes, this seems to break the situation where a wallet wants to use
> > NOINPUT for everything, including normal L1 payments. For example, in the
> > scenario where address reuse will be rejected/ignored by the recipient
> > unconditionally, and the payee is considered to have burned their
> > bitcoins by attempting it.
> >
> > Luke

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Luke Dashjr via bitcoin-dev]

On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> While this seems fully compatible with eltoo, is there any other proposals
> require NOINPUT, and is adversely affected by either way of tagging?

Yes, this seems to break the situation where a wallet wants to use NOINPUT for 
everything, including normal L1 payments. For example, in the scenario where 
address reuse will be rejected/ignored by the recipient unconditionally, and 
the payee is considered to have burned their bitcoins by attempting it.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves Transactions

[Luke Dashjr via bitcoin-dev]

On Tuesday 29 January 2019 22:03:04 Steven Roose via bitcoin-dev wrote:
> The existence of the first input (which is just a commitment hash) ensures
> that this transaction is invalid and can never be confirmed.

But nodes can never prove the transaction is invalid, thus if sent it, they 
will likely cache the "transaction", taking up memory. I'm not sure if this 
is an actual problem, as an attacker can fabricate such transactions anyway.

> #:Not all systems that will be used for verification have access to a full
> index of all transactions.  However, proofs should be easily verifiable
> even after some of the UTXOs used in the proof are no longer unspent.
> Metadata present in the proof allows for relatively efficient verification
> of proofs even if no transaction index is available.

I don't see anything in the format that would prove unspentness...

> The proposed proof-file format provides a standard way of combining
> multiple proofs and associated metadata.  The specification of the format
> is in the Protocol
> Buffershttps://github.com/protocolbuffers/protobuf/ format.

IIRC, this has been contentious for its use in BIP70 and may hinder adoption.

> message OutputMeta {
> // Identify the outpoint.
> bytes txid = 1;
> uint32 vout = 2;
>
> // The block hash of the block where this output was created.
> bytes block_hash = 3;

This isn't really sufficient. There should probably be a merkle proof.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Luke Dashjr via bitcoin-dev]

On Thursday 16 August 2018 02:22:21 Lautaro Dragan wrote:
> > Choosing not to mine transactions is not censorship.
>
> Is it not, if for political rather than economical reasons? These
> transactions pay fees like any other.

Miners have always chosen transaction on "political" basises, and doing such 
is their right. That's why the system is supposed to be comprised of many 
miners, all with their own policies - so the choices of one do not impact the 
overall ability to spend (presumably only spam should be rejected by all 
miners).

For fees to themselves justify the cost of a transaction, they would need to 
be magnitudes higher than we've ever seen on Bitcoin. But even then, nobody 
has an obligation to accept payment, no matter how reasonable it is, for a 
service they don't want to provide.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Luke Dashjr via bitcoin-dev]

On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev wrote:
> On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Can a miner identify which transactions came from your software simply by
> > running a copy themselves?  If so, then they can censor your transactions
> > no matter how you encode them.
>
> Possibly, but in the IPFS case I suspect the latency required to inspect
> all hashes would likely  impact the ability of the miner to succeed in the
> block. (True? I don’t touch mining software.)

Not true at all.

> Thus as long as all hashes look the same, and there are multiple content
> addressable schemes that use hashes that have to be searched in order to
> know to censor, you have to censor all or none.

Choosing not to mine transactions is not censorship.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Luke Dashjr via bitcoin-dev]

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
> . At Po.et we use
> colored coins
> 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
>  that
> *protocols wishing to claim OP_RETURN prefixes should use the standard
> Bitcoin Improvement Proposals process*.
>
> That entry seems to have changed recently
> , 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Luke Dashjr via bitcoin-dev]

On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional applications where a third party might pay to
> an address a second time, and should only be used in special protocols
> which make that kind of mistake unlikely. 

I don't agree. Address reuse is undefined behaviour. Nobody should assume it 
is safe or works.

I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in 
a wallet I am writing, which explicitly does not support address reuse.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_TRUE standard?

[Luke Dashjr via bitcoin-dev]

You'd send 0 satoshis to OP_TRUE, creating a UTXO. Then you spend that 0-value 
UTXO in another transaction with a normal fee. The idea is that to get the 
latter fee, the miner needs to confirm the original tranaction with the 
0-value OP_TRUE.

(Aside, in case it wasn't clear on my previous email, the template-script idea 
would not make it *mandatory* to spend in the same block, but that the UTXO 
would merely cease to be valid *after* that block. So the 0-value output does 
not take up a UTXO db entry when left unused.)

On Thursday 10 May 2018 09:33:29 Jorge Timón via bitcoin-dev wrote:
> I fail to see what's the practical difference between sending to op_true
> and giving the coins are fees directly. Perhaps it is ao obvious to you
> that you forget to mention it?
> If you did I honestlt missed it.
>
> On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
>
> bitcoin-dev@lists.linuxfoundation.org> 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@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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Luke Dashjr via bitcoin-dev]

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 0181 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 0181, 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@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

Re: [bitcoin-dev] BloomFilter issue with segwit addresses

[Luke Dashjr via bitcoin-dev]

As I understand it, the plan is to deprecated and remove BIP37 entirely once 
BIP158 is implemented and deployed.

In the meantime, Bitcoin Knots supports the MSG_FILTERED_WITNESS_BLOCK 
extension to download witness data. (Note that light clients currently have no 
way to verify the witness data is correct.)

As far as matching goes, why not look for the specific COutPoints? That should 
work already with standard BIP37.

Luke


On Friday 13 April 2018 3:32:15 PM Andreas Schildbach via bitcoin-dev wrote:
> Anton, a developer on the bitcoinj maiing list, recently made me aware
> [1] of a compatibility issue between segwit and BIP37 (Bloom Filtering).
> 
> The issue affects only P2WPKH and the special case of transactions
> without change outputs (such as when emptying a wallet). In this case,
> neither inputs not outputs contain any data elements that would cause a
> match for the filter. The public key, which would match, goes to the
> witness but not to the input.
> 
> My suggestion was to include an OP_RETURN output with a matching public
> key in such transactions. Anton confirmed that this workaround is indeed
> working. But of course it nullifies some of the segwit's size improvements.
> 
> I wonder if Bitcoin Core would be willing to extend the BIP37 matching
> rules such that data elements in the witness are also matched against?
> 
> 
> [1] https://groups.google.com/d/msg/bitcoinj/SJpLgjowc1I/V7u2BavvAwAJ
> 
> ___
> 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

Re: [bitcoin-dev] {sign|verify}message replacement

[Luke Dashjr via bitcoin-dev]

On Thursday 15 March 2018 7:36:48 AM Karl Johan Alm wrote:
> On Wed, Mar 14, 2018 at 12:36 PM, Luke Dashjr  wrote:
> > Ideally, it should support not only just "proof I receive at this
> > address", but also "proof of funds" (as a separate feature) since this
> > is a popular misuse of the current message signing (which doesn't
> > actually prove funds at all). To do this, it needs to be capable of
> > signing for multiple inputs.
> 
> Re-reading this, I think what you mean is it should be possible to
> create a proof for (a) specific UTXO(s), hence "inputs". That sounds
> pretty useful, yeah!

Not necessarily specific UTXOs (that would contradict fungibility, as well as 
be impossible for hot/cold wallet separation), but just to prove funds are 
available. The current sign message cannot be used to prove present possession 
of funds, only that you receive funds.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] {sign|verify}message replacement

[Luke Dashjr via bitcoin-dev]

I don't see a need for a new RPC interface, just a new signature format.

Ideally, it should support not only just "proof I receive at this address", 
but also "proof of funds" (as a separate feature) since this is a popular 
misuse of the current message signing (which doesn't actually prove funds at 
all). To do this, it needs to be capable of signing for multiple inputs.

Preferably, it should also avoid disclosing the public key for existing or 
future UTXOs. But I don't think it's possible to avoid this without something 
MAST-like first. Perhaps it can be a MAST upgrade later on, but the new 
signature scheme should probably be designed with it in mind.

Luke


On Wednesday 14 March 2018 8:09:20 AM Karl Johan Alm via bitcoin-dev wrote:
> Hello,
> 
> I am considering writing a replacement for the message signing tools
> that are currently broken for all but the legacy 1xx addresses. The
> approach (suggested by Pieter Wuille) is to do a script based
> approach. This does not seem to require a lot of effort for
> implementing in Bitcoin Core*. Below is my proposal for this system:
> 
> A new structure SignatureProof is added, which is a simple scriptSig &
> witnessProgram container that can be serialized. This is passed out
> from/into the signer/verifier.
> 
> RPC commands:
> 
> sign   [=false]
> 
> Generates a signature proof for  using the same method that
> would be used to spend coins sent to .**
> 
> verify[=false]
> 
> Deserializes and executes the proof using a custom signature checker
> whose sighash is derived from . Returns true if the check
> succeeds, and false otherwise. The scriptPubKey is derived directly
> from .**
> 
> Feedback welcome.
> 
> -Kalle.
> 
> (*) Looks like you can simply use VerifyScript with a new signature
> checker class. (h/t Nicolas Dorier)
> (**) If  is true,  is the sighash, otherwise
> sighash=sha256d(message).
> ___
> 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

Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure

[Luke Dashjr via bitcoin-dev]

On Wednesday 07 March 2018 3:43:49 PM Jan Čapek wrote:
> Our reasoning for coming up with a new method for miner configuration
> was stated here: https://github.com/slushpool/stratumprotocol/issues/1

This reasoning is not sound.

> It is primarily the determinism of expecting the response. That is
> the reason why we chose a new method mining.configure instead of an
> existing mining.capabilities that was not being very well documented or
> used.

It was as well documented as the original stratum protocol, and in use since 
2014.

While the response type is admittedly undefined, simply defining that would 
have been a better solution than to reinvent it incompatibly for no reason. 
(Although version rolling does not actually require a response at all.)

> 
> 
> On Wed, 7 Mar 2018 14:43:11 +0000 Luke Dashjr via bitcoin-dev
> 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Why are you posting this obsolete draft? You've already received
> > review in private, and been given useful suggestions. There's even a
> > 
> > shared Google Doc with the current draft:
> > https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9T
> > V9LRqvStak/edit?usp=sharing
> > 
> > Again:
> > 
> > * This is no different from what Timo and Sergio proposed years ago,
> > and as such should be based on their work instead of outright
> > not-invented-here respecification. The current draft integrates their
> > work while not trying to steal credit for it (they are included as
> > primary authors).
> > 
> > * The specification should be complete, including updates for GBT and
> > the Stratum mining protocol. These are included in the current draft.
> > 
> > Additionally, it is not appropriate to begin using a draft BIP on
> > mainnet before any discussion or consensus has been reached. Doing so
> > seems quite malicious, in fact. I hope DragonMint miners can still
> > operate using the *current* Bitcoin protocol.
> > 
> > Luke
> > 
> > On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote:
> > > Hi,
> > > 
> > > The following proposal reduces the number of version-bits that can
> > > be used for parallel soft-fork signalling, reserving 16 bits for
> > > non-specific use. This would reduce the number of parallel
> > > soft-fork activations using versionbits to from 29 to 13 and
> > > prevent node software from emitting false warnings about unknown
> > > signalling bits under the versionbits signalling system (BIP8/9). I
> > > chose the upper bits of the nVersion, because looking at the
> > > versionbits implementation in the most widely deployed node
> > > software, it is easier to implement than say annexing the lower 2
> > > bytes of the field.
> > > 
> > > The scope of the BIP is deliberately limited to reserving bits for
> > > general use without specifying specific uses for each bit, although
> > > there have previously been various discussions of some use-cases of
> > > nVersion bits including version-rolling AsicBoost[1], and nonce
> > > rolling to reduce CPU load on mining controllers because
> > > ntime-rolling can only be done for short periods otherwise it could
> > > have negative side effects distorting time. However, specific use
> > > cases are not important for this BIP.
> > > 
> > > I am reviving discussion on this topic now, specifically, because
> > > the new DragonMint miner uses version-rolling AsicBoost on
> > > mainnet[2]. It is important to bring up so node software can adapt
> > > the versionbits warning system to prevent false positives. This BIP
> > > has the added advantage that when a new use for bits is found,
> > > mining manufacturers can play in the designated area without
> > > causing disruption or inconvenience (as unfortuntely, the use of
> > > version-rolling will cause until BIP8/9 warning systems are
> > > adapted). I appologise for the inconvenience in advance, but this
> > > is the unfortunate result of restraints while negotiating to get
> > > the patent opened[3] and licensed defensively[4] in the first place.
> > > 
> > > I believe there was a similar proposal[5] made some years ago,
> > > before the advent of BIP9. This proposal differs in that it's
> > > primary purpose is to remove bits from the versionbits soft-fork
> > > activation system and earmark 16 bits for general use without
> > > allocating fixed uses for each bit. The BIP cites a couple of
> > > usecases for good measure, but they are just

Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader

[Luke Dashjr via bitcoin-dev]

Why are you posting this obsolete draft? You've already received review in 
private, and been given useful suggestions. There's even a shared Google Doc 
with the current draft:


https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9TV9LRqvStak/edit?usp=sharing

Again:

* This is no different from what Timo and Sergio proposed years ago, and as 
such should be based on their work instead of outright not-invented-here 
respecification. The current draft integrates their work while not trying to 
steal credit for it (they are included as primary authors).

* The specification should be complete, including updates for GBT and the 
Stratum mining protocol. These are included in the current draft.

Additionally, it is not appropriate to begin using a draft BIP on mainnet 
before any discussion or consensus has been reached. Doing so seems quite 
malicious, in fact. I hope DragonMint miners can still operate using the 
*current* Bitcoin protocol.

Luke


On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote:
> Hi,
> 
> The following proposal reduces the number of version-bits that can be used
> for parallel soft-fork signalling, reserving 16 bits for non-specific use.
> This would reduce the number of parallel soft-fork activations using
> versionbits to from 29 to 13 and prevent node software from emitting false
> warnings about unknown signalling bits under the versionbits signalling
> system (BIP8/9). I chose the upper bits of the nVersion, because looking at
> the versionbits implementation in the most widely deployed node software,
> it is easier to implement than say annexing the lower 2 bytes of the field.
> 
> The scope of the BIP is deliberately limited to reserving bits for general
> use without specifying specific uses for each bit, although there have
> previously been various discussions of some use-cases of nVersion bits
> including version-rolling AsicBoost[1], and nonce rolling to reduce CPU
> load on mining controllers because ntime-rolling can only be done for short
> periods otherwise it could have negative side effects distorting time.
> However, specific use cases are not important for this BIP.
> 
> I am reviving discussion on this topic now, specifically, because the new
> DragonMint miner uses version-rolling AsicBoost on mainnet[2]. It is
> important to bring up so node software can adapt the versionbits warning
> system to prevent false positives. This BIP has the added advantage that
> when a new use for bits is found, mining manufacturers can play in the
> designated area without causing disruption or inconvenience (as
> unfortuntely, the use of version-rolling will cause until BIP8/9 warning
> systems are adapted). I appologise for the inconvenience in advance, but
> this is the unfortunate result of restraints while negotiating to get the
> patent opened[3] and licensed defensively[4] in the first place.
> 
> I believe there was a similar proposal[5] made some years ago, before the
> advent of BIP9. This proposal differs in that it's primary purpose is to
> remove bits from the versionbits soft-fork activation system and earmark 16
> bits for general use without allocating fixed uses for each bit. The BIP
> cites a couple of usecases for good measure, but they are just
> informational examples, not part of a specification laid down. For this
> reason, there no is mention of the version-rolling Stratum extension[6]
> specifics within the BIP text other than a reference to the specification
> itself.
> 
> Refs:
> 
> [1] https://arxiv.org/pdf/1604.00575.pdf
> [2]
> https://halongmining.com/blog/2018/03/07/dragonmint-btc-miner-uses-version-> 
> rolling-asicboost/ [3]
> https://www.asicboost.com/single-post/2018/03/01/opening-asicboost-for-defe
> nsive-use/ [4] https://blockchaindpl.org/
> [5] https://github.com/BlockheaderNonce2/bitcoin/wiki
> [6] http://stratumprotocol.org/stratum-extensions
> 
> 
>   BIP: ?
>   Title: Reserved nversion bits in blockheader
>   Author: BtcDrak 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>   Status: Draft
>   Type: Informational
>   Created: 2018-03-01
>   License: BSD-3-Clause
>CC0-1.0
> 
> 
> ==Abstract==
> 
> This BIP reserves 16 bits of the block header nVersion field for
> general purpose use and removes their meaning for the purpose of
> version bits soft-fork signalling.
> 
> ==Motivation==
> 
> There are a variety of things that miners may desire to use some of
> the nVersion field bits for. However, due to their use to coordinate
> miner activated soft-forks, full node software will generate false
> warnings about unknown soft forks if those bits are used for non soft
> fork signalling purposes. By reserving bits from the nVersion field
> for general use, node software can be updated to ignore those bits and
> therefore will not emit false warnings. Reserving 16 bits for general
> use leaves enough for 13 

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

[Luke Dashjr via bitcoin-dev]

On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote:
> BIP 123 suggests that BIPs in the consensus layer should be assigned a
> label "soft fork" or "hard fork". However, I think the differentiation
> into soft fork or hard fork should not be made for BIPs that document
> buried deployments. In contrast to soft forks and hard forks, buried
> deployments do not require community and miner coordination for a safe
> deployment.

They also do not require software coordination. Therefore, why should there be 
BIPs at all? Seems to me that we should instead add these documents to 
https://github.com/bitcoin-core/docs

That being said, I'm also okay with just adding an Annex to the original 
softfork/hardfork BIP describing each shortcut. It just seems annoying to have 
two BIPs for every protocol change: one for the change itself, and then 
another for implementation-specific shortcuts taken.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Possible change to the MIT license

[Luke Dashjr via bitcoin-dev]

This would give too much power to Bitcoin Core, and implies falsely that 
Bitcoin and Bitcoin Core are the same thing.

On Tuesday 13 February 2018 12:25:53 PM JOSE FEMENIAS CAÑUELO via bitcoin-dev 
wrote:
> Hi,
> 
> Bitcoin is licensed under the MIT license
> (https://github.com/bitcoin/bitcoin/blob/master/COPYING
> ) which is one of
> the most permissive licenses widely in use. While this almost
> restriction-less license has proved useful to many software projects, I
> think it could be wise to question its current suitability for this
> project, given the recent history.
> 
> The difficulty among the general population to distinguish between Bitcoin
> (the protocol and software) and bitcoin (the currency) arises
> spontaneously from the intimate entanglement of both. The current list of
> Bitcoin lookalikes includes: Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond,
> Bitcoin God, Bitcoin Clashic, Super Bitcoin, Bitcoin Hot, Bitcoin X, Oil
> Bitcoin, Bitcoin World, Lightning Bitcoin...
> 
> This recent flurry of hard forks is, IMHO, exacerbating the confusion about
> the very nature of the project, and harming it in many ways.
> 
> Although the liberal MIT license is (rightfully) beneficial to many other
> projects, companies and individuals, it is my belief that several projects
> are unfairly taking advantage of this generous license to attack Bitcoin
> (both the software and the currency), confuse the public, and gain
> personal profit in a way that is severely harming the Bitcoin ecosystem.
> 
> Therefore, I’d like to raise the possibility of amending the MIT license in
> a simple way, by adding a line such as:
> 
> 
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE
> NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE
> SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN
> (CORE) BLOCKCHAIN ***
> 
> (This is just an approximation. A final version would probably have to
> include a restriction to some soundalikes like BITKOIN, BIITCOIN,…)
> 
> This way, I could legitimate use this software to create my own crypto
> coin, or use it in Ethereum, Litecoin or any of the other legitimate
> cryptos, but I could not make my “Bitcoin Whatever” fork and keep using
> this software as the basis for it. I could also fork the bitcoin
> blockchain to create “Bcoin lightspeed” but not “Bitcoin lightspeed” for
> instance.
> 
> I know this would probably not prevent the explosion of forks in the
> future, but maybe it could help mitigate the confusion among the users and
> the harm to this community. Even if its enforceability is dubious, at
> least any infringing project would be exposed to some liability. I see
> myself some possible loopholes the way the license addendum is written. My
> intention is not to arrive immediately to a final wording but to know if
> there is some value to the idea of changing the license with this purpose.
> 
> 
> Jose Femenias
> ___
> 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

Re: [bitcoin-dev] BIP 117 Feedback

[Luke Dashjr via bitcoin-dev]

On Tuesday 16 January 2018 1:06:14 AM Rusty Russell via bitcoin-dev wrote:
> "Russell O'Connor"  writes:
> > However, if I understand correctly, the situation for BIP 117 is entirely
> > different.  As far as I understand there is currently no restrictions
> > about terminating a v0 witness program with a non-empty alt-stack, and
> > there are no restrictions on leaving non-canonical boolean values on the
> > main stack.
> 
> BIP-141: "The script must not fail, and result in exactly a single TRUE
> on the stack."  And it has long been non-standard for P2SH scripts to
> not do the same (don't know exactly when).

This doesn't affect the alt-stack (it's a completely separate stack).

> The rule AFAICT is "standard transactions must still work".  This was
> violated with low-S, but the transformation was arguably trivial.
> 
> OTOH, use of altstack is completely standard, though in practice it's
> unused and so only a theoretical concern.

I'm not aware of a single standard/BIP that uses the altstack at all.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bech32 and P2SH²

[Luke Dashjr via bitcoin-dev]

I've posted an initial draft of a possible Bech32 revision/replacement here:

https://github.com/luke-jr/bips/blob/new_bech32_p2sh2/bip-bech32-p2sh2.mediawiki

On Thursday 04 January 2018 2:23:05 PM Luke Dashjr via bitcoin-dev wrote:
> I know I'm super-late to bring this up, but was there a reason Bech32
> omitted the previously-discussed P2SH² improvements? Since deployment
> isn't too widespread yet, maybe it'd be worth a quick revision to add
> this?
> 
> For those unfamiliar with the concept, the idea is to have the address
> include the *single* SHA256 hash of the public key or script, rather than
> RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would then
> perform the second hash to produce the output. Doing this would in the
> future enable relaying the "middle-hash" as a way to prove the final hash
> is in fact a hash itself, thereby proving it is not embedded data spam.
> 
> Bech32 seems like a huge missed opportunity to add this, since everyone
> will probably be upgrading to it at some point.
> 
> Luke
> ___
> 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