Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage

[Keagan McClelland via bitcoin-dev]

> As a result, there are incentives structure distorted and critical
inefficiencies/vulnerabilities (e.g. misallocation of block space,
blockspace value destruction, disincentivized simple transaction,
centralization around complex transactions originators).

Can you please describe the mechanism here?

> Price of blockspace should be the same for any data (1 byte = 1 byte,
irrespectively of location inside or outside of witness), e.g. 205/205
and 767/767 bytes in the examples above.

"Should" ... to what end?

Keags

On Wed, Dec 27, 2023 at 10:26 AM Greg Tonoski via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Blockspace price for data of a simple transaction is higher than the
> one for data of other ("complex") transactions: 3 vs 1.49
> "weight"/byte in the examples below:
> - 3=616 "weight" / 205 bytes (txid:
> aabbcce67f2aa71932f789cac5468d39e3d2224d8bebb7ca2c3bf8c41d567cdd)
> - 1.49=1140 "weight" / 767 bytes (txid:
> 1c35521798dde4d1621e9aa5a3bacac03100fca40b6fb99be546ec50c1bcbd4a).
>
> As a result, there are incentives structure distorted and critical
> inefficiencies/vulnerabilities (e.g. misallocation of block space,
> blockspace value destruction, disincentivized simple transaction,
> centralization around complex transactions originators).
>
> Price of blockspace should be the same for any data (1 byte = 1 byte,
> irrespectively of location inside or outside of witness), e.g. 205/205
> and 767/767 bytes in the examples above.
>
> Perhaps, the solution (the same price, "weight" of each bit of a
> transaction) could be introduced as part of the next version of Segwit
> transactions.
>
> Let's fix it. What do you think?
> ___
> 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] Future of the bitcoin-dev mailing list

[Keagan McClelland via bitcoin-dev]

I also think that good archives are extremely important. Far more important
than being a medium of discussion is capturing all of that discussion for
posterity. An unbelievable amount of knowledge capital has been built up in
the mailing list over the years and given that Bitcoin is a system that
needs to survive complete turnover in its contributor base, it's of extreme
importance that we have a system that can capture the archive.

While Nostr might be good towards the end of being very resilient it isn't
mature enough to have good UX's built up around it wherein people with a
variety of backgrounds can engage it. Personally, I think the email UX
leaves a lot to be desired but at least it's accessible to a lot of people.
I don't think I can say the same for Nostr yet.

I won't opine much further on the solution but I think the properties we
need to solve for are:

1. Archive is effectively permanent
2. Accessible to a wide audience
3. Data format is not proprietary and isn't tied to the success or failure
of a particular organization

In principle I think that Nostr can offer a lot in the long term towards
this goal, but it isn't really an immediate solution to this problem.

Keags

On Tue, Nov 7, 2023 at 12:07 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2023-11-07 05:37, Bryan Bishop via bitcoin-dev wrote:
> > What about [...] delvingbitcoin.org?
>
> I'm only willing to consider discussion groups that provide good
> archives, so I think it's worth noting that James O'Beirne has written
> code[1] and is currently maintaining a git repo[2] with a backup of
> Delving Bitcoin discussion.  See his post[3] for additional details.
>
> In addition to providing an archive, I currently find it to be nice way
> to quickly skim all posts made to the forum since I last checked (plus I
> see edits)[4]:
>
> $ cd delving-bitcoin-archive/
> $ git pull
> $ git log -p archive/rendered-topics/
>
> I think some technical discussions were already migrating to Delving
> Bitcoin before the shutdown notice and I expect more discussions to move
> there in the future even if the current mailing list is relocated to a
> new platform.  Knowing that discussions are archived in a way that I can
> easily replicate was key to me feeling comfortable putting significant
> time into reading and writing posts on Delving Bitcoin, so I wanted to
> share that information here.
>
> -Dave
>
> [1] https://github.com/jamesob/discourse-archive
> [2] https://github.com/jamesob/delving-bitcoin-archive
> [3] https://delvingbitcoin.org/t/public-archive-for-delving-bitcoin/87/6
> [4] Plus every commit makes me laugh.  James O'Beirne's commit robot is
> called "jamesobot"
> ___
> 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". (ashneverdawn)

[Keagan McClelland via bitcoin-dev]

There is an open question as to whether or not we should figure out a way
to price space in the UTXO set. I think it is fair to say that given the
fact that the UTXO set space remains unpriced that we actually have no way
to determine whether some of these transactions are spam or not. The UTXO
set must be maintained by all nodes including pruned nodes, whereas main
block and witness data do not have the same type of indefinite footprint,
so in some sense it is an even more significant resource than chain space.
We may very well discover that if we price UTXOs in a way that reflect the
resource costs that usage of inscriptions would vanish. The trouble though
is that such a mechanism would imply having to pay "rent" for an "account"
with Bitcoin, a proposition that would likely be offensive to a significant
portion of the Bitcoin user base.

Cheers,
Keags

On Mon, Jul 31, 2023 at 4:55 AM Hugo L via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't think it's anyone's place to judge which types of transactions
> should be allowed or not on the network, in fact, when it comes to privacy
> and censorship resistance, it would be better if we were not even able to
> distinguish different types of transactions from one another in the first
> place.
>
> We have limited resources on the blockchain and so they should go to the
> highest bidder. This is already how the network functions and how it
> ensures it's security.
>
> Rather than thinking about this as "spam", I think it's useful to
> objectively think about it in terms of value to the marketplace (fees
> they're willing to pay) against cost to the network (storage consumed). It
> comes down to supply and demand.
>
> If the rate of growth of the blockchain is too high, Ordinals aren't the
> cause, it's rather that the theoretical limit of the amount of storage that
> can be added per block isn't sufficiently limited. (Whether they are used
> to produce Ordinals or something else)
>
>
>
> On Sun, Jul 30, 2023, 5:51 PM , <
> bitcoin-dev-requ...@lists.linuxfoundation.org> 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: Concern about "Inscriptions". (rot13maxi)
>>
>>
>> --
>>
>> Message: 1
>> Date: Sun, 30 Jul 2023 18:34:12 +
>> From: rot13maxi 
>> To: L?o Haf , "vju...@gazeta.pl"
>> 
>> Cc: Bitcoin Protocol Discussion
>> 
>> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
>> Message-ID:
>>
>> > protonmail.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello,
>>
>> > This cat and mouse game can be won by bitcoin defenders. Why ? Because
>> it is easier to detect these transactions and make them a standardization
>> rule than to create new types of spam transactions.
>>
>> One of the things discussed during the mempoolfullrbf discussion is that
>> a small (~10%) of nodes willing to relay a class of transaction is enough
>> for that class of transaction to consistently reach miners. That means you
>> would need to get nearly the entire network to run updated relay policy to
>> prevent inscriptions from trivially reaching miners and being included in
>> blocks. Inscription users have shown that they are willing and able to send
>> non-standard transactions to miners out of band (
>> https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
>> so even if you managed to get enough of the network running the new rule to
>> prevent propagation to miners, those users can just go out of band. Or,
>> they can simply change the script that is used to embed an inscription in
>> the transaction witness. For example, instead of 0 OP_IF?, maybe they do 0
>> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect this, they
>> have to update the rule and wait for 90%
>>  + of the network to upgrade. When the pro-inscription people see this,
>> they only have to convince other inscription enthusiasts and businesses to
>> update.
>>
>> The anti-inscription patch has to be run by many more participants (most
>> of whom don?t care), while the pro-inscription update has to be run by a
>> small number of people who care a lot. It?s a losing battle for the
>> anti-inscription people.
>>
>> If you want to prevent inscriptions, the best answer we know of today is
>> economic: the cost of the blockspace needs to be more expensive than
>> 

Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"

[Keagan McClelland via bitcoin-dev]

Hi Antoine,

Thank you for the effort you've put towards this. I generally agree that a
smooth functioning Lightning Network is of greater importance than advanced
contracting capabilities. However, as I dive deeper into some of the more
ambitious goals for LN development I am learning that a great deal of
complexity of some current lightning (LN) proposals can be handily
discharged with CTV. While I am not intimately familiar with all of the
other covenant schemes to the same level of technical proficiency, I have a
suspicion that a number of them, if not all of them, are capable of
discharging the same flavor and amount of complexity as well. Others should
chime in if they can confirm this claim.

I have been publicly on the record as supporting the addition of some
covenant scheme into Bitcoin for some time and have long held on
theoretical grounds that the addition of such a mechanism is both necessary
and inevitable if Bitcoin is to survive in the long term. However, as I've
started to work more directly with the Lightning protocol, these
theoretical and purely logical arguments became far more concrete and
immediately beneficial.

I say this primarily to challenge the idea that covenants are a distraction
from lightning development. It may very well be that your areas of focus on
LN preclude you from splitting your attention and none of this email should
be interpreted as a criticism of you applying your efforts in the highest
leverage manner you can manage. That said, I don't want observers of this
thread to walk away with the impression that they are two independent
efforts as covenants can significantly contribute to LN's maturity. When
and how should they be prioritized? Unfortunately I don't feel able to
comment on that at this time. All I know is that Lightning would almost
certainly benefit substantially from having a covenant primitive.

Cheers,
Keags

On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi list,
>
> Last year amid the failure of the CTV speedy trial activation and intense
> conversations about a rainbow of covenant proposals, I introduced the idea
> of a new community process to specify covenants [0]. This post is to resume
> the experiment so far and officially mark the process maintenance as "up
> for grabs", as I won't actively pursue it further (after wavering on such a
> decision a bit during May / June).
>
> Few of the goals announced at that time were to build a consistent
> framework to evaluate covenant proposals, see the common grounds between
> proposals if they could be composed or combined by their authors, open the
> consensus  changes development process beyond the historical boundaries of
> Bitcoin Core and maintain high-quality technical archive as a consensus
> discussions have spawned half a decade from intellectual conception to
> activation in average (at least for segwit, schnorr, taproot).
>
> Such effort was a speak-by-the-act answer to the issues in
> consensus development changes pointed out by Jeremy Rubin in April of last
> year [1]: namely the lack of a "codified checklist" for consensus changes,
> that "consensus is memoryless" and "bitcoin core is not bitcoin"
> (independently of the technical concerns as I have as limited or
> non-adequate primitive for vaults / payment pools I expressed during the
> same time). Other complementary initiatives have been undertaken during the
> same period, AJ with the bitcoin-inquisition fork where the community of
> developers and contracting primitives of researchers on a consensus-enabled
> fork of core [2]. And Dave Harding with the careful archiving of all
> covenant proposals under the Optech umbrella [3].
>
> About the Bitcoin Contracting Primitives WG, a Github repository was
> started and maintained to archive and document all the primitives (apo,
> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
> check_output_covenant_verify, inherited ids, anyamount, singletons,
> op_vault) and the corresponding protocols (payment pools, vaults,
> drivechains, trust-minimized mining pools payouts). We had a total of 6
> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
> a number of more than 20 individual attendees representing most of the
> parts of the community. I think (missing march logs). Numerous in-depth
> discussions did happen on the repository and on the channel on things like
> "merkelized all the things" or "payment pools for miners payoffs".
>
> As I've been busy on the Lightning-side and other Bitcoin projects, I've
> not run an online meeting since the month of April, while still having a
> bunch of fruitful technical discussions with folks involved in the effort
> at conferences and elsewhere. I launched the effort as an experiment with
> the soft commitment to dedicate 20% of my time on it, after few successful
> sessions I think such a process has an interest of its own, however it
> 

Re: [bitcoin-dev] Formosa --- proposed improvement upon BIP39

[Keagan McClelland via bitcoin-dev]

Good day Yuri,

This is a very cool idea. After reviewing the repository it seems that
there lacks a BIP style specification for this, so it is possible that some
of my takeaways may not be correct but I figured I'd comment with some
observations anyway. Feel free to correct me where I've made a mistake.

I think to make an idea like this work it would be necessary for it to
"extend" BIP39 rather than "replace" it. What I mean by this is that BIP39
is heavily entrenched in the ecosystem and so in order for you to sidestep
the need to get everyone in the ecosystem to adopt a new standard, you'd
want this process to be able to output a standard BIP39 seed sequence. This
becomes even more important when you allow these different "themes" that
are mentioned later in the document. The notion of themes practically
precludes the standardization of the technique since customization really
is the antithesis of standardization.

The largest value proposition of these schemes is that it allows
significant wallet interoperability. This is achieved if process for
translating these phrases to the underlying wallet seed is deterministic.
Themes may prove to make this harder to solve. I also do not believe that
themes meaningfully increase the ability to remember the phrase: the fact
that the phrase has a valid semantic at all is a massive step up from an
undifferentiated sequence of words that is the current state of BIP39. The
benefits afforded by the themes here are little by comparison.

Overall, I think exploring this idea further is a good idea. However, there
may be concerns about whether the increased memorability is a good thing.
It would certainly make $5 wrench attacks more viable, not less. I can't
help but ask myself the question whether more Bitcoin is lost because of
seed phrases not being memorized, or because of social engineering
exercises used to scrape these phrases from the brains of users. I have a
hunch that loss is a larger problem than theft, but it is a very real
possibility that a wide deployment of this type of tech could change that.

Stay Inspired,
Keags

On Tue, May 2, 2023 at 6:05 AM Yuri S VB via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dear colleagues,
>
> The following is a password format that improves upon BIP39 by allowing
> meaningful, themed sentences with a regular grammatical structure instead
> of semantically disconnected words, while keeping the same entropy/checksum
> and total bits/non-repeating leading digits ratios (of 32/1 and 11/4
> respectively).
>
> https://github.com/Yuri-SVB/formosa
>
> Anecdotal experiments suggest that less than one hour of moderate
> concentration is enough for long term memorization of 128 + 4 bits
> (equivalent to the 12 words standard of BIP39) if a theme of interest is
> employed.
>
> I hereby offer it to your scrutiny as a Bitcoin Improvement Proposal.
> Please don't hesitate to ask whatever issue about the project there might
> be.
>
> Faithfully yours, Yuri S VB.
>
> ___
> 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] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Keagan McClelland via bitcoin-dev]

Erik,

I'm curious about what you believe to be "non-economic" txs. As far as I
can tell, any transaction included in the blockchain is economically
motivated by the very evidence of fees paid. That said, for the sake of
argument if we assume that there exists a category of information that
constitutes "non-economic" information, then so long as there is any
variance in the way to express a single economic intention, there exists a
vector for including "non-economic" information. I'll add beyond this that
there must always be variance in the way to express the same intent because
the signature data must be indistinguishable from entropy for Bitcoin's
security to hold.

Even if we eliminate small UTXOs, OP_RETURN, or whatever other vector of
the day that is currently being used to propagate such "non-economic"
information, we will always have the potential variance in the signature
data to do so. The best you can hope for is to make such means so
inefficient that the real cost-per-bit is expensive enough that there are
fewer distinct use cases. However, this isn't enough to actually *prevent*
the "spam". By increasing the cost-per-bit, it may limit it to only
"non-economic" information of extremely high value (note the
contradiction), it limits the number of use cases while also increasing the
impact of the use cases that make it past that threshold. Thus, it isn't
the impact of spam that is being reduced so much as it is reducing the
number of distinct use cases that result in "spam". Perhaps this is enough
to make spam more intermittent, and maybe on those grounds alone it could
be worth it, but I doubt it.

IMO the proper way to handle things like this isn't to introduce consensus
or relay policy to incentivize the expansion of the chain weight these
"non-economic" use cases require, but rather to reduce the necessary chain
footprint of supposed "economically motivated" transactions, which
incidentally is the entire point of all layered scaling tech. The current
fees we are experiencing are still significantly lower than they need to be
if Bitcoin is going to survive in a post-subsidy era. If our layered
protocols can't survive the current fee environment, the answer is to fix
the layered protocols.

Food for thought.

Stay Inspired,
Keags

On Tue, May 9, 2023 at 12:38 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>> > no data at all
>
>
> exactly, which is why a relationship between "cpfp-inclusive outputs" and
> "fees" makes sense.   it's clear that's a good definition of dust, and not
> too hard to get a working pr up for the network-layer.   i get that your
> node will still route.   i get that it would break timestamps, indeed, it
> would break all non-economic use cases if we made it a consensus change.
>
> but that's the point of the discussion.
>
> the question is whether breaking all non-economic use cases is the right
> move, given the game-theory of what underpins bitcoin
>
> i'm sad (honestly) to say that it might be
>
> it may very well be that bitcoin *cannot* be a "global ledger of all
> things" in order to remain useful and decentralized, and instead the
> monetary use case must be it's only goal
>
> also, i'm not really advocating for this solution so much as i would like
> a
>
> - rational conversation about the incentives
> - whether this solution would be an effective enough barrier to keep most
> non-economic tx off bitcoin
>
> obviously it's easy enough to evade if every non-economic user simply
> keeps enough bitcoin around and sends it back to himself
>
> so maybe it's a useless idea?   but maybe that's enough of a hassle to
> stop people (it certainly breaks ordinals, since it can never be 1 sat)
>
> ___
> 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] Seeking concept ACKs for transaction terminology BIP

[Keagan McClelland via bitcoin-dev]

Concept ACK,

The only way we can hope to have productive discussion is to minimize the
amount of effort spent in miscommunication especially that which arises
from unclear terminology. Which exact words refer to which meanings is
somewhat arbitrary, (look at math, particularly abstract math), but what
matters is that there is precision in their use to whatever degree is
possible. Having a document of shared terminology helps us communicate with
one another and speeds up the process of coming to social consensus on
issues.

Stay Inspired,
Keags

On Wed, Apr 5, 2023 at 2:54 PM Murch via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hey everyone,
>
> Over the years, I have participated in a few conversations about various
> aspects of transactions. Often a chunk of the conversation is spent on
> establishing a shared vocabulary. There are many competing terms—e.g. I
> can think of at least three additional terms that refer to `scriptPubKey`.
>
> I’ve drafted an informational BIP that proposes terminology for various
> components and aspects of transactions. As some established terms are
> already contradictory, the proposal does not aim for a perfectly
> consistent selection of terms, but rather just to establish a shared
> vocabulary to avoid confusion.
>
> Draft: https://github.com/Xekyo/bips/pull/1
>
> Please let me know whether you’d be interested in the creation of such a
> BIP.
>
> Cheers,
> Murch
> ___
> 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] Bitcoin covenants are inevitable

[Keagan McClelland via bitcoin-dev]

> The PoW security of Bitcoin benefits all Bitcoin users, proportional to
the
value of BTC they hold; if Bitcoin blocks aren't reliably created the value
of
*all* BTC goes down. It doesn't make sense for the entire cost of that
security
to be paid for on a per-tx basis. And there's a high chance paying for it
on a
per-tx basis won't work anyway due to lack of consistent demand.

FWIW I prefer the demurrage route. Having something with finite supply as a
means of measuring economic activity is unprecedented and I believe deeply
important. I'm sympathetic to the argument that the security of the chain
should not be solely the responsibility of transactors. We realize the
value of money on receipt, hold *and* spend and it would be appropriate for
there to be a balance of fees to that effect. While inflation may be
simpler to implement (just chop off the last few halvings), I think it
would be superior (on the assumption that such a hodl tax was necessary) to
keep the supply fixed and have people's utxo balances decay, at least at
the level of the UX.

But also none of this should be reasons we don't improve Bitcoin's value
(and therefore demand)

Keagan

On Mon, Jun 20, 2022 at 2:42 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>  if we start seeing issues with block rewards being too low to maintain
>> acceptable security, we're going to have multiple solutions being
>> implemented for it, and definitely a hard fork to indefinitely maintain
>> some degree of block subsidy
>>
>
> if we failed to first try increasing block demand with advanced
> transaction support, it would seem like we were just throwing money and
> growth away to support one narrative (simplicty of function), while
> destroying another (finite supply)
>
> if stuff like covenant support and mweb gets us higher fees, with stuff
> like on-chain mixing protocols, vaults, and higher utility, it might be
> more than enough to sustain bitcoin on fees alone forever
>
> ___
> 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] Bitcoin covenants are inevitable

[Keagan McClelland via bitcoin-dev]

> will never be justifiable simply because you and some of your friends
think it is totally cool and might make more people like you or give your
friends funding.

100%

But while the OP may have given less than ideal reasons for things like
covenants, it does not broadly characterize the reasons for adding them to
the Bitcoin protocol. The reasons to do so are:

- better self custody solutions that don’t rely on the trust of named third
parties
- significantly more tractable solutions for things like coin pools
- significantly more efficient DLCs

These are not “hackathon project” reasons and are the main reasons people
advocate for covenants.

> None of the quoted following items are features or responsibilities of
the Bitcoin software, nor Core developers.

Since you seem to have the stone tablets onto which our responsibilities
are etched, would you care to enumerate them?

> Whether you are a child or an attacker, none of us should care,

Are you incapable of actually treating people with respect or do you think
that bullying people on this mailing list is the most effective way to get
what you want? If it’s the latter I may suggest you go back to Twitter
where that works and maybe just leave those comments out of the mailing
list if you actually want to convince people of your point of view.

Keagan

On Sat, Jun 4, 2022 at 7:37 AM John Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Core development is not a hackathon project.
>
> None of the quoted following items are features or responsibilities of the
> Bitcoin software, nor Core developers.
>
> Quoted:
> "- Developers can build interesting projects with real demand in market.
> - Students learn Sapio and not just solidity.
> - Better tooling could be available for application developers.
> - Maybe we see bitcoin developer hackathons in different countries.
> - Demand for block space might increase, it wont be just exchanges and
> coinjoin.
> - Funding of bitcoin developers and projects might improve. Wont need to
> convince a few people for grants."
>
> Whether you are a child or an attacker, none of us should care, but CTV,
> nor any change to Bitcoin software, will never be justifiable simply
> because you and some of your friends think it is totally cool and might
> make more people like you or give your friends funding.
>
> Please stop making noise about CTV, this is not a place for spamming.
>
> --
> John Carvalho
>
>
>
> On Sat, Jun 4, 2022 at 1:00 PM <
> bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:
>
>>
>> Date: Fri, 03 Jun 2022 18:39:34 +
>> From: alicexbt 
>> To: Bitcoin Protocol Discussion
>> 
>> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
>> Message-ID:
>>
>> > protonmail.com>
>>
>> Content-Type: text/plain; charset=utf-8
>>
>> Note: This email is an opinion and not an attack on bitcoin
>>
>> Covenants on bitcoin will eventually be implemented with a soft fork. CTV
>> is the easiest and best possible way OP_TX looks good as well. Apart from
>> the technical merits, covenants will improve a few other things:
>>
>> - Developers can build interesting projects with real demand in market.
>> - Students learn Sapio and not just solidity.
>> - Better tooling could be available for application developers.
>> - Maybe we see bitcoin developer hackathons in different countries.
>> - Demand for block space might increase, it wont be just exchanges and
>> coinjoin.
>> - Funding of bitcoin developers and projects might improve. Wont need to
>> convince a few people for grants.
>>
>> **Why covenants are not contentious?**
>>
>> Some people may write paragraphs about CTV being contentious, spread
>> misinformation and do all types of drama, politics etc. on social media but
>> there are zero technical NACKs for CTV. We have discussed other covenant
>> proposals in detail on mailing list and IRC meetings with an open minded
>> approach.
>>
>> All the developers that participated in the discussion are either okay
>> with CTV or OP_TX or covenants in general.
>>
>> **How and when should covenants be implemented in Bitcoin?**
>>
>> I don't think we should wait for years anticipating a proposal that
>> everyone will agree on or argue for years to pretend changes are hard in
>> Bitcoin. We should improve the review process for soft fork BIPs and share
>> honest opinions with agreement, disagreement on technical merits.
>>
>> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything
>> else being used if that improves Bitcoin. Covenants implemented in Bitcoin
>> before the next cycle would provide opportunity for developers to build
>> interesting things during the bear market. Ossification supporters also
>> believe there is some window that will close soon, maybe doing changes
>> considering each case individually will be a better approach. CTV is not a
>> rushed soft fork, less people followed the research and it was not
>> mentioned on social media repeatedly by the respected 

Re: [bitcoin-dev] A Calculus of Covenants

[Keagan McClelland via bitcoin-dev]

> One must also analyze all the covenants that one *could* author using a
primitive

So as I've been contemplating this more, I'm realizing that a calculus of
covenants themselves may not make as much sense as a broader calculus of
Bitcoin transactions as a whole. I think this comment that you made in your
followup solidified that position. If you have to analyze it in the context
of all of the other opcodes that could potentially interact with it, you
don't really have a closed algebra that you can really try to understand
and evaluate. I'm still ruminating on what such a calculus would be, but it
also makes me more convinced that Simplicity gets a lot right here. That
said, there is probably an opportunity for a significantly more domain
specific set of primitives than what simplicity offers that would allow you
similar practical use cases but with a much more high level analysis.

The way I think about this now is that most of the primitives in the
Bitcoin script VM right now are constraints on the witness, you have a
couple of opcodes that are constraints on the chain state, and then
covenants are really a constraint on the body of the transaction that
spends an input. I think most of the time we imagine covenants of output
constraints but you can also imagine a hypothetical covenant that says,
"this input may not be spent alongside any other inputs". This is still a
constraint on the spending transaction despite the fact that it mentions
nothing of the outputs, and I would still broadly think of this as a
covenant. I think depending on how you define "family" and "state
transition" it would tolerate this distinction. However, it definitely
complicates the question of things like unrollability. Is a covenant that
permits any output(s) but the input must be spent alone unrollable? Does
the concept unrollable even make any sense when you aren't constraining the
outputs?

These thoughts aren't completely baked but I figured I'd jot them down
while I was thinking about it.

Keagan

On Tue, Apr 12, 2022 at 9:04 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> note of clarification:
>
> this is from the perspective of a developer trying to build infrastructure
> for covenants. from the perspective of bitcoin consensus, a covenant
> enforcing primitve would be something like OP_TLUV and less so it's use in
> conjunction with other opcodes, e.g. OP_AMOUNT.
>
> One must also analyze all the covenants that one *could* author using a
> primitive, in some sense, to demonstrate that our understanding is
> sufficient. As a trivial example, you could use
> OP_DELETE_BITCOIN_ENTIRELY_IF_KNOWS_PREIMAGE_TO_X_OR_TLUV and just because
> you could use it safely for TLUV would not mean we should add that opcode
> if there's some way of using it negatively.
>
> Cheers,
>
> Jeremy
> --
> @JeremyRubin 
>
>
> On Tue, Apr 12, 2022 at 10:33 AM Jeremy Rubin 
> wrote:
>
>> Sharing below a framework for thinking about covenants. It is most useful
>> for modeling local covenants, that is, covenants where only one coin must
>> be examined, and not multi-coin covenants whereby you could have issues
>> with protocol forking requiring a more powerful stateful prover. It's the
>> model I use in Sapio.
>>
>> I define a covenant primitive as follows:
>>
>> 1) A set of sets of transaction intents (a *family)*, potentially
>> recursive or co-recursive (e.g., the types of state transitions that can be
>> generated). These intents can also be represented by a language that
>> generates the transactions, rather than the literal transactions
>> themselves. We do the family rather than just sets at this level because to
>> instantiate a covenant we must pick a member of the family to use.
>> 2) A verifier generator function that generates a function that accepts
>> an intent that is any element of one member of the family of intents and a
>> proof for it and rejects others.
>> 3) A prover generator function that generates a function that takes an
>> intent that is any element of one member of the family and some extra data
>> and returns either a new prover function, a finished proof, or a rejection
>> (if not a valid intent).
>> 4) A set of proofs that the Prover, Verifier, and a set of intents are
>> "impedance matched", that is, all statements the prover can prove and all
>> statements the verifier can verify are one-to-one and onto (or something
>> similar), and that this also is one-to-one and onto with one element of the
>> intents (a set of transactions) and no other.
>> 5) A set of assumptions under which the covenant is verified (e.g., a
>> multi-sig covenant with at least 1-n honesty, a multisig covenant with any
>> 3-n honesty required, Sha256 collision resistance, DLog Hardness, a SGX
>> module being correct).
>>
>> To instantiate a covenant, the user would pick a particular element of
>> the set of sets of transaction intents. For example, in TLUV payment pool,
>> it 

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Keagan McClelland via bitcoin-dev]

> > > To me the most scary one is visacoin, specially seeing what happened
in canada and other places lately and the general censorship in the west,
the supposed war on "misinformation" going on (really a war against truth
imo, but whatever) it's getting really scary. But perhaps someone else can
be more scared about a covenant to add demurrage fees to coins or
something, I don't know.
> > > https://bitcointalk.org/index.php?topic=278122

> > This requires *recursive* covenants.

> Actually, for practical use, any walled-garden requires *dynamic*
covenants, not recursive covenants.

There's actually also a very straight forward defense for those who do not
want to receive "tainted" coins. In every covenant design I've seen to date
(including recursive designs) it requires that the receiver generate a
script that is "compliant" with the covenant provisions to which the sender
is bound. The consequence of this is that you can't receive coins that are
bound by covenants you weren't aware of*. So if you don't want to receive
restricted coins, just don't generate an address with those restrictions
embedded. As long as you can specify the spend conditions upon the receipt
of your funds, it really doesn't matter how others are structuring their
own spend conditions. So long as the verification of those conditions can
be predictably verified by the rest of the network, all risk incurred is
quarantined to the receiver of the funds. Worst case scenario is that no
one wants to agree to those conditions and the funds are effectively burned.

It's not hard to make the case that any time funds are being transferred
between organizations with incompatible interests (external to a firm),
that they will want to be completely free to choose their own spend
conditions and will not wish to inherit the conditions of the spender.
Correspondingly, any well implemented covenant contract will include
provisions for escaping the recursion loop if some sufficiently high bar is
met by the administrators of those funds. Unless governments can mandate
that you generate these addresses AND force you to accept funds bound by
them for your services**, I don't actually see how this is a real concern.

*This requires good wallet tooling and standards but that isn't materially
different than wallets experimenting with non-standard recovery policies.

**This is a reason to oppose legal tender laws for Bitcoin imo.

Keagan

On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  This requires *recursive* covenants.
>
> Actually, for practical use, any walled-garden requires *dynamic*
> covenants, not recursive covenants. CTV can get arbitrarily close to
> recursive covenants, because you can have an arbitrarily long string of
> covenants. But this doesn't help someone implement visacoin because CTV
> only allows a specific predefined iteration of transactions, meaning that
> while "locked" into the covenant sequence, the coins can't be used in any
> way like normal coins - you can't choose who you pay, the sequence is
> predetermined.
>
> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
> )
> don't automatically allow for practical walled gardens. Recursion
> definitely allows creating walled gardens, but those gardens would be
> impractically static. You could add millions of potential addresses to send
> to, which would "only" quadruple the size of your transactions, but if
> anyone creates a new address you want to send to, you wouldn't be able to.
> Everyone would have to have a single address whitelisted into every
> government-bitcoin output. If someone lost their key and needs to create a
> new wallet, suddenly no one would be able to pay them.
>
> In order to really build a wallet garden, infinite recursion isn't really
> necessary nor sufficient. You need to be able to dynamically specify
> destination addresses. For example, if you were a government that wants to
> make a walled garden where you (the government) could confiscate the funds
> whenever you wanted, you'd have to have a covenant that allows the end-user
> to specify an arbitrary public key to send money to. The covenant might
> require that user to send to another covenant that has a government spend
> path, but also has a spend path for that user-defined public key. That way,
> you (the government) could allow people to send to each other arbitrarily,
> while still ensuring that you (the government) could spend the funds no
> matter where they may have been sent. Even without recursive covenants, you
> could have arbitrarily long chains of these, say 1 million long, where at
> the end of the chain the user must send your coins back to the government
> who can then send them back with another million-long chain of covenants to
> work with.
>
> OP_CHECKOUTPUTVERIFY 

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

[Keagan McClelland via bitcoin-dev]

f merit or just plain old grit).
However, if this is the case, I don't think we can honestly claim that devs
don't control the protocol (as a group).

I don't think we will have broad agreement on #1 as it is ultimately a
value judgement and even the most intellectually honest people in Bitcoin
dev are going to have different value sets. I think this is OK, to a
degree. But where a lot of communication breakdown occurs is when people
are debating the properties of #2/#3 when they don't even know that there
is disagreement between them on #1. I think that everyone having an
individual answer to #1 can make these discussions go a lot more smoothly
in the technical sphere since I think most people can suspend their own
values for the sake of analyzing the effectiveness of a particular
approach. I am concerned, however, that if value differences are allowed to
be passed off as technical evaluations, the quality of the conversation may
erode to the point where no meaningful advancement can happen anymore,
since we will lose our shared framework for understanding. If this occurs
too soon, I believe quite strongly that Bitcoin will be captured through
the increasing power of custodial institutions.

Keagan

On Wed, Apr 27, 2022 at 11:22 AM  wrote:

> The idea seems interesting at first glance, but soon we see several
> problems. The biggest problem with votes of this type is that they can be
> easily manipulated. Imagine a powerful attacker who impersonates someone in
> good faith and arrives with a proposal that looks great but has dark ends
> behind it (and that no one has simply noticed yet). It would be enough for
> this attacker to convince major wallets, major exchanges and even
> individuals to believe him. It could be with a good marketing campaign or
> even buying these people. This would create a "false consensus", a
> misconception of what consensus means.
>
> For me, the consensus should follow the current line: discussions and
> tests carried out by experts. We all know that the most important devs have
> the most weight in discussions. And that's how it should be, because they
> understand far better than any other lowly mortal. Consensus simply means
> that there are not at least two or three important people opposing the idea
> with solid arguments. Is it very subjective and difficult? Yes. For sure.
> We all yearn for objective answers or methods. However, any method would
> fail. At the end, after numerous discussions and an apparent consensus, the
> objective answer and the real consensus will be obtained in the network, in
> the nodes upgrading. If there is a big war, the network will end up
> splitting in two, as it has in the past. To avoid any unwanted splits we
> discuss for exhaustion here in the list.
>
> I don't think flagging transactions would be a good method to measure this
> sort of thing. You are handing important technical discussions into the
> hands of those who have no idea about the subject.
>
> Felipe.
>
> On Tue, Apr 26, 2022 at 5:12 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Alongside the debate with CTV right now there's a second debate that was
>> not fully hashed out in the activation of Taproot. There is a lot of
>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
>> etc. A significant reason for the breakdown in civility around this debate
>> is that because we don't have a means of measuring user support for
>> proposed sof-fork changes, it invariably devolves into people claiming that
>> their circles support/reject a proposal, AND that their circles are more
>> broadly representative of the set of Bitcoin users as a whole.
>>
>> It seems everyone in this forum has at one point or another said "I would
>> support activation of  if there was consensus on it, but there isn't".
>> This statement, in order to be true, requires that there exist a set of
>> conditions that would convince you that there is consensus. People have
>> tried to dodge this question by saying "it's obvious", but the reality is
>> that it fundamentally isn't. My bubble has a different "obvious" answer
>> than any of yours.
>>
>> Secondly, due to the trauma of the block size wars, no one wants to utter
>> a statement that could imply that miners have any influence over what
>> rulesets get activated or don't. As such "miner signaling" is consistently
>> devalued as a signal for market demand. I don't think this is reasonable
>> since following the events of '17  miners are aware that they have the
>> strong incentive that they understand market demand. Nevertheless, as it
>> stands right now the only signal we 

[bitcoin-dev] Towards a means of measuring user support for Soft Forks

[Keagan McClelland via bitcoin-dev]

Hi all,

Alongside the debate with CTV right now there's a second debate that was
not fully hashed out in the activation of Taproot. There is a lot of
argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
etc. A significant reason for the breakdown in civility around this debate
is that because we don't have a means of measuring user support for
proposed sof-fork changes, it invariably devolves into people claiming that
their circles support/reject a proposal, AND that their circles are more
broadly representative of the set of Bitcoin users as a whole.

It seems everyone in this forum has at one point or another said "I would
support activation of  if there was consensus on it, but there isn't".
This statement, in order to be true, requires that there exist a set of
conditions that would convince you that there is consensus. People have
tried to dodge this question by saying "it's obvious", but the reality is
that it fundamentally isn't. My bubble has a different "obvious" answer
than any of yours.

Secondly, due to the trauma of the block size wars, no one wants to utter a
statement that could imply that miners have any influence over what
rulesets get activated or don't. As such "miner signaling" is consistently
devalued as a signal for market demand. I don't think this is reasonable
since following the events of '17  miners are aware that they have the
strong incentive that they understand market demand. Nevertheless, as it
stands right now the only signal we have to work with is miner signaling,
which I think is rightly frustrating to a lot of people.

So how can we measure User Support for a proposed rule change?

I've had this idea floating around in the back of my head for a while, and
I'd like to solicit some feedback here. Currently, all forms of activation
that are under consideration involve miner signaling in one form or
another. What if we could make it such that users could more directly
pressure miners to act on their behalf? After all, if miners are but the
humble servants of user demands, this should be in alignment with how
people want Bitcoin to behave.

Currently, the only means users have of influencing miner decisions are A.
rejection of blocks that don't follow rules and B. paying fees for
transaction inclusion. I suggest we combine these in such a way that
transactions themselves can signal for upgrade. I believe (though am not
certain) that there are "free" bits in the version field of a transaction
that are presently ignored. If we could devise a mapping between some of
those free bits, and the signaling bits in the block header, it would be
possible to have rules as follows:

- A transaction signaling in the affirmative MUST NOT be included in a
block that does not signal in the affirmative
- A transaction that is NOT signaling MAY be included in a block regardless
of that block's signaling vector
- (Optional) A transaction signaling in the negative MUST NOT be included
in a block that signals in the affirmative

Under this set of conditions, a user has the means of sybil-resistant
influence over miner decisions. If a miner cannot collect the fees for a
transaction without signaling, the user's fee becomes active economic
pressure for the miner to signal (or not, if we include some variant of the
negative clause). In this environment, miners could have a better view into
what users do want, as would the Bitcoin network at large.

Some may take issue with the idea that people can pay for the outcome they
want and may try to compare a method like this to Proof of Stake, but there
are only 3 sybil resistant mechanisms I am aware of, and any "real" view
into what social consensus looks like MUST be sybil resistant:

- Hashpower
- Proof of personhood (KYC)
- Capital burn/risk

Letting hashpower decide this is the thing that is currently contentious,
KYC is dead on arrival both on technical and social grounds, which really
just leaves some means of getting capital into the process of consensus
measurement. This mechanism I'm proposing is measurable completely
en-protocol and doesn't require trust in institutions that fork futures
would. Additionally it could be an auxiliary feature of the soft fork
deployment scheme chosen making it something you could neatly package all
together with the deployment itself.

There are many potential tweaks to the design I propose above:
1. Do we include a notion of negative signaling (allowing for the
possibility of rejection)
2. Do we make it such that miner signaling must be congruent with >X% of
transactions, where congruence is that the signal must match any
non-neutral signal of transaction.

Some anticipated objections:

1. signaling isn't voting, no deployment should be made without consensus
first.
- yeah well we can't currently measure consensus right now, so that's not a
super helpful thing to say and is breeding ground for abuse in the form of
certain people making the unsubstantiated claim that consensus does or 

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland via bitcoin-dev]

> BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period.

Thanks for the clarification.

> Semi-mandatory in that only "threshold" blocks must signal, so if
only 4% or 9% of miners aren't signalling and the threshold is set
at 95% or 90%, no blocks will be orphaned.

How do nodes decide on which blocks are orphaned if only some of them have
to signal, and others don't? Is it just any block that would cause the
whole threshold period to fail?

Keagan

On Mon, Apr 25, 2022 at 11:00 AM Anthony Towns  wrote:

> On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Under *any* other circumstance, when they're used to activate a bad
> soft
> > > fork, speedy trial and bip8 are the same. If a resistance method works
> > > against bip8, it works against speedy trial; if it fails against speedy
> > > trial, it fails against bip8.
> > IIRC one essential difference between ST (which is a variant of BIP9) and
> > BIP8 is that since there is no mandatory signaling during the lockin
> > period,
>
> BIP8 doesn't have mandatory signaling during the lockin period, it has
> semi-mandatory [0] signalling during the must_signal period.
>
> > you can't do a counter soft fork as easily.
>
> The "counter" for bip8 activation is to reject any block during either
> the started or must_signal phases that would meet the threshold. In that
> case someone running bip8 might see blocks:
>
>   [elapsed=2010, count=1813, signal=yes]
>   [elapsed=2011, count=1813, signal=no]
>   [elapsed=2012, count=1814, signal=yes]
>   [elapsed=2013, count=1815, signal=yes, will-lockin!]
>   [elapsed=2014, count=1816, signal=yes]
>   [elapsed=2015, count=1816, signal=no]
>   [elapsed=2016, count=1816, signal=no]
>   [locked in!]
>
> But running software to reject the soft fork, you would reject the
> elapsed=2013 block, and any blocks that build on it. You would wait for
> someone else to mine a chain that looked like:
>
>   [elapsed=2013, count=1814, signal=no]
>   [elapsed=2014, count=1814, signal=no]
>   [elapsed=2015, count=1814, signal=no]
>   [elapsed=2016, count=1814, signal=no]
>   [failed!]
>
> That approach works *exactly* the same with speedy trial.
>
> Jeremy's written code that does exactly this using the getdeploymentinfo
> rpc to check the deployment status, and the invalidateblock rpc to
> reject a block. See: https://github.com/JeremyRubin/forkd
>
> The difference to bip8 with lot=true is that nodes running speedy trial
> will reorg to follow the resisting chain if it has the most work. bip8
> with lot=true nodes will not reorg to a failing chain, potentially
> creating an ongoing chain split, unless one group or the other gives up,
> and changes their software.
>
> Cheers,
> aj
>
> [0] Semi-mandatory in that only "threshold" blocks must signal, so if
> only 4% or 9% of miners aren't signalling and the threshold is set
> at 95% or 90%, no blocks will be orphaned.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland via bitcoin-dev]

Hi AJ,

> Under *any* other circumstance, when they're used to activate a bad soft
fork, speedy trial and bip8 are the same. If a resistance method works
against bip8, it works against speedy trial; if it fails against speedy
trial, it fails against bip8.

IIRC one essential difference between ST (which is a variant of BIP9) and
BIP8 is that since there is no mandatory signaling during the lockin
period, you can't do a counter soft fork as easily. This is one of the
points that Luke mentioned to me that made clear the benefits of the
mandatory signaling. A variant of ST that does require mandatory signaling
may actually be something that can improve the process and give users a
more effective means of forking away from SF changes that they reject.

Keagan

On Sun, Apr 24, 2022 at 12:58 PM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns  wrote:
>
>> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
>> > You're not even considering user resistance in your cases.
>>
>> Of course I am. Again:
>>
>
> No, you're relying on miners to stop bad proposals.
>
>
>> > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
>> > > attempting activation via bip8 is *never* superior to speedy trial,
>> > > and in some cases is worse.
>> > >
>> > > If I'm missing something, you only need to work through a single
>> example
>> > > to demonstrate I'm wrong, which seems like it ought to be easy... But
>> > > just saying "I disagree" and "I don't want to talk about that" isn't
>> > > going to convince anyone.
>>
>> The "some cases" where bip8 with lot=true is *worse* than speedy trial
>> is when miners correctly see that a bad fork is bad.
>>
>> Under *any* other circumstance, when they're used to activate a bad soft
>> fork, speedy trial and bip8 are the same. If a resistance method works
>> against bip8, it works against speedy trial; if it fails against speedy
>> trial, it fails against bip8.
>>
>
> You're wrong.
>
>
>> > Sorry for the aggressive tone, but I when people ignore some of my
>> points
>> > repeteadly, I start to wonder if they do it on purpose.
>>
>> Perhaps examine the beam in your own eye.
>>
>
> Yeah, whether you do that yourself or not: sorry, it's over.
>
>
>> Cheers,
>> aj
>>
> ___
> 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] User Resisted Soft Fork for CTV

[Keagan McClelland via bitcoin-dev]

Good day Michael,

> and discuss working on an additional release that if run may ultimately
reject blocks that signal for CTV.

This seems silly to me.

The structure of CTV is imbuing an OP_NOP with script semantics. Resisting
changes that don't affect you is not consistent with the ideals of people
being able to structure their own private agreements as they see fit...aka
freedom. It seems needlessly coercive to try and resist CTV in this way.
CTV is ultimately an opt-in proposal. If you don't like the risk/benefit
ratio, you can simply not generate scripts that contain CTV checks.
Conservatism and apathy are something I can understand, but resisting CTV
via an escalating soft fork is not conservatism or apathy, it's fundamental
opposition. What is it that you hope to accomplish by blocking others from
using a new opcode? According to your formal statement, you haven't really
opposed CTV on fundamental grounds so much as vaguely questioning whether
or not it is the "best tool for the job"...as if anyone really has the
capacity to judge that for a diverse group with varying interests and use
cases that may differ substantially from their own.

There are really two ways to effectively resist this change: 1. reject all
blocks during the lockin period, 2. reject all blocks that include OP_CTV
in the script.

Regardless of which method you choose, it is ultimately going to be a far
more forceful/invasive consensus change than CTV was in the first place. So
have fun trying to explain yourself out of that one. You've gone from
saying you won't NACK the proposal on its own to intentionally cause
consensus forks to block its enforcement. Did you change your mind or
something?

> Hence it is prudent to prepare for an eventuality where the miner
signaling threshold might be reached but the community wants to prevent the
attempted soft fork from activating. (I personally don't think a 90 percent
miner signaling threshold will be reached but I wouldn't want to bet
Bitcoin's future on it.)

Making the statement that "the community doesn't want this to activate" as
if it's some kind of foregone conclusion is a pretty bold claim. I think
you'll be surprised at how broad support actually is. To contrast your
second citation, here's the set of people who have endorsed the proposal,
along with a handful of people opposed (such as yourself):
https://utxos.org/signals/. If you are aware of others who are opposed, it
would be worth your time to solicit a statement from them that can be put
on the signals page. Absent that, it seems appropriate to assume that the
overwhelming majority of people who have opined on the subject are for it.

> But as always with Jeremy caution and conservatism seems to be thrown out
the window and we have to react to that. It goes without saying that this
is not how Bitcoin consensus changes should be attempted.

What an unhinged take. The level of effort put into gathering consensus for
CTV has set the bar higher than Taproot. Taproot didn't have the level of
outreach effort that CTV does, and the complexity in taproot is
significantly larger than for CTV. You didn't seem to have a problem
organizing that activation process. That proposal was opened for public
discussion in Jan'20, merged in Oct'20, and you were organizing activation
discussions as early as Jan'21. The design of CTV has been *final* since
Feb'20, a month after Taproot was opened for public discussion. There's a
ton of Proof-of-Concept code that has been written to test out use cases
for CTV, but for Taproot it still doesn't look like we'll have MuSig for a
while longer (I heard a year, but someone can correct me on that if I'm
wrong), and wallet support for Taproot wasn't fleshed out until after
activation. Characterizing Jeremy's efforts as throwing caution and
conservatism out the window is hypocritical at best and malicious at worst.

Finally, I think it is worth stating that if Bitcoin adopts a culture where
a willfully ignorant set of people can block changes that have no impact on
them, despite a large constituency wanting those changes, then Bitcoin kind
of deserves the slow deterioration that will result from that. I don't
really find that future appealing and so I think that trying to find ways
to activate non-invasive changes should be everyone's goal, *even if* they
personally may not have an immediate use case, or have a slight preference
for alternate solutions. The exception to this is any introduction of
systemic risk. Not all soft-forks are equal, and therefore the
meta-consensus requirements for getting them activated should vary based on
how broadly consequential the change is.

Feel free to resist this if you want. In some sense that's what the Speedy
Trial procedure is for. However, I think your case would be more compelling
if you actually had some sort of affirmative argument for why CTV induces
systemic risk to non-users of the opcode. Expressing uncertainty over
whether it is the globally optimal 

Re: [bitcoin-dev] On the regularity of soft forks

[Keagan McClelland via bitcoin-dev]

>  But whether or not it is a basic principle of general software
engineering kind of misses the point. Security critical software clearly
isn't engineered in the same way as a new social media app. Bugs are easily
reverted in a new social media app.On top of that we aren't just dealing
with security critical software. One of the most important objectives is to
keep all the nodes on the network in consensus. Introducing a consensus
change before we are comfortable there is community consensus for it is a
massive effective bug in itself. The network can split in multiple ways
e.g. part of the network disagrees on whether to activate the consensus
change, part of the network disagrees on how to resist that consensus
change, part of the network disagrees on how to activate that consensus
change etc

>  A consensus change is extremely hard to revert and probably requires a
hard fork, a level of central coordination we generally attempt to avoid
and a speed of deployment that we also attempt to avoid.

This seems to assert the idea that soft forks are all the same: they are
not. For instance a soft fork, lowering the block subsidy is completely
different than changing the semantics of an OP_NOP to have semantics that
may reject a subset of the witnesses that attest to the transactions
permissibility. As a result, reversion means two entirely different things
in these contexts. While a strict reversion of both soft forks is by
definition a hard fork, the requirement of reversion as a result of
undesired behavior is not the same. In the case of opcodes, there is almost
never a requirement to revert it. If you don't like the way the opcodes
behave, then you just don't use them. If you don't like the reduction of
the block subsidy, well that's a much bigger problem.

I make this point to elucidate the idea that we cannot treat SoftForks™ as
a single monolithic idea. Perhaps we need to come up with better
terminology to be specific about what each fork actually is. The soft vs.
hard distinction is a critical one but it is not enough and treating soft
forks that are noninvasive such as OP_NOP tightenings. This has been
proposed before [1], and while I do not necessarily think the terms cited
are necessarily complete, they admit the low resolution of our current
terminology.

> Soft fork features can (and should) obviously be tested thoroughly on
testnet, signet, custom signets, sidechains etc on a standalone basis and a
bundled basis.

I vehemently disagree that any consensus changes should be bundled,
especially when it comes to activation parameters. When we start to bundle
things, we amplify the community resources needed to do review, not reduce
them. I suspect your opinion here is largely informed by your frustration
with the Taproot Activation procedure that you underwent earlier this year.
This is understandable. However, let me present the alternative case. If we
start to bundle features, the review of the features gets significantly
harder. As the Bitcoin project scales, the ability of any one developer to
understand the entire codebase declines. Bundling changes reduces the
number of people who are qualified to review a particular proposal, and
even worse, intimidates people who may be willing and able to review
logically distinct portions of the proposal, resulting in lower amounts of
review overall. This will likely have the opposite effect of what you seem
to desire. BIP8 and BIP9 give us the ability to have multiple independent
soft forks in flight at once. Choosing to bundle them instead makes little
sense when we do not have to. Bundling them will inevitably degenerate into
political horse trading and everyone will be worse off for it.

> part of the network disagrees on whether to activate the consensus
change, part of the network disagrees on how to resist that consensus
change, part of the network disagrees on how to activate that consensus
change etc

Disagreements, and by extension, forks are a part of Bitcoin. What is
important is that they are well defined and clean. This is the reason why
the mandatory signaling period exists in BIP8/9, so that clients that
intend to reject the soft fork change have a very easy means of doing so in
a clean break where consensus is clearly divergent. In accordance with
this, consensus changes should be sequenced so that people can decide which
sides of the forks they want to follow and that the economic reality can
reorganize around that. If choose to bundle them, you have one of two
outcomes: either consensus atomizes into a mist where people have different
ideas of which subsets of a soft fork bundle they want to adopt, or what
likely comes after is a reconvergence on the old client with none of the
soft fork rules in place. This will lead to significantly more confusion as
well given that with sufficient miner consensus some of the rules may stick
anyway even if the rest of the user base reconverges on the old client.

It is quite likely less damaging to 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Keagan McClelland via bitcoin-dev]

> That is in fact true of Proof of Work as well. If a colluding coalition
of miners with more than 50% of the hashrate want to censor transactions,
they absolutely can do that by orphaning blocks that contain transactions
they want to censor. This is not different in proof of stake.

This power does not translate into them being able to block your
acquisition of hashpower itself, a property extremely different than in
proof of stake.

On Wed, Jun 23, 2021 at 6:14 PM Billy Tetrud  wrote:

> >  This is not true in a Proof of Work system and this difference
> absolutely should not be trivialized.
>
> That is in fact true of Proof of Work as well. If a colluding coalition of
> miners with more than 50% of the hashrate want to censor transactions, they
> absolutely can do that by orphaning blocks that contain transactions
> they want to censor. This is not different in proof of stake.
>
> On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland <
> keagan.mcclell...@gmail.com> wrote:
>
>> > Premise: There is a healthy exchange market for PoS Coin X with tens of
>> thousands of participants bidding to buy and sell the coin for other
>> currencies on the market.
>>
>> The difference here though is that Proof of Stake allows the quorum of
>> coin holders to block the exchange of said coins if they are going to a
>> particular destination. Nothing requires these staking nodes to include
>> particular transactions into a block. With that in mind, it isn't just that
>> you require the permission of the person who sold you the coins, which I
>> can agree is a less dangerous form of permission, but you must also require
>> the permission of at least 51% of the coin holders to even receive those
>> coins in the first place. This is not true in a Proof of Work system and
>> this difference absolutely should not be trivialized.
>>
>> Keagan
>>
>> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> >  Barrier to entry in PoS is being given permission by the previous
>>> owner of a token
>>>
>>> The idea that proof of stake is not permissionless is completely
>>> invalid. It pains me to see such an argument here. Perhaps we can come to
>>> an agreement by being more specific. I'd like to propose the following:
>>>
>>> Premise: There is a healthy exchange market for PoS Coin X with tens of
>>> thousands of participants bidding to buy and sell the coin for other
>>> currencies on the market.
>>>
>>> If the premise above is true, then there is no significant permission
>>> needed to enter the market for minting blocks for PoS Coin X. If you make a
>>> bid on someone's coins and they don't like you and refuse, you can move on
>>> to any one of the other tens of thousands of people in that marketplace.
>>> Would you agree, Cloud Strife, that this situation couldn't be considered
>>> "permissioned"?
>>>
>>> If not, consider that participation in *any* decentralized system
>>> requires the permission of at least one user in that system. If there are
>>> thousands of bitcoin public nodes, you require the permission of at least
>>> one of them to participate in bitcoin. No one considers bitcoin
>>> "permissioned" because of this. Do you agree?
>>>
>>> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Barrier to entry in PoW is matter for hardware and energy is
 permissionless and exist all over the universe, permissionless cost which
 exists for everyone no matter who because it's unforgeable.

 Barrier to entry in PoS is being given permission by the previous owner
 of a token for you to have it via transfer or sale, both choices they never
 have to make since there are no continuous costs with producing blocks
 forcing it. A permission is an infinitely high barrier to entry if the
 previous owner, like the premining party, refuses to give up the token they
 control.

 You're skipping the part where you depend on a permission of a central
 party in control of the authority token before you can produce blocks on
 your rasberry Pi.

 Proof of stake is not in any possible way relevant to permissionless
 protocols, and thus not possibly relevant to decentralized protocols where
 control must be distributed to independent (i.e. permissionless) parties.

 There's nothing of relevance to discuss and this has been figured out
 long long ago.


 https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy


 https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca




 On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> @Lloyd wrote:
>
> Of course in reality no one wants to keep their coin holding keys
>> online so in Alogorand you can authorize a set 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Keagan McClelland via bitcoin-dev]

> Premise: There is a healthy exchange market for PoS Coin X with tens of
thousands of participants bidding to buy and sell the coin for other
currencies on the market.

The difference here though is that Proof of Stake allows the quorum of coin
holders to block the exchange of said coins if they are going to a
particular destination. Nothing requires these staking nodes to include
particular transactions into a block. With that in mind, it isn't just that
you require the permission of the person who sold you the coins, which I
can agree is a less dangerous form of permission, but you must also require
the permission of at least 51% of the coin holders to even receive those
coins in the first place. This is not true in a Proof of Work system and
this difference absolutely should not be trivialized.

Keagan

On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  Barrier to entry in PoS is being given permission by the previous owner
> of a token
>
> The idea that proof of stake is not permissionless is completely invalid.
> It pains me to see such an argument here. Perhaps we can come to an
> agreement by being more specific. I'd like to propose the following:
>
> Premise: There is a healthy exchange market for PoS Coin X with tens of
> thousands of participants bidding to buy and sell the coin for other
> currencies on the market.
>
> If the premise above is true, then there is no significant permission
> needed to enter the market for minting blocks for PoS Coin X. If you make a
> bid on someone's coins and they don't like you and refuse, you can move on
> to any one of the other tens of thousands of people in that marketplace.
> Would you agree, Cloud Strife, that this situation couldn't be considered
> "permissioned"?
>
> If not, consider that participation in *any* decentralized system requires
> the permission of at least one user in that system. If there are thousands
> of bitcoin public nodes, you require the permission of at least one of them
> to participate in bitcoin. No one considers bitcoin "permissioned" because
> of this. Do you agree?
>
> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Barrier to entry in PoW is matter for hardware and energy is
>> permissionless and exist all over the universe, permissionless cost which
>> exists for everyone no matter who because it's unforgeable.
>>
>> Barrier to entry in PoS is being given permission by the previous owner
>> of a token for you to have it via transfer or sale, both choices they never
>> have to make since there are no continuous costs with producing blocks
>> forcing it. A permission is an infinitely high barrier to entry if the
>> previous owner, like the premining party, refuses to give up the token they
>> control.
>>
>> You're skipping the part where you depend on a permission of a central
>> party in control of the authority token before you can produce blocks on
>> your rasberry Pi.
>>
>> Proof of stake is not in any possible way relevant to permissionless
>> protocols, and thus not possibly relevant to decentralized protocols where
>> control must be distributed to independent (i.e. permissionless) parties.
>>
>> There's nothing of relevance to discuss and this has been figured out
>> long long ago.
>>
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>>
>>
>> https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca
>>
>>
>>
>>
>> On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> @Lloyd wrote:
>>>
>>> Of course in reality no one wants to keep their coin holding keys online
 so in Alogorand you can authorize a set of "participation keys"[1] that
 will be used to create blocks on your coin holding key's behalf.
 Hopefully you've spotted the problem.
 You can send your participation keys to any malicious party with a nice
 website (see random example [2]) offering you a good return.
 Damn it's still Proof-of-SquareSpace!

>>>
>>> I believe we are talking about a comparison to PoW, correct? If you want
>>> to mine PoW, you need to buy expensive hardware and configure it to work,
>>> and wait a long time to get any return by solo mining. Or you can join a
>>> mining pool, which might use your hashing power for nefarious purposes. Or
>>> you might skip the hardware all together and fall for some "cloud mining"
>>> scheme with a pretty website and a high rate of advertised return. So as
>>> you can see, Proof-of-SquareSpace exists in PoW as well!
>>>
>>> The PoS equivalent of buying mining hardware is setting up your own
>>> validator and not outsourcing that to anyone else. So both PoW and PoS have
>>> the professional/expert way of participating, and the fraud-prone, amateur
>>> way of participating. The only difference is, with PoS the
>>> 

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

[Keagan McClelland via bitcoin-dev]

>One needs a cost/benefit analysis, not just an account of the cost. For
example, if PoW could do calculations that are otherwise useful (maybe
solve a queue of standardized math-jobs, such as climate simulations) there
would be more benefit, or, let's say the data storage in proof-of-space is
useful.

Any discussion on whether Proof of Work is suitable for the task needs to
recognize that the "waste" is what creates the security. If you manage to
make the proof of work useful for tasks external to the protocol, you
reintroduce the "nothing at stake" problem in a roundabout way. Useful
computation is something people will pay for. If they pay for it, miners
can be compensated in such a way that choosing to mine one of the
Not-The-Heaviest-Chain's becomes costless. This erodes the security of the
network substantially. It is not a matter of coming up with the "right"
kind of useful computation that is not subject to these problems. These
problems are a natural consequence of it being useful outside the protocol
*at all*.

Keagan

On Tue, May 18, 2021 at 8:24 AM Claus Ehrenberg via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Ultimately all currency security derives from energy consumption.
> > Everything eventually resolves down to proof-of-work.
> This is ideology. Yes, without energy and work, not many things happen.
> But the amounts of energy and work to achieve a goal vary widely. Detailed
> analysis comparing one alternative with the other in depth  is required.
> And I would not look for order-of-magnitude improvements, 25% better is
> also a big deal, if discovered.
>
> > * Proof-of-space simply moves the work to the construction of more
> storage devices.
> One needs a cost/benefit analysis, not just an account of the cost. For
> example, if PoW could do calculations that are otherwise useful (maybe
> solve a queue of standardized math-jobs, such as climate simulations) there
> would be more benefit, or, let's say the data storage in proof-of-space is
> useful.
>
> > * Proof-of-stake simply moves the work to stake-grinding attacks.
> Simply not true, there are PoS implementations that are immune to
> stake-grinding attacks, and even where not, the possible amount of
> computations is limited compared to PoW
>
> > * The optical proof-of-work simply moves the work to the construction of
> more miners.
> The idea was to shift from energy to cap-ex. We can get a
> financial penalty for misbehavior from three sources:
> - cost of energy/labor (PoW)
> - cost of capital (PoS)
> - cost of cap-ex
> There might be a better mix than PoW only. I have written code for mixed
> PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense,
> but the environmental impact needs to be analyzed, it could also make it
> worse than just the use of electricity. At least electricity as such does
> not leave waste behind. Mining in orbit with solar power would be totally
> acceptable.
>
> > At least, proof-of-work is honest about its consumption of resources.
> Agreed, but we can't be satisfied with that. If we try hard enough we can
> do better.
>
> Cheers
> Claus
>
> On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> > A few things jump out at me as I read this proposal
>> >
>> > First, deriving the hardness from capex as opposed to opex switches the
>> privilege from those who have cheap electricity to those who have access to
>> chip manufacturers/foundries. While this is similarly the case for Bitcoin
>> ASICS today, the longevity of the PoW algorithm has led to a better
>> distribution of knowledge and capital goods required to create ASICS. The
>> creation of a new PoW of any kind, hurts this dimension of decentralization
>> as we would have to start over from scratch on the best way to build,
>> distribute, and operate these new pieces of hardware at scale. While I have
>> not combed over the PoW proposed here in fine detail, the more complicated
>> the algorithm is, the more it privileges those with specific knowledge
>> about it and the manufacturing process.
>> >
>> > The competitive nature of Bitcoin mining is such that miners will be
>> willing to spend up to their expected mining reward in their operating
>> costs to continue to mine. Let's suppose that this new PoW was adopted,
>> miners will continue to buy these chips in ever increasing quantities,
>> turning the aforementioned CAPEX into a de facto OPEX. This has a few
>> consequences. First it just pushes the energy consumption upstream to the
>> chip manufacturing process, rather than eliminating it. And it may trade
>> some marginal amount of the energy consumption for the set of resources it
>> takes to educate and create chip manufacturers. The only way to avoid that
>> cost being funneled back into more energy consumption is to make the
>> barrier to understanding of the manufacturing process sufficiently
>> difficult so as to limit the proliferation 

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

[Keagan McClelland via bitcoin-dev]

A few things jump out at me as I read this proposal

First, deriving the hardness from capex as opposed to opex switches the
privilege from those who have cheap electricity to those who have access to
chip manufacturers/foundries. While this is similarly the case for Bitcoin
ASICS today, the longevity of the PoW algorithm has led to a better
distribution of knowledge and capital goods required to create ASICS. The
creation of a new PoW of any kind, hurts this dimension of decentralization
as we would have to start over from scratch on the best way to build,
distribute, and operate these new pieces of hardware at scale. While I have
not combed over the PoW proposed here in fine detail, the more complicated
the algorithm is, the more it privileges those with specific knowledge
about it and the manufacturing process.

The competitive nature of Bitcoin mining is such that miners will be
willing to spend up to their expected mining reward in their operating
costs to continue to mine. Let's suppose that this new PoW was adopted,
miners will continue to buy these chips in ever increasing quantities,
turning the aforementioned CAPEX into a de facto OPEX. This has a few
consequences. First it just pushes the energy consumption upstream to the
chip manufacturing process, rather than eliminating it. And it may trade
some marginal amount of the energy consumption for the set of resources it
takes to educate and create chip manufacturers. The only way to avoid that
cost being funneled back into more energy consumption is to make the
barrier to understanding of the manufacturing process sufficiently
difficult so as to limit the proliferation of these chips. Again, this
privileges the chip manufacturers as well as those with close access to the
chip manufacturers.

As far as I can tell, the only thing this proposal actually does is create
a very lucrative business model for those who sell this variety of chips.
Any other effects of it are transient, and in all likelihood the transient
effects create serious centralization pressure.

At the end of the day, the energy consumption is foundational to the
system. The only way to do away with authorities, is to require
competition. This competition will employ ever more resources until it is
unprofitable to do so. At the base of all resources of society is energy.
You get high energy expenditure, or a privileged class of bitcoin
administrators: pick one. I suspect you'll find the vast majority of
Bitcoin users to be in the camp of the energy expenditure, since if we pick
the latter, we might as well just pack it in and give up on the Bitcoin
experiment.

Keagan

On Mon, May 17, 2021 at 2:33 PM Bogdan Penkovsky via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Devs,
>
> We would like to share with you a draft proposal for a durable, low
> energy Bitcoin proof of work.
>
> 
>
> 
>   BIP: ?
>   Title: Durable, Low Energy Bitcoin PoW
>   Author: Michael Dubrovsky , Bogdan Penkovsky
> 
>   Discussions-To: 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/PoWx-Org/obtc/wiki/BIP
>   Status: Draft
>   Type: Standards Track
>   Created: 2021-05-13
>   License: BSD-2-Clause
>OPL
> 
>
>
> == Simple Summary ==
>
> Bitcoin's energy consumption is growing with its value (see Figure below).
> Although scaling PoW is necessary to maintain the security of the network,
> reliance on massive energy consumption has scaling drawbacks and leads to
> mining
> centralization. A major consequence of the central role of local
> electricity
> cost in mining is that today, most existing and potential participants in
> the
> Bitcoin network cannot profitably mine Bitcoin even if they have the
> capital to
> invest in mining hardware. From a practical perspective, Bitcoin adoption
> by
> companies like Tesla (which recently rescinded its acceptance of Bitcoin as
> payment) has been hampered by its massive energy consumption and perceived
> environmental impact.
>
> [[https://github.com/PoWx-Org/obtc/raw/main/img/btc_energy-small.png]]
>
> Figure. Bitcoin price and estimated Bitcoin energy consumption.
> Data sources: [https://cbeci.org Cambridge Bitcoin Electricity
> Consumption Index], [https://www.coindesk.com CoinDesk].
>
> We propose a novel proof-of-work paradigm for Bitcoin--Optical
> proof-of-work. It
> is designed to decouple Bitcoin mining from energy and make it feasible
> outside
> of regions with low electricity costs. ''Optical proof-of-work'' (oPoW) is
> a
> modification of Hashcash that is most efficiently computed using a new
> class of
> photonic processors. Without compromising the cryptographic or
> game-theoretical
> security of Hashcash, oPoW shifts the operating expenses of mining (OPEX),
> to
> capital expenses (CAPEX)--i.e. electricity to hardware. oPoW makes it
> possible
> for billions of new miners to enter the market simply by investing in a
> low-energy photonic miner. Shifting to a high-CAPEX PoW has the 

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

[Keagan McClelland via bitcoin-dev]

In principle the idea of making your transactions not mineable except by
miners who follow some particular practice is something that can and should
be discussed. For instance, it could help give economic signals for future
soft forks such that users can declare preference in a costly, sybil
resistant way.

As I understand what you are asking, you want users to be able to issue
transactions that can only be included in blocks that are signed by miners
whose certificates can be traced back to some set of certificates that the
sender has "whitelisted". The trouble here is that in order for this to be
an open system, the user would need to be able to include an unbounded
number of optional certificates in the transaction itself, otherwise the
rest of the network would be unable to validate whether or not the
transaction, when included in the block fit the consensus rules or not.

This is not possible for rather obvious reasons:
1. transaction sizes cannot be allowed to be unbounded because this creates
denial of service attacks for the broader network
2. if the valid certificate set is not unbounded, then centralization
pressure will mount on the bound between the Nth and N+1th certifier.

Finally, all of this would require a rather large consensus change to even
implement. Given how contentious the proposal of a "choose your
miner/certifier" is, it is unlikely to gain the necessary support in the
form of code, review, miner signaling, or user uptake for a UASF.

That said, not all is lost. If you truly care about only having your
transactions mined by "green" miners or whatever other qualification you
are going after, then this can likely be implemented in upper layers as you
suggested. You can submit your transaction via an overlay network directly
to any miners that fit your criteria. Since miners operate in a selfish
way, it is not in their interest to share your transaction with other
miners, and the probable case is that your transaction will only be
included in a block that is signed by your preferred authority.

I should note though, that you may be waiting forever for your transactions
to be mined and your business partners might choose not to do business with
you in the future due to delays caused by virtue signaling to nocoiners.

> Please don't be dismissive, it is an open forum and everybody is entitled
to his/her/its own opinion.

It is, in fact, an open forum and everyone is entitled to their view,
including being dismissive of yours.

> I respectfully submit that people who know how to launch rockets to the
sky and beam high-speed internet from the satellites to every place on
earth are at least capable of understanding how Bitcoin works. There is
even an english expression which reads 'it is not a rocket science' which I
think fits especially nicely in this particular case :)

No one is contesting that Elon and the rest of the technical staff at Tesla
are *capable* of understanding Bitcoin. We are just asserting that, at
present, they do not understand the underlying mechanics well enough to
give consistent rationale for their choices, and because their public
statements reveal either a deep hypocrisy, or deep ignorance in their
understanding of Bitcoin.

Keagan

On Mon, May 17, 2021 at 8:11 AM Anton Ragin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello, list
>
> >Hello centralisation. Might as well just have someone sign miner keys,
> and get
> >rid of PoW entirely...
> >No, it is not centralization -
>
> No, it is not centralization, as:
>
> (a) different miners could use different standards / certifications for
> 'green' status, there are many already;
>
>
> >> That does not refute the claim at all. Just because you can choose from
> multiple centralized authorities, which are well known and can collude, it
> does not mean it is decentralized by any reasonable definition of the term.
>
> (b) it does not affect stability of the network in a material way, rather
> creates small (12.5% of revenue max) incentive to move to green sources of
> energy (or buy carbon credits) and get certified - miners who would choose
> to run dirty energy will still be able to do so.
> and
>
>
> >> Who is to issue these credits? A centralized entity I guess ... There
> is no place for such in Bitcoin.
>
> If I am to concede on the point that *voluntarily* green-status miner
> certification is 'centralization', can you please explain *in detail* why
> aren't 'bitcoin.org' and GitHub repo similar examples of
> 'centralization'? You make a correct point that bitcoin.org and the
> GitHub repo are not 'official' things of Bitcoin network, however nowhere
> in my proposals on green miner certification I was suggesting to introduce
> an 'official' certificate for such a thing. May be I mis-formulated my
> ideas, in that case I apologize:
>
> The only thing which I suggested was to introduce an option to have some
> transactions encrypted in the mempool to allow Bitcoin users some control
> 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Keagan McClelland via bitcoin-dev]

To reiterate some of the points here. My problem with proof of stake is
twofold.

1. It requires permission of coin holders to enter into the system. This is
not true of proof of work. You may even attempt (though not successfully) a
proof of work with pencil and paper and submit the block from a regular
laptop if you so choose. Whether this level of permissionlessness is
necessary is up to individual risk tolerance etc. but it is definitely the
default preference of Bitcoin.

2. Proof of stake must have a trusted means of timestamping to regulate
overproduction of blocks. This introduction of trust is generally
considered to be a nonstarter in Bitcoin. Proof of Work regulates this by
making blocks fundamentally difficult to produce in the first place.

Like Jeremy, I’m always interested to learn about new attempts in consensus
algorithms, but the bar to clear is very high and proof of stake to date
has not proposed much less demonstrated a set of properties that is
consistent with Bitcoins objectives.

Keagan

On Mon, May 10, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> personally, not speaking for anyone else, i think that proof-of-burn
> has a much higher likelihood of being a) good enough security and b)
> solving the nothing-at-stake problem
>
>  the only issue i see with a quality PoB implementation is a robust
> solution to the block-timing problem.
>
> https://grisha.org/blog/2018/01/23/explaining-proof-of-work/
>
> i do think there *could* be other low-energy solutions to verifiable
> timing, just haven't seen one
>
>
> On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
>  wrote:
> >
> > Hello list,
> >
> > I am a lurker here and like many of you I worry about the energy usage
> of bitcoin mining. I understand a lot mining happens with renewable
> resources but the impact is still high.
> >
> > I want to get your opinion on implementing proof of stake for bitcoin
> mining in future. For now, proof of stake is still untested and not battle
> tested like proof of work. Though someday it will be.
> >
> > In the following years we'll be seeing proof of stake being implemented.
> Smaller networks can test PoS which is a luxury bitcoin can't afford.
> Here's how I see this the possibilities:
> >
> > 1 - Proof of stake isn't a good enough security mechanism
> > 2 - Proof of state is a good security mechanism and works as intended
> >
> > IF PoS turns out to be good after battle testing, would you consider
> implementing it for Bitcoin? I understand this would invoke a lot of
> controversies and a hard fork that no one likes. But its important enough
> to consider a hard fork. What are your opinions provided PoS does work?
> >
> > Love from India.
> > ___
> > 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] Taproot NACK

[Keagan McClelland via bitcoin-dev]

LORD HIS EXCELLENCY,

This isn't different with Taproot either. When you spend a P2SH output you
reveal the script. In Taproot you reveal the portion of the script that is
relevant to allowing you to spend it. There is no value to specifying the
other possible conditions that could have moved the coins because, after
all, you aren't invoking those clauses to move the coins. I am showing you
my fingertip, and pointing to my finger tip, the palm is not relevant.

Keagan

On Wed, Mar 10, 2021 at 2:11 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev  wrote:

> Good Afternoon,
>
> You cannot liken the ability to scrutinise the public ledger to be the
> same as hiding information, it is like showing your palm while you are
> pointing at the back of your hand. The advice that I have is P2SH is
> scrutable once the UTXO is spent. Also, there is no public ledger
> obfuscation in creating new addresses, there is a plausible reduction in
> transaction linkage.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this
> email if misdelivered.
> --
> *From:* bitcoin-dev  on
> behalf of Ryan Grant via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 6 March 2021 1:04 AM
> *To:* Bitcoin Protocol Discussion 
> *Subject:* Re: [bitcoin-dev] Taproot NACK
>
> On Thu, Mar 4, 2021 at 8:48 PM LORD HIS EXCELLENCY JAMES HRMH via
> bitcoin-dev  wrote:
> > My concern was that the more complex scripts allow obfuscation of the
> Pay To address
>
> This is no different from options available in P2SH, or from the
> obfuscation achieved by generating a new address for a payment.
> ___
> 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] Taproot activation proposal "Speedy Trial"

[Keagan McClelland via bitcoin-dev]

The assumption of malice on the part of those of us supporting a UASF is
tragic and frankly ridiculous. Many of us backed off of the effort the
second that this Speedy Trial solution was proposed in order to dislodge
the gridlock on the LOT value. I can't say for certain that 100% of those
working towards a UASF will abandon the effort but I can say for certain
that a good portion of the would be contributors to Bitcoin Activation have
already said that they would switch over to this Speedy Trial if it
actually materialized.

Given that the opposition towards the UASF to begin with was to not assume
malice out of miners I would expect that the same good will be extended to
those who were supporting a LOT=true client in good faith *given that Core
already said they wouldn't ship any activation code at all.*

Keagan

On Sat, Mar 6, 2021 at 1:49 PM Ariel Luaces via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoin-dev
>  wrote:
> >
> > I'm really unsure that three months is a short enough time window that
> there wouldn't be a material effort to split the
> > network with divergent consensus rules. Instead, a three month window is
> certainly long enough to organize and make a
> > lot of noise around such an effort, given BIP 148 was organized and
> reached its peak within a similar such window.
> >
> > Worse, because the obvious alternative after a three month activation
> failure is a significant delay prior to
> > activation, the vocal UASF minority may be encouraged to pursue such a
> route to avoid such a delay.
> >
>
> I agree with your concern, a three month window motivates a small
> group to constantly tell people to upgrade as soon as possible. Which
> is mostly fine, but if this group gets near 51% mining support in the
> three months it will embolden them to switch the messaging from
> "upgrade the client" to "run this new client that has the LOT flag
> switched to true" (UASF)
> This marketing group will attempt a UASF regardless of the timelines
> because there is no cost if they fail a UASF and there is great reward
> if they succeed by activating in 3 months. They can run an alt-node,
> scare everyone else of being reorged, pretend they have a majority,
> and say their chain is the safe one. I say there is no cost because
> the leaders of that movement are likely savvy enough to give up the
> effort and move back to running core even after the chain split. The
> ones who get hurt are the followers of the UASF movement that don't
> fully understand the discussion and drink the kool aid.
> A short time window doesn't preclude this group from attempting a UASF.
>
> > One alternative may be to reduce the signaling windows involved and
> start slightly later. Instead of the likelihood of
> > failure growing on the horizon, simply have two signaling windows (maybe
> two weeks, maybe a moth each?). In order to
> > ensure success remains likely, begin them somewhat later after software
> release to give pools and miners a chance to
> > configure their mining software in advance.
> >
> > Matt
>
> The shorter the signaling windows the more unlikely they are to reach
> a mining power supermajority.
> With a short signaling window the supermajority threshold will
> probably be configured to low levels (80% 70% 60%). Which makes the
> activation period dangerous because it forces the other miners (20%
> 30% 40%) to upgrade really suddenly once the threshold is reached.
> Unless the LOCKED_IN period is made really long (1 year) but then we
> have to wait a really long time.
> As long as the mining power running the soft fork is above 50% the
> chain will stay together. Anything above that is just a safety margin
> to prevent orphan blocks.
>
> So why not encode this 50%+ dynamic into the activation logic.
> Spread the deployment window out to a year, make the activation
> threshold 95%, and at the end of the window the feature can activate
> if there is above 51% signaling.
> By definition, the activation will happen if either 95% is reached
> early or if at the end of the deployment window mining support is
> between 51% and 95%. With this setup the chain is guaranteed to stay
> together and no need to rush miners and users.
>
> Cheers
> Ariel Lorenzo-Luaces
>
> >
> > On 3/5/21 22:43, 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 

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Keagan McClelland via bitcoin-dev]

> A large portion of BTC is already mined through AWS servers and non-asic
specific hardware anyways. A majority of them would benefit from a hybrid
proof, and the fact that it is hybrid in that manner wouldn't
disenfranchise currently optimized mining entities as well.

My instincts tell me that this is an outlandish claim. Do you have
supporting evidence for this?

Keagan

On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Actually I mentioned a proof of space and time hybrid which is much
> different than staking. Sorry to draw for the confusion as PoC is more
> commonly used then PoST.
> There is a way to make PoC cryptographically compatible w/ Proof of Work
> as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
> It has rarely been done though given the technological complexity of being
> both CPU compatible and memory-hard compatible. There are lots of benefits
> outside of the realm of efficiency, and I already looked into numerous
> fault tolerant designs as well and what others in the cryptography
> community attempted to propose. The actual argument you have only against
> this is the Proof of Memory fallacy, which is only partially true. Given
> how the current hashing algorithm works, hard memory allocation wouldn't be
> of much benefit given it is more optimized for CPU/ASIC specific mining.
> I'm working towards a hybrid mechanism that fixes that. BTW: The way
> Bitcoin currently stands in its cryptography still needs updating
> regardless. If someone figures out NP hardness or the halting problem the
> traditional rule of millions of years to break all of Bitcoin's
> cryptography now comes down to minutes. Bitcoin is going to have to
> eventually radically upgrade their cryptography and hashing algo in the
> future regardless. I want to integrate some form of NP complexity in
> regards to the hybrid cryptography I'm aiming to provide which includes a
> polynomial time algorithm in the cryptography. More than likely the first
> version of my BTC hard fork will be coded in a way where integrating such
> complexity in the future only requires a soft fork or minor upgrade to its
> chain.
>
> In regards to the argument, "As a separate issue, proposing a hard fork in
> the hashing algorithm will invalidate the enormous amount of capital
> expenditure by mining entities and disincentivize future capital
> expenditure into mining hardware that may compute these more "useful"
> proofs of work."
>
> A large portion of BTC is already mined through AWS servers and non-asic
> specific hardware anyways. A majority of them would benefit from a hybrid
> proof, and the fact that it is hybrid in that manner wouldn't
> disenfranchise currently optimized mining entities as well.
>
> There are other reasons why a cryptography upgrade like this is
> beneficial. Theoretically one can argue BItcoin isn't fully decentralized.
> It is few unsolved mathematical proofs away from being entirely broken. My
> goal outside of efficiency is to build cryptography in a way that prevents
> such an event from happening in the future, if it was to ever happen. I
> have various research in regards to this area and work alot with
> distributed computing. I believe if the BTC community likes such a
> proposal, I would single handedly be able to build the cryptographic proof
> myself (though would like as many open source contributors as I can get :)
>
> Anyways just something to consider. We are in the same space in regards to
> what warrants a shitcoin or the whole argument against staking.
>
> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl
>
> Best regards,  Andrew
>
> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <
> keagan.mcclell...@gmail.com> wrote:
>
>> It is important to understand that it is critical for the work to be
>> "useless" in order for the security model to be the same. If the work was
>> useful it provides an avenue for actors to have nothing at stake when
>> submitting a proof of work, since the marginal cost of block construction
>> will be lessened by the fact that the work was useful in a different
>> context and therefore would have been done anyway. This actually degrades
>> the security of the network in the process.
>>
>> As a separate issue, proposing a hard fork in the hashing algorithm will
>> invalidate the enormous amount of capital expenditure by mining entities
>> and disincentivize future capital expenditure into mining hardware that may
>> compute these more "useful" proofs of work. This is because any change in
>> the POW algorithm will be considered unstable and subject to change in the
>> future. This puts the entire network at even more risk meaning that no
>> entity is tying their own interests to that of the bitcoin network at
>> large. It also puts the developers in a position where they can be bribed
>> by entities with a vested interest in 

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

[Keagan McClelland via bitcoin-dev]

It is important to understand that it is critical for the work to be
"useless" in order for the security model to be the same. If the work was
useful it provides an avenue for actors to have nothing at stake when
submitting a proof of work, since the marginal cost of block construction
will be lessened by the fact that the work was useful in a different
context and therefore would have been done anyway. This actually degrades
the security of the network in the process.

As a separate issue, proposing a hard fork in the hashing algorithm will
invalidate the enormous amount of capital expenditure by mining entities
and disincentivize future capital expenditure into mining hardware that may
compute these more "useful" proofs of work. This is because any change in
the POW algorithm will be considered unstable and subject to change in the
future. This puts the entire network at even more risk meaning that no
entity is tying their own interests to that of the bitcoin network at
large. It also puts the developers in a position where they can be bribed
by entities with a vested interest in deciding what the new "useful" proof
of work should be.

All of these things make the Bitcoin network worse off.

Keagan

On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Also in regards to my other email, I forgot to iterate that my
> cryptography proposal helps behind the efficiency category but also tackles
> problems such as NP-Completeness or Halting which is something the BTC
> network could be vulnerable to in the future. For sake of simplicity, I do
> want to do this BIP because it tackles lots of the issues in regards to
> this manner and can provide useful insight to the community. If things such
> as bigger block height have been proposed as hard forks, I feel at the very
> least an upgrade regarding the hashing algorithm and cryptography does at
> least warrant some discussion. Anyways I hope I can send you my BIP, just
> let me know on the preferred format?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <
> loneroassociat...@gmail.com> wrote:
>
>> Hi, this isn't about the energy efficient argument in regards to
>> renewables or mining devices but a better cryptography layer to get the
>> most out of your hashing for validation. I do understand the arbitrariness
>> of it, but do want to still propose a document. Do I use the Media Wiki
>> format on GitHub and just attach it as my proposal?
>>
>> Best regards, Andrew
>>
>> On Fri, Mar 5, 2021, 10:07 AM Devrandom 
>> wrote:
>>
>>> Hi Ryan and Andrew,
>>>
>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>

   https://www.truthcoin.info/blog/pow-cheapest/
 "Nothing is Cheaper than Proof of Work"
 on | 04 Aug 2015


>>> Just to belabor this a bit, the paper demonstrates that the mining
>>> market will tend to expend resources equivalent to miner reward.  It does
>>> not prove that mining work has to expend *energy* as a primary cost.
>>>
>>> Some might argue that energy expenditure has negative externalities and
>>> that we should move to other resources.  I would argue that the negative
>>> externalities will go away soon because of the move to renewables, so the
>>> point is likely moot.
>>>
>>> ___
> 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 the case for flag day activation of taproot

[Keagan McClelland via bitcoin-dev]

As one of the folks that prefers LOT=true I can certainly attest to the
fact that at least some of us would be willing to do a flag day activation
instead. As far as I'm concerned, flag day does not give a very small
percentage of the user base (5-10% of minerz) the ability to veto a change
that has broad support and is non-invasive.

However, I must question the incongruence between those who oppose LOT=true
and support a possible flag day activation. In my mind, all that LOT=true
does is concatenate a flag day activation after a LOT=false deployment,
where, as Russell noted, activation is an idempotent operation.

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.

More generally, I want to remind everyone that this is a change everyone
supports (so far). So letting the activation method kill the proposal
altogether would be tragic. If those with specific objections to various
activation methods can be clear about what those objections are, and, even
better, suggest small adjustments to various proposals on those grounds, I
think we have a far more optimistic path forward on getting Taproot
activated. Bitcoin may not have voting, but it certainly can have
compromise to come to consensus on these things. I don't think anyone in
the UASF crowd is impatient with respect to the actual guaranteed
activation timeline, what I get the sense of is a burnout on the arguments,
paired with no action. To the degree that we can make progress on coming to
an agreement that makes people comfortable, even if you don't get
everything you want, I think.

Keagan

On Thu, Mar 4, 2021 at 11:04 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Appologies as I've rearranged your comments in my reply.
>
> On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo 
> wrote:
>
>>
>> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>>
> > After a normal and successful Core update with LOT=false, we will have
>> more data showing broad community support for the
>> > taproot upgrade in hand.
>>
>> I think this is one of the strongest arguments against a flag day
>> activation, but, as I described in more detail in the
>> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
>> aren't there enough already.
>>
>
> I agree with you.  I also think we have plenty of evidence to proceed with
> taproot and could proceed with a PR for such a flag day activation.  If
> there is support for it to be merged, that would be fantastic.  I think we
> should proceed along these lines forthwith.
>
> However, the existence and/or release of a flag day activation code does
> not in of itself preclude concurrently developing and/or releasing a BIP8
> LOT=false deployment.  Activating taproot is "idempotent" after all. We
> could even do a Core release with a flag day activation while we continue
> to discuss BIP8 LOT=false if that gets the ball rolling.  Certainly having
> a flag day activation code merged would take a lot of pressure off further
> BIP8 LOT=false work.
>
> As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL
> state, then running BIP8 LOT=false alongside a flag day activation at
> timeout may be the way to go.  Once a flag day deployment is released, the
> LOT=true people would have their guaranteed activation and would be less
> interested in an alternative client. And without a MUST_SIGNAL state, I
> believe the LOT=false deployment won't lead any hashpower that is following
> standardness rules to create invalid blocks.
>
>
>> > In the next release, 6 months later or so, Core could then confidently
>> deploy a BIP8 LOT=true
>>
>> Could you clarify what an acceptable timeline is, then? Six months from
>> release of new consensus rules to activation (in
>> the case of a one-year original window) seems incredibly agressive for a
>> flag-day activation, let alone one with
>> forced-signaling, which would require significantly higher level of
>> adoption to avoid network split risk. In such a
>> world, we'd probably get Taproot faster with a flag day from day one.
>>
>
> Whatever timeline people are in favour of.  I think having a year or more
> between the LOT=true or flag day more and the anticipated second release
> date is fair myself.
> That would suggest a 2-year timeout from the start to give plenty of room.
>
> Of course, if we start with a flag day from the start then we can just do
> 1 year and we don't need a second deployment.
>
> We could also do a "Let’s see what happens" with a short 3 or 4-month
> deployment and still do a follow up activation if that is more agreeable.
> That would give a net of about 1.5 years or so because we don't need to
> anticipate the second relase date.
>
> I'm good with whatever, and I'm happy to make more concrete suggestions if
> that is necessary.  I think there exist 

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

[Keagan McClelland via bitcoin-dev]

> Personally I consider this counterproductive. Apart from the complexity,
it’s not healthy. And the chain grows linearly with storage cost falling
exponentially, leading to a straightforward conclusion.

The motivation for this change is not to encourage full archival nodes to
prune, but to make it possible for pruned nodes to beef up what kind of
archive they retain. Personally I think using the falling storage costs as
a means of providing access to more users is more important than using it
to justify requiring higher node requirements.

> Something to consider adding to this proposal is to keep the idea of
pruning - i.e. retain a sequentially uninterrupted number of the most
recent blocks.
>
> Many users do not run a node for entirely altruistic reasons - they do
so, at least in part, because it allows them to use their wallets
privately. Without this ability, I think the number of users willing to run
their node in this configuration might be reduced.
>
> Another related thought is to have a decreasing density over blocks over
time as you go backwards towards genesis, in order for the data density of
the storage to match the actual usage of the network, in which (I would
imagine) more recent blocks are more heavily requested than early ones.

Per my above comments, this change is actually capitalizing primarily upon
those who wish to do it for more altruistic reasons. Furthermore, doing
linear block scans when you need to query blocks that you don't keep does
not leak privacy details in the same way that bloom filters do. You are not
signaling to the peer that there is something specific in that block that
you care about, because you don't actually know. You are signalling only
that you do not have that block right now, which from the other parts of
the design you are already leaking. In light of this, I don't think that it
is necessary for the blocks to be in sequential sets at all. If there is no
requirement on them being sequential, uniform randomness will take care of
the density problem automatically.

Keagan


On Mon, Mar 1, 2021 at 4:20 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>
> > Only headers need to be downloaded sequentially so downloading relevant
> blocks from one node is totally possible with gaps in between.
>
>
>
> In fact this is exactly how libbitcoin v4 works. We download and store
> blocks in parallel. In the case of a restart block gaps are repopulated.
> Given that headers are validated, we go after the most responsive nodes.
> Based on standard deviation, we drop the slowest peers and rebalance load
> to new/empty channels. We make ordered but not necessarily sequential
> requests. There is no distinction between “initial” block download, a
> restart, or a single or few blocks at the top. So it’s referred to as
> continuous parallel block download.
>
>
>
> But we don’t prune. Personally I consider this counterproductive. Apart
> from the complexity, it’s not healthy. And the chain grows linearly with
> storage cost falling exponentially, leading to a straightforward conclusion.
>
>
>
> e
> ___
> 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] A design for Probabilistic Partial Pruning

[Keagan McClelland via bitcoin-dev]

Hi all,

I've been thinking for quite some time about the problem of pruned nodes
and ongoing storage costs for full nodes. One of the things that strikes me
as odd is that we only really have two settings.

A. Prune everything except the most recent blocks, down to the cache size
B. Keep everything since genesis

>From my observations and conversations with various folks in the community,
they would like to be able to run a "partially" pruned node to help bear
the load of bootstrapping other nodes and helping with data redundancy in
the network, but would prefer to not dedicate hundreds of Gigabytes of
storage space to the cause.

This led me to the idea that a node could randomly prune some of the blocks
from history if it passed some predicate. A rough sketch of this would look
as follows.

1. At node startup, it would generate a random seed, this would be unique
to the node but not necessary that it be cryptographically secure.
2. In the node configuration it would also carry a "threshold" expressed as
some percentage of blocks it wanted to keep.
3. As IBD occurs, based off of the threshold, the block hash, and the
node's unique seed, the node would either decide to prune the data or keep
it. The uniqueness of the node's hash should ensure that no block is
systematically overrepresented in the set of nodes choosing this storage
scheme.
4. Once the node's IBD is complete it would advertise this as a peer
service, advertising its seed and threshold, so that nodes could
deterministically deduce which of its peers had which blocks.

The goals are to increase data redundancy in a way that more uniformly
shares the load across nodes, alleviating some of the pressure of full
archive nodes on the IBD problem. I am working on a draft BIP for this
proposal but figured I would submit it as a high level idea in case anyone
had any feedback on the initial design before I go into specification
levels of detail.

If you have thoughts on

A. The protocol design itself
B. The barriers to put this kind of functionality into Core

I would love to hear from you,

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Keagan McClelland via bitcoin-dev]

I wanted to follow up on what Jeremy and others are saying regards finding
consensus on LOT. I've seen a few other opinions saying that finding
consensus on the LOT value is far more important than what the LOT value
actually is. This makes sense because if 100% of economic activity is
running the same rule set, there is no divergence, regardless of which
value is picked.

It is my understanding that those who oppose LOT=true are mostly opposed on
the grounds of it *appearing* "unnecessarily coercive" and that this lack
of consensus can precipitate a chain split at the "brinksmanship period" as
Jeremy refers to it. I don't think that we can say that LOT=true is
coercive at all unless there is some opposition to Taproot itself.
Opposition on the grounds that it *may* be opposed by others and Core does
not want to assert control over the protocol is a conservative view but
ultimately contingent upon opposition to Taproot for more fundamental
reasons. If no one opposes it, then by definition you have consensus, and
in that case I also don't think that the LOT=true (or false) in that regard
sets meaningful precedent, as I would expect precedents to only be
meaningful if they were established during a contentious scenario. As it
stands we have precedents for both MASF's and UASF's to execute soft forks
in Bitcoin.

Of course it seems intractable to ascertain the views of ~100% of the
Bitcoin constituency, and therefore it gives credibility to the argument
that by coming to consensus on LOT=false among those who *are* speaking up
is safer with the embedded assumptions that modifying consensus beyond what
core ships is an active choice, presumably by those who know what they are
doing. However, the simple act of Core choosing to ship an unconfigurable
LOT=false value does not *prevent* the forking and creation of a UASF
client. As Jeremy points out, the LOT=true possibility always exists here,
and we have multiple high profile people saying they will be running that
regardless of how things turn out. It seems to me that in this scenario,
LOT=false does less to prevent a chain split.

In regards to precedent, there may be good reasons to force that minority
to fork themselves off the network, as would be the case if a hypothetical
soft fork was a consensus action to blacklist some UTXO's or something else
that weaponizes consensus against some subset of Bitcoin's user base, but I
haven't heard a single person who advocates for LOT=false on the grounds
that they *themselves* oppose the consensus change that is being proposed
here. So if the goal is to prevent a chain split, and the soft fork is
benign and essentially "annexing unoccupied territory" with respect to
script versions, and no one actually has opposed Taproot itself, then I
fail to see how LOT=false is safer in the presence of a grenade defense by
the LOT=true crowd.

I personally *prefer* LOT=true for these reasons, but I am NOT going to be
joining the ranks of the intolerant minority if Core ultimately ships
LOT=false. I think it is more important to stay in consensus, and as a
result I am able to be convinced that false is the right answer. My
question to everyone else (true AND false advocates) is this: what would
you have to observe, in order to change your mind or is it immutably made
up? If we have a significant portion of the community that is immutably
made up to go false, and another portion that is going to go true, the
asymmetry of the fork almost *requires* that those of us whose opinions are
malleable to break for true.

If social consensus is what drives technical consensus and not the other
way around it seems as if there cannot exist a valid (rational?) reason to
oppose Taproot itself, and then by extension with the arguments laid out
above, LOT=true seems to be the logical conclusion of all of this, even if
Core ships LOT=false at the outset.

Where am I wrong here?

Keagan

On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not responding to anyone in particular, but it strikes me that one can
> think about the case where a small minority (let's say H = 20%?) of nodes
> select the opposite of what Core releases (LOT=false, LOT=true). I'm
> ignoring the case where a critical bug is discovered in Taproot for reasons
> I could expand on if anyone is interested (I don't think LOT=true/false has
> much of a diff in that regard).
>
> You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes
> are clearly updated (or lying), LOT=false nodes may be un-upgraded (or
> however you want to interpret it).
>
>
> *# 80% on LOT=false, 20% LOT=True*
>
> - Case 1: Activates ahead of time anyways
>
> No issues.
>
> - Case 2: Fails to Activate before timeout...
>
> 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of
> multi block reorgs at time of fork relatively high, especially if network
> does not partition.
>
> Implication is that activation % being 90%, then X% 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Keagan McClelland via bitcoin-dev]

Hi all,

I think it's important for us to consider what is actually being considered
for activation here.

The designation of "soft fork" is accurate but I don't think it adequately
conveys how non-intrusive a change like this is. All that taproot does
(unless I'm completely missing something) is imbue a previously undefined
script version with actual semantics. In order for a chain reorg to take
place it would mean that someone would have to have a use case for that
script version today. This is something I think that we can easily check by
digging through the UTXO set or history. If anyone is using that script
version, we absolutely should not be using it, but that doesn't mean that
we can't switch to a script version that no one is actually using.

If no one is even attempting to use the script version, then the change has
no effect on whether a chain split occurs because there is simply no block
that contains a transaction that only some of the network will accept.

Furthermore, I don't know how Bitcoin can stand the test of time if we
allow developers who rely on "undefined behavior" (which the taproot script
version presently is) to exert tremendous influence over what code does or
does not get run. This isn't a soft fork that makes some particular UTXO's
unspendable. It isn't one that bans miners from collecting fees. It is a
change that means that certain "always accept" transactions actually have
real conditions you have to meet. I can't imagine a less intrusive change.

On the other hand, choosing to let L=F be a somewhat final call sets a very
real precedent that 10% of what I estimate to be 1% of bitcoin users can
effectively block any change from here on forward. At that point we are
saying that miners are in control of network consensus in ways they have
not been up until now. I don't think this is a more desirable outcome to
let ~0.1% of the network get to block *non-intrusive* changes that the rest
of the network wants.

I can certainly live with an L=F attempt as a way to punt on the
discussion, maybe the activation happens and this will all be fine. But if
it doesn't, I hardly think that users of Bitcoin are just going to be like
"well, guess that's it for Taproot". I have no idea what ensues at that
point, but probably another community led UASF movement.

I wasn't super well educated on this stuff back in '17 when Segwit went
down, as I was new at that time, so if I'm missing something please say so.
But from my point of view, we can't treat all soft forks as equal.

Keagan

On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We've had several softforks in Bitcoin which, through the course of their
> activation, had a several-block reorg. That
> should be indication enough that we need to very carefully consider
> activation to ensure we reduce the risk of that as
> much as absolutely possible. Again, while I think Taproot is a huge
> improvement and am looking forward to being able to
> use it, getting unlucky and hitting a 4-block reorg that happens to
> include a double-spend and some PR around an
> exchange losing millions would be worse than having Taproot is good.
>
> Matt
>
> On 2/18/21 09:26, Michael Folkson wrote:
> > Thanks for your response Matt. It is a fair challenge. There is always
> going to be an element of risk with soft forks,
> > all we can do is attempt to minimize that risk. I would argue that risk
> has been minimized for Taproot.
> >
> > You know (better than I do in fact) that Bitcoin (and layers built on
> top of it) greatly benefit from upgrades such as
> > Taproot. To say we shouldn't do Taproot or any future soft forks because
> there is a small but real risk of chain splits
> > I think is shortsighted. Indeed I think even if we collectively decided
> not to do any future soft fork upgrades ever
> > again on this mailing list that wouldn't stop soft fork attempts from
> other people in future.
> >
> > I don't think there is anything else we can do to minimize that risk for
> the Taproot soft fork at this point though I'm
> > open to ideas. To reiterate that risk will never be zero. I don't think
> I see Bitcoin as fragile as you seem to (though
> > admittedly you have a much better understanding than me of what happened
> in 2017).
> >
> > The likely scenario for the Taproot soft fork is LOT turns out to be
> entirely irrelevant and miners activate Taproot
> > before it becomes relevant. And even the unlikely worst case scenario
> would only cause short term disruption and
> > wouldn't kill Bitcoin long term.
> >
> > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo  > wrote:
> >
> > If the eventual outcome is that different implementations (that have
> material *transaction processing* userbases,
> > and I’m not sure to what extent that’s true with Knots) ship
> different consensus rules, we should stop here and not
> > activate Taproot. Seriously.
> >
> >   

Re: [bitcoin-dev] bip48 proposal

[Keagan McClelland via bitcoin-dev]

I was just looking into the conventions around this yesterday! It seems
like this proposal is mostly just formalizing stuff that is already a tacit
standard. I'm glad to see that someone is documenting it somewhere more
"official".

It appears consistent with https://github.com/bitcoin/bips/pull/253, However,
due to historical timing, the PR you linked doesn't include any standards
around segwit conventions.

In the review thread you had mentioned that you needed an ACK from prusnak,
but he explicitly gave a NACK in favor of a separate proposal for BIP 48,
which seems like it could be something like the OP. Reading the proposal it
seems consistent with the pull request that you linked, as well. At the end
of the thread the author of PR#253 said they would open a separate
proposal, but it appears that it never materialized. Was there a reason for
this?

Keagan

On Wed, Dec 16, 2020 at 10:17 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> BIP number 48 has not been assigned. Do not self-assign BIP numbers.
>
> Is this intended to be compatible with
> https://github.com/bitcoin/bips/pull/253 ?
>
> Luke
>
>
>
> On Wednesday 16 December 2020 14:10:28 dentondevelopment via bitcoin-dev
> wrote:
> > Here is the repo instead of a static link:
> > https://github.com/Fonta1n3/bips/blob/master/bip-0048.mediawiki
> >
> > Fontaine
> >
> > Sent with [ProtonMail](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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Keagan McClelland via bitcoin-dev]

> It should be therefore a top priority to make the UX of connecting my
mobile LN client to my home full node extremely easy, so that centralised
services can't improve much on that step. Especially if I already run a
full node.

For what it's worth, this is a main research area for us at Start9 Labs.

> Could someone briefly describe how this UX looks currently? And if it's
not as seamless as it could, what blockers are there?

At the root of all of these problems is that a "private server" is
considered inconvenient. There is no fundamental reason this has to be the
case. The main UX challenges we've found are around installation and
configuration of server applications, not to mention, that users don't have
an existing mental model for how to imagine applications. Most people who
do not work on computers for a living have heard of servers but their
firsthand experience with software is "apps". The fact that there is a
component of their applications that runs remotely on computers they don't
own.

So in short:
1. Educating on the distinction between client and server apps is an open
question whose burden will likely fall on the entire industry if we want to
get this right and not have an exchange takeover of Bitcoin.
2. Apps that either require "zero configuration" or have very easy in-app
walkthroughs of the bare essentials of configuration
3. GUI style installs of server applications familiar to those who have
installed desktop or mobile software.

I'm sure there are more things we'll learn as we grow but these are the top
three observations we've made and this is our primary area of work.

> Private full nodes serving headers to a handful of weak devices have been
mentioned many times as a good solution against all sorts of problems in a
future full of LN + SPV nodes. I agree.

This is the main thesis I've been going on for a while. Once your full node
has synced the whole blockchain and the total set of headers is known, you
don't actually even need to carry 100% of the block data, as you can
re-fetch a needed block from elsewhere and verify the block data matches
the header you've already checked for consensus. From there the header
chain can serve as base truth for a whole set of L2+ services or L1 SPV
wallets. Ideally, in a model like this, more expensive peer services would
be authenticated so that your other applications could get the data they
need without exposing your full node to the extra costs of those who are
not running their own nodes. Typically we've used Core's RPC API for this
but as others have mentioned upthread JSON is a wasteful format and there
are good reasons that you'd want Lightning to be able to request peer
services without necessarily having ownership control over the node.

The other thing I wanted to note is the fact that the issue isn't that
Lightning does SPV, the issue is around whether or not the node it is
tethered to is *actually* trusted since SPV necessarily trusts some
dimensions of the information supplied to it. Doing SPV against a full node
you own is no more dangerous than indexing watch only addresses in Core and
then asking for wallet/utxo information over RPC.

Keagan

On Thu, May 14, 2020 at 12:50 AM Orfeas Stefanos Thyfronitis Litos <
o.thyfroni...@ed.ac.uk> wrote:

>
>
> >If everyone runs such a privately-owned server, on the other hand, this
> >is not so different from having a Lightning node you run at your home
> >that has a fullnode as well and which you access via a remote control
> >mobile device, and it is the inconvenience of having such a server at
> >your home that prevents this in the first place.
>
> Private full nodes serving headers to a handful of weak devices have been
> mentioned many times as a good solution against all sorts of problems in a
> future full of LN + SPV nodes. I agree. It should be therefore a top
> priority to make the UX of connecting my mobile LN client to my home full
> node extremely easy, so that centralised services can't improve much on
> that step. Especially if I already run a full node.
>
> Could someone briefly describe how this UX looks currently? And if it's
> not as seamless as it could, what blockers are there?
>
> Best,
> Orfeas
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> ___
> Lightning-dev mailing list
> lightning-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Keagan McClelland via bitcoin-dev]

> The RPC interface in Bitcoin Core, and others, is not great for this
> because it exposes a lot of functionality that isn't necessary and
> introduces risks.

This is actually somewhat my point. If the RPC interface was good for this
and *didn't* introduce risks, we could just use that and be done with it.
But I'm finding there are many use cases that you want to have low cost
ways to serve peer services to people whom you have given explicit
permission, but they shouldn't have full ability to administrate the node.

Perhaps I wasn't explicit in my previous note but what I mean is that there
seems to be a demand for something *in between* a peer interface, and an
owner interface. I have little opinion as to whether this belongs in core
or not, I think there are much more experienced folks who can weight in on
that, but without something like this, you cannot limit your exposure for
serving something like bip157 filters without removing your own ability to
make use of some of those same services.

Keagan

On Fri, May 8, 2020 at 1:51 PM Braydon Fuller  wrote:

> On 5/6/20 9:07 PM, Keagan McClelland wrote:
>
> > I think that one of the solutions here is to have light clients choose
> > their full node tethers explicitly. Even if you think it is unrealistic
> to
> > have everyone run their own node (fwiw, I don’t), there is still a trust
> > model where you can pick your trusted source.
> >
> > This way you could have many light clients working off of a family node,
> > and the peer services could be limited to some sort of “authenticated”
> > peers. Perhaps this is better accomplished over the RPC interface in
> Core,
> > but the idea is to have some sort of peer service model between “full
> > public” and “owner only”. This limits the amount of costs that can be
> > properly externalized, without exposing risk of consensus capture by
> > economically weighty institutions.
>
> The RPC interface in Bitcoin Core, and others, is not great for this
> because it exposes a lot of functionality that isn't necessary and
> introduces risks. For example the `gettxoutsetinfo` can start a very
> intensive CPU and disk I/O task. There are several others, for example:
> `stop`, `addnode`, `clearbanned`, `setban`, and etc. Furthermore reading
> full raw blocks isn't very efficient with JSON. Electrum servers (e.g
> electrs) for example read blocks from disk instead and use the RPC
> interface to sync headers. Though, Electrum servers also have a risk of
> DoS with addresses that have many transactions, see the `--txid-limit`
> option [2].
>
> [1]:
>
> https://github.com/bitcoin/bitcoin/blob/5b24f6084ede92d0f493ff416b4726245140b2c1/src/rpc/blockchain.cpp#L954-L956
> [2]:
>
> https://github.com/romanz/electrs/blob/f0a7a325af495ecbc152c0866550dc300011779b/src/query.rs#L284-L289
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Keagan McClelland via bitcoin-dev]

I think that one of the solutions here is to have light clients choose
their full node tethers explicitly. Even if you think it is unrealistic to
have everyone run their own node (fwiw, I don’t), there is still a trust
model where you can pick your trusted source.

This way you could have many light clients working off of a family node,
and the peer services could be limited to some sort of “authenticated”
peers. Perhaps this is better accomplished over the RPC interface in Core,
but the idea is to have some sort of peer service model between “full
public” and “owner only”. This limits the amount of costs that can be
properly externalized, without exposing risk of consensus capture by
economically weighty institutions.

Keagan

On Wed, May 6, 2020 at 9:56 PM Antoine Riard 
wrote:

> What I'm thinking more is if the costs of security are being too much
> externalized from the light clients onto full nodes, nodes operators are
> just going to stop servicing light clients `peercfilters=false`. The
> backbone p2p network is going to be fine. But the massive LN light clients
> network built on top is going to rely on centralized services for its chain
> access and now you may have consensus capture by those..
>
> Le mer. 6 mai 2020 à 12:00, Keagan McClelland 
> a écrit :
>
>> Hi Antoine,
>>
>> Consensus capture by miners isn't the only concern here. Consensus
>> capture by any subset of users whose interests diverge from the overall
>> consensus is equally damaging. The scenario I can imagine here is that the
>> more light clients outpace full nodes, the more the costs of security are
>> being externalized from the light clients onto the full nodes. In this
>> situation, it can make full nodes harder to run. If they are harder to run
>> it will price out some marginal set of full node operators, which causes a
>> net new increase in light clients (as the disaffected full nodes convert),
>> AND a redistribution of load onto a smaller surface area. This is a
>> naturally unstable process. It is safe to say that as node counts drop, the
>> set of node operators will increasingly represent economic actors with
>> extreme weight. The more this process unfolds, the more likely their
>> interests will diverge from the population at large, and also the more
>> likely they can be coerced into behavior they otherwise wouldn't. After all
>> it is easier to find agents who carry lots of economic weight. This is true
>> independent of their mining status, we should be just as wary of consensus
>> capture by exchanges or HNWI's as we are about miners.
>>
>> Keagan
>>
>> On Wed, May 6, 2020 at 3:06 AM Antoine Riard 
>> wrote:
>>
>>> I do see the consensus capture argument by miners but in reality isn't
>>> this attack scenario have a lot of assumptions on topology an deployment ?
>>>
>>> For such attack to succeed you need miners nodes to be connected to
>>> clients to feed directly the invalid headers and if these ones are
>>> connected to headers/filters gateways, themselves doing full-nodes
>>> validation invalid chain is going to be sanitized out ?
>>>
>>> Sure now you trust these gateways, but if you have multiple connections
>>> to them and can guarantee they aren't run by the same entity, that maybe an
>>> acceptable security model, depending of staked amount and your
>>> expectations. I more concerned of having a lot of them and being
>>> diversified enough to avoid collusion between gateways/chain access
>>> providers/miners.
>>>
>>> But even if you light clients is directly connected to the backbone
>>> network and may be reached by miners you can implement fork anomalies
>>> detection and from then you may have multiples options:
>>> * halt the wallet, wait for human intervention
>>> * fallback connection to a trusted server, authoritative on your chain
>>> view
>>> * invalidity proofs?
>>>
>>> Now I agree you need a wide-enough, sane backbone network to build on
>>> top, and we should foster node adoption as much as we can.
>>>
>>> Le mar. 5 mai 2020 à 09:01, Luke Dashjr  a écrit :
>>>
 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" 

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

[Keagan McClelland via bitcoin-dev]

Hi Antoine,

Consensus capture by miners isn't the only concern here. Consensus capture
by any subset of users whose interests diverge from the overall consensus
is equally damaging. The scenario I can imagine here is that the more light
clients outpace full nodes, the more the costs of security are being
externalized from the light clients onto the full nodes. In this situation,
it can make full nodes harder to run. If they are harder to run it will
price out some marginal set of full node operators, which causes a net new
increase in light clients (as the disaffected full nodes convert), AND a
redistribution of load onto a smaller surface area. This is a naturally
unstable process. It is safe to say that as node counts drop, the set of
node operators will increasingly represent economic actors with extreme
weight. The more this process unfolds, the more likely their interests will
diverge from the population at large, and also the more likely they can be
coerced into behavior they otherwise wouldn't. After all it is easier to
find agents who carry lots of economic weight. This is true independent of
their mining status, we should be just as wary of consensus capture by
exchanges or HNWI's as we are about miners.

Keagan

On Wed, May 6, 2020 at 3:06 AM Antoine Riard 
wrote:

> I do see the consensus capture argument by miners but in reality isn't
> this attack scenario have a lot of assumptions on topology an deployment ?
>
> For such attack to succeed you need miners nodes to be connected to
> clients to feed directly the invalid headers and if these ones are
> connected to headers/filters gateways, themselves doing full-nodes
> validation invalid chain is going to be sanitized out ?
>
> Sure now you trust these gateways, but if you have multiple connections to
> them and can guarantee they aren't run by the same entity, that maybe an
> acceptable security model, depending of staked amount and your
> expectations. I more concerned of having a lot of them and being
> diversified enough to avoid collusion between gateways/chain access
> providers/miners.
>
> But even if you light clients is directly connected to the backbone
> network and may be reached by miners you can implement fork anomalies
> detection and from then you may have multiples options:
> * halt the wallet, wait for human intervention
> * fallback connection to a trusted server, authoritative on your chain view
> * invalidity proofs?
>
> Now I agree you need a wide-enough, sane backbone network to build on top,
> and we should foster node adoption as much as we can.
>
> Le mar. 5 mai 2020 à 09:01, Luke Dashjr  a écrit :
>
>> 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
>>
> ___
> Lightning-dev mailing list
> lightning-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev