Nostr notes by

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

2023-08-02T10:19:22Z

In reply to nevent1q…r7ry
_________________________

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

Cheers,
Keags

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

> I don't think it's anyone's place to judge which types of transactions
> should be allowed or not on the network, in fact, when it comes to privacy
> and censorship resistance, it would be better if we were not even able to
> distinguish different types of transactions from one another in the first
> place.
>
> We have limited resources on the blockchain and so they should go to the
> highest bidder. This is already how the network functions and how it
> ensures it's security.
>
> Rather than thinking about this as "spam", I think it's useful to
> objectively think about it in terms of value to the marketplace (fees
> they're willing to pay) against cost to the network (storage consumed). It
> comes down to supply and demand.
>
> If the rate of growth of the blockchain is too high, Ordinals aren't the
> cause, it's rather that the theoretical limit of the amount of storage that
> can be added per block isn't sufficiently limited. (Whether they are used
> to produce Ordinals or something else)
>
>
>
> On Sun, Jul 30, 2023, 5:51 PM , <
> bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev at lists.linuxfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> or, via email, send a message with subject or body 'help' to
>> bitcoin-dev-request at lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-owner at lists.linuxfoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Concern about "Inscriptions". (rot13maxi)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 30 Jul 2023 18:34:12 +0000
>> From: rot13maxi <rot13maxi at protonmail.com>
>> To: L?o Haf <leohaf at orangepill.ovh>, "vjudeu at gazeta.pl"
>> <vjudeu at gazeta.pl>
>> Cc: Bitcoin Protocol Discussion
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
>> Message-ID:
>>
>> <RIqguuebFmAhEDqCY_0T8KRqHBXEfcvPw6-MbDIyWsAWpLenFFeOVx88-068QFZr7xowg-6Zg988HsRCKdswtZC6QUKPXnrTyTAc_l5jphg=@
>> protonmail.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello,
>>
>> > This cat and mouse game can be won by bitcoin defenders. Why ? Because
>> it is easier to detect these transactions and make them a standardization
>> rule than to create new types of spam transactions.
>>
>> One of the things discussed during the mempoolfullrbf discussion is that
>> a small (~10%) of nodes willing to relay a class of transaction is enough
>> for that class of transaction to consistently reach miners. That means you
>> would need to get nearly the entire network to run updated relay policy to
>> prevent inscriptions from trivially reaching miners and being included in
>> blocks. Inscription users have shown that they are willing and able to send
>> non-standard transactions to miners out of band (
>> https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
>> so even if you managed to get enough of the network running the new rule to
>> prevent propagation to miners, those users can just go out of band. Or,
>> they can simply change the script that is used to embed an inscription in
>> the transaction witness. For example, instead of 0 OP_IF?, maybe they do 0
>> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect this, they
>> have to update the rule and wait for 90%
>> + of the network to upgrade. When the pro-inscription people see this,
>> they only have to convince other inscription enthusiasts and businesses to
>> update.
>>
>> The anti-inscription patch has to be run by many more participants (most
>> of whom don?t care), while the pro-inscription update has to be run by a
>> small number of people who care a lot. It?s a losing battle for the
>> anti-inscription people.
>>
>> If you want to prevent inscriptions, the best answer we know of today is
>> economic: the cost of the blockspace needs to be more expensive than
>> inscribers are willing to pay, either because its too expensive or because
>> there?s no market demand for inscriptions. The former relies on Bitcoin
>> becoming more useful to more people, the latter is the natural course of
>> collectibles.
>>
>> > Finally, I would like to quote satoshi himself who wrote about spam
>> here is the link:
>> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>>
>> Appeals to Satoshi are not compelling arguments.
>>
>> Cheers,
>> Rijndael
>>
>> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via bitcoin-dev <[
>> bitcoin-dev at lists.linuxfoundation.org](mailto:On Sun, Jul 30, 2023 at
>> 2:04 PM, L?o Haf via bitcoin-dev <<a href=)> wrote:
>>
>> > ?According to you, the rules of standardization are useless but in this
>> case why were they introduced? The opreturn limit can be circumvented by
>> miners, yet it is rare to see any, the same for maxancestorcount,
>> minrelayfee or even the dust limit.
>> >
>> > This cat and mouse game can be won by bitcoin defenders. Why ? Because
>> it is easier to detect these transactions and make them a standardization
>> rule than to create new types of spam transactions.
>> >
>> > As for the default policy, it can be a weakness but also a strength
>> because if the patch is integrated into Bitcoin Core by being activated by
>> default, the patch will become more and more effective as the nodes update.
>> >
>> > Also, when it came to using a pre-segwit node, it is not a solution
>> because this type of node cannot initiate new ones, which is obviously a
>> big problem.
>> >
>> > Finally, I would like to quote satoshi himself who wrote about spam
>> here is the link:
>> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>> >
>> >> Le 27 juil. 2023 ? 07:10, vjudeu at gazeta.pl a ?crit :
>> >
>> >>
>> >
>> >> ?
>> >
>> >>> not taking action against these inscription could be interpreted by
>> spammers as tacit acceptance of their practice.
>> >
>> >>
>> >
>> >> Note that some people, even on this mailing list, do not consider
>> Ordinals as spam:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html
>> >
>> >>
>> >
>> >> See? It was discussed when it started. Some people believe that
>> blocking Ordinals is censorship, and could lead to blocking regular
>> transactions in the future, just based on other criteria. That means, even
>> if developers would create some official version with that option, then
>> some people would not follow them, or even block Ordinals-filtering nodes,
>> exactly as described in the linked thread:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html
>> >
>> >>
>> >
>> >>> as spammers might perceive that the Bitcoin network tolerates this
>> kind of behavior
>> >
>> >>
>> >
>> >> But it is true, you have the whole pages, where you can find images,
>> files, or other data, that was pushed on-chain long before Ordinals. The
>> whole whitepaper was uploaded just on 1-of-3 multisig outputs, see
>> transaction
>> 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You have
>> the whole altcoins that are connected to Bitcoin by using part of the
>> Bitcoin's UTXO set as their database.
>> >
>> >>
>> >
>> >> That means, as long as you won't solve IBD problem and UTXO set
>> growing problem, you will go nowhere, because if you block Ordinals
>> specifically, people won't learn "this is bad, don't do that", they could
>> read it as "use the old way instead", as long as you won't block all
>> possible ways. And doing that, requires for example creating new nodes,
>> without synchronizing non-consensus data, like it could be done in "assume
>> UTXO" model.
>> >
>> >>
>> >
>> >> Also note that as long as people use Taproot to upload a lot of data,
>> you can still turn off the witness, and become a pre-Segwit node. But if
>> you block those ways, then people will push data into legacy parts, and
>> then you will need more code to strip it correctly. The block 774628 maybe
>> contains almost 4 MB of data from the perspective of Segwit node, but the
>> legacy part is actually very small, so by turning witness off, you can
>> strip it to maybe just a few kilobytes.
>> >
>> >>
>> >
>> >>> I want to emphasize that my proposal does not involve implementing a
>> soft fork in any way. On the contrary, what I am asking is simply to
>> consider adding a standardization option. This option would allow the
>> community to freely decide whether it should be activated or not.
>> >
>> >>
>> >
>> >> 1. Without a soft-fork, those data will be pushed by mining pools
>> anyway, as it happened in the block 774628.
>> >
>> >> 2. Adding some settings won't help, as most people use the default
>> configuration. For example, people can configure their nodes to allow free
>> transactions, without recompiling anything. The same with disabling dust
>> amounts. But good luck finding a node in the wild that does anything
>> unusual.
>> >
>> >> 3. This patch produced by Luke Dashjr does not address all cases. You
>> could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used by Ordinals,
>> and easily bypass those restrictions. This will be just a cat and mouse
>> game, where spammers will even use P2PK, if they will be forced to. The
>> Pandora's box is already opened, that fix could be good for February or
>> March, but not now.
>> >
>> >>
>> >
>> >>
>> >
>> >>
>> >
>> >>> On 2023-07-26 11:47:09 user leohaf at orangepill.ovh wrote:
>> >
>> >>> I understand your point of view. However, inscription represent by
>> far the largest spam attack due to their ability to embed themselves in the
>> witness with a fee reduction.
>> >
>> >>
>> >
>> >> Unlike other methods, such as using the op_return field which could
>> also be used to spam the chain, the associated fees and the standardization
>> rule limiting op_return to 80 bytes have so far prevented similar abuses.
>> >
>> >>
>> >
>> >> Although attempting to stop inscription could lead to more serious
>> issues, not taking action against these inscription could be interpreted by
>> spammers as tacit acceptance of their practice. This could encourage more
>> similar spam attacks in the future, as spammers might perceive that the
>> Bitcoin network tolerates this kind of behavior.
>> >
>> >>
>> >
>> >> I want to emphasize that my proposal does not involve implementing a
>> soft fork in any way. On the contrary, what I am asking is simply to
>> consider adding a standardization option. This option would allow the
>> community to freely decide whether it should be activated or not.
>> >
>> >>
>> >
>> >>
>> >
>> >>>> Le 26 juil. 2023 ? 07:30, vjudeu at gazeta.pl a ?crit :
>> >
>> >>>> and I would like to understand why this problem has not been
>> addressed more seriously
>> >
>> >>> Because if nobody has any good solution, then status quo is
>> preserved. If tomorrow ECDSA would be broken, the default state of the
>> network would be "just do nothing", and every solution would be
>> backward-compatible with that approach. Burn old coins, and people will
>> call it "Tether", redistribute them, and people will call it "BSV". Leave
>> everything untouched, and the network will split into N parts, and then you
>> pick the strongest chain to decide, what should be done.
>> >
>> >>>> However, when it comes to inscriptions, there are no available
>> options except for a patch produced by Luke Dashjr.
>> >
>> >>> Because the real solution should address some different problem, that
>> was always there, and nobody knows, how to deal with it: the problem of
>> forever-growing initial blockchain download time, and forever-growing UTXO
>> set. Some changes with "assume UTXO" are trying to address just that, but
>> this code is not yet completed.
>> >
>> >>>> So, I wonder why there are no options to reject inscriptions in the
>> mempool of a node.
>> >
>> >>> Because it will lead you to never ending chase. You will block one
>> inscriptions, and different ones will be created. Now, they are present
>> even on chains, where there is no Taproot, or even Segwit. That means, if
>> you try to kill them, then they will be replaced by N regular
>> indistinguishable transactions, and then you will go back to those more
>> serious problems under the hood: IBD time, and UTXO size.
>> >
>> >>>> Inscriptions are primarily used to sell NFTs or Tokens, concepts
>> that the Bitcoin community has consistently rejected.
>> >
>> >>> The community also rejected things like sidechains, and they are
>> still present, just in a more centralized form. There are some unstoppable
>> concepts, for example soft-forks. You cannot stop a soft-fork. What
>> inscription creators did, is just non-enforced soft-fork. They believe
>> their rules are followed to the letter, but this is not the case, as you
>> can create a valid Bitcoin transaction, that will be some invalid Ordinals
>> transaction (because their additional rules are not enforced by miners and
>> nodes).
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> ------------------------------
>>
>> End of bitcoin-dev Digest, Vol 98, Issue 20
>> *******************************************
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230801/3e3a2496/attachment-0001.html>;

📅 Original date posted:2023-07-19 🗒️ Summary of this ...

2023-07-20T09:54:05Z

In reply to nevent1q…a3d6
_________________________

📅 Original date posted:2023-07-19
🗒️ Summary of this message: The author agrees that a smooth functioning Lightning Network is important, but believes that adding covenant schemes can help simplify LN development. They challenge the idea that covenants are a distraction and suggest that they can contribute to LN's maturity.
📝 Original message:
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 at 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
> comes with direct competition of my time to work on Lightning robustness.
> Getting my hands dirty on low-level LDK development recently made me
> realize we still have years of titan work to get a secure and reliable
> Lightning Network.
>
> As such, between extended covenant capabilities for advanced contracts
> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think
> the latter goal is more critical for Bitcoin existential survival, and
> where on a personal title I'll allocate the best of my time and energy (and
> somehow it match the "slow" technical activity on bitcoin-inquisition
> mostly done by Lightning hands).
>
> This is my personal conclusion only on the state of Bitcoin technological
> momentum, and this is quite tainted by my deep background in Lightning
> development. If you've been working on covenant changes proposals, please
> don't take it as a discouragement, I think Taproot (privacy-preserving
> script policies behind the taproot tree branches) and Schnorr (for native
> multi-sig) soft forks have shown how it can improve the building of
> self-custody solutions by one or two order of magnitude, and small
> incremental changes might be good enough to have a lower technical
> consensus bar.
>
> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
> better solutions with the interactivity issue and mass-compression of
> withdrawal and design exotic advanced Bitcoin contracts based on the
> taproot annex, though more in a "l'art pour l'art" approach for the time
> being [4]. Additionally, I might start to submit an in-depth security
> review of consensus changes under pseudonyms, it has already been done in
> the past and somehow it's good practice in terms of "message neutrality"
> [5]. If folks wanna experiment in terms of payment pools deployment, Greg
> Maxwell's old joinpool can be used today (and somehow it's worthy of its
> own as a net advance for coinjoins).
>
> I'll honestly acknowledge towards the community, I might have overpromised
> with the kickstart of this new process aiming to move the frontlines in
> matters of Bitcoin consensus changes development process. On the other
> hand, I think enough sessions of the working group have been runned and
> enough marks of technical interests have been collected to demonstrate the
> minimal value of such a process, so I would estimate my open-source balance
> sheet towards the community to be in good standing ? (open-minded question).
>
> I don't think Bitcoin fundamentally lacks compelling technical proposals
> to advance the capabilities of Bitcoin Script today, nor the crowd of
> seasoned and smart protocol developers to evaluate mature proposals
> end-to-end and on multiple dimensions with a spirit of independence.
> Rather, I believe what Bitcoin is lacking is a small crowd of technical
> historians and archivist doing the work of assessing, collecting and
> preserving consensus changes proposals and QA devs to ensure any consensus
> change proposals has world-class battle-ground testing before to be
> considered for deployment, ideally with the best standards of Bitcoin
> decentralization and FOSS neutrality [6].
>
> If you would like to pursue the maintenance and nurturing of the Bitcoin
> Contracting Primitives WG (or the bitcoin-inquisition fork or collaborate
> with Optech to organize industry-wise workshop on covenants at the image of
> what has been done in 2019 for Taproot), that you're willing to show
> proof-of-work and you estimate that operational ground, legal information
> or financial resources will anchor your individual work on the long-term,
> don't hesitate to reach out, I'll see what I can do with a disinterested
> mind [7].
>
> With humility,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
> remaining "Big Problems" is still pending on my visit to co-author Gleb
> Naumenko in Ukraine, which has been postponed few times in light of the
> conflict operational evolutions.
> [5] See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.
> For the philosophical reasons of doing so, I invite you to read Foucault's
> famous essay "Le philosophe masque".
> [6] Somehow I come to share Jeremy's thesis's "Product management is not
> "my Job" it's yours" in matters of consensus changes. I believe we might be
> past the technical complexity threshold where even simple consensus changes
> can be conducted from A to Z as a one man job or even by a group of 2/3
> elite devs.
> [7] I've been reached out multiple times and consistently by R&D
> non-profits, plebs whales and VC firms who were interested to commit
> resources to advance softforks and covenants in the Bitcoin space, no doubt
> when you're reliable and with a track record, folks are ready to offer you
> opportunities to work full-time on consensus changes.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230719/5dac7ac0/attachment.html>;

📅 Original date posted:2023-05-11 🗒️ Summary of this ...

2023-06-19T17:42:07Z

In reply to nevent1q…637q
_________________________

📅 Original date posted:2023-05-11
🗒️ Summary of this message: A message encourages Jorge to consider how his words will be read and understood by others on the mailing list. It suggests communicating in a way that recruits allies, seeks common ground, and demonstrates good faith to elicit greater sympathy and cooperation.
📝 Original message:
Jorge,

I invite you to consider reading your emails before you send them. During
this reread, I specifically encourage you to do so with the frame of mind
of how your words will be read and understood by others on this mailing
list.

The people on this list may have varying levels of familiarity with the
drama you are referencing. If we consider the technical dispositions and
the critical thinking capacity of the typical reader of this list, it is
overwhelmingly probable that someone reading your note is going to be
suspicious of your purely case due to the overt antagonism that is embedded
in every line. After reading your note, I am hard pressed to imagine that
anyone would come away from reading it with more sympathy for your
case, which I believe is the opposite of the intended outcome. If you wish
to affect change, should communicate in a way that recruits allies, seeks
common ground, and demonstrates good faith. Without that you will only
create more enemies, and feel like you are being "unfairly" victimized by
everyone you interact with here.

I am generally assuming that you are interested in getting people to see
things from your point of view and it pains me to see you further entrench
yourself in a situation that you clearly do not wish to be in. Realize that
you have the power to change this and elicit greater sympathy and
cooperation simply by taking greater care in seeing how your words get
understood by others.

Keags

On Thu, May 11, 2023 at 4:53 AM Jorge Timón <jtimon at jtimon.cc> wrote:

> Pressumption of innocence?
> Right to defend yourself?
>
> Wow, that sounds amazing, but, for example, wouldn't me defendibg myself
> from jeremy rubin be offtopic like...pretty much everywhere?
> Not sure you're familiar with that story, certainly you didn't hear my
> side of the story, did you?
> Where would it be fine for me to defend myself?
> I don't want to keep cosing bitcoin anymore, novody would review my PRs
> anyway once jeremy made sure everyone thought I am evil. Or perhaps I'm
> paranoid. Anyway, I would juat like to find the right venue to clean my
> name or at least be allowed to try. If that venue exists at all, that is.
>
> Personally, I feel extremely censored.
> I also feel I've been judged unfairly and margibalized by many.
> If it was because of my mistakes and not because jeremy and others lied
> about me behind my back, well, I would like to know at least.
>
> Am I really asking that much?
> I'm surprised at how very few people are in favor of the american first
> amendment, btw.
>
> I know, I know. Offtopic. Everywhere. Every time.
> If something it's offtopic everywhere, that's a censored taboo, I think.
>
> Therefore I challenge to a public debate somewhere. For me to defend
> myself and for him to defend himself too (if that's possible).
> I know it's never going to happen, but I want to make sure it is known
> that it is because of him, I'm more than ready to defend myself against
> him. Is he?
>
> He can call me a nazi and even though I'm not one (I'm not even racist),
> it is not so easy to sue for defamation in international jurisdictions.
> Imagine if I called him a pederast (kethuboth 11b, sanhesrin 69b) or a
> cannibal (samhedrin 64a) without giving him a chance to defend himself.
> Wouldn't that be nasty?
> I want him to be able to defend himself too, or at least try it.
>
> Now, moderators, censor this email for being offtopic and prove my point.
> Jeremy will still get the email and I bet he won't want a public debate.
> But I'm biased because I think he is guilty. Just like jeffrey epstein.
> Is jeremy rubin a mossad agent?
> Is there any reason to think so?
> Or are these just rummors?
> He should have a chance to try to clean his name, in my opinion. Again,
> just like jeffrey epstein.
>
> On Wed, May 10, 2023, 17:57 Antoine Riard <antoine.riard at gmail.com> wrote:
>
>> Hi Tony,
>>
>> > Is there a better place to have public communication? Unfortunately
>> since one off topic email was sent here, it's been a ghost town. It appears
>> that there's many emails being held and only one moderator that checks them
>> once a week.
>>
>> As I think you're referring to my post of March 21th and as the author of
>> this post, I'll politely refuse the qualification of "off-topic". I had and
>> I still have the concerns of "frivolous legal claims" being used between
>> bitcoin developers/organizations provoking a distortion of the neutrality
>> of the development and a chilling effect of the technical discussions (i.e
>> code we compile and spec we implement). For those reasons, it was my legal
>> right and moral duty to inform the community of what is happening between
>> Chaincode and myself. And here I'm following the recommendation of one of
>> the moderators of the Lightning mailing list himself "If this worries you
>> too, let's make sure we keep each other honest, OK?" [0].
>>
>> When you think a group of people with open-source responsibilities are in
>> a situation of conflict of interests or "moral hazards", or even the
>> appearance of them, you have the right to expose the wrongdoing, including
>> the _proportional_ revelation of private elements. People have done the
>> "free choice" to conduct a career in open-source, for some even declaring
>> in some context to maintain integrity and accept their actions to be
>> submitted to external accountability [1]. While the exposure of private
>> elements of public personalities might break common courtesy, it's a
>> morally valid practice if you're familiar with the public institutions of
>> US and Europe, and I think this practice has found validity in the history
>> of open-source commons or IETF's protocol development [1].
>>
>> Beyond, the Bitcoin and Lightning development communication channels
>> constitute a public forum, where by nature the participants are exchanging
>> ideas and defending competing interests. In consequence, the participants'
>> rights and capabilities to contribute and speak their minds in those
>> communication channels should be protected. Those communication channels
>> are not your usual corporate workplace, and in case of conflicting
>> principles, the maintainers of those communication channels should ensure a
>> balance of rights and a proportionality in any restraining measure.
>>
>> And this new post is not to exonerate myself of any legal responsibility
>> for personal matters that could be recognized as the outcome of a judicial
>> process, respective of both rights of the accusation and rights of the
>> defense. Rather to enlighten the Bitcoin community that the formal
>> separation between private matters and open-source responsibilities, and
>> the adequate check-and-balances to guarantee this separation is somehow
>> what are the underlying stakes for this feud between Chaincode and myself,
>> from my perspective. I can say missing an open-source engineering meeting
>> or being revoked a few Github permissions matters far less than the clear
>> affirmation and respect of the freedom of expression, the presumption of
>> innocence and due process in the Bitcoin common space, all proportions
>> conserved.
>>
>> I don't blame any party involved in this issue, nor assign "bad
>> intentions''. One position is really a function of your life experiences,
>> knowledge of the legal and cultural framework and access to the factual
>> elements. As all human conflicts it is not binary rather "grey". People can
>> be top executives at a billion-dollar company, having successful ventures
>> with hundreds of folks under management, or have a lot of responsibilities
>> for their relative young age, and still disagree on the set of legal and
>> moral principles to apply in the present case.
>>
>> Finally, thanks to the Bitcoin friends who have reached out to call for
>> level-headedness and cool-mindness in the public discussion of this complex
>> topic. Like I said to them, in the lack of more suspected wrongdoing from
>> the other side, I won't communicate further on this subject on the Bitcoin
>> and Lightning technical channels. However I still firmly believe the
>> discussion on the principles, abstract in the maximum from its private
>> elements, should still be pursued on other channels. Independently, there
>> is a legal channel opened between Chaincode and myself and good progress is
>> made to find a serene and long-standing resolution to this issue.
>>
>> Best,
>> Antoine
>>
>> [0]
>> https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
>> [1]
>> https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
>> [2]
>> https://www.ietf.org/about/administration/policies-procedures/conflict-interest/
>>
>> Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev <
>> lightning-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Is there a better place to have public communication? Unfortunately
>>> since one off topic email was sent here, it's been a ghost town. It appears
>>> that there's many emails being held and only one moderator that checks them
>>> once a week.
>>>
>>> Would hate to see this list die but wondering if there's a better place
>>> for discussions?
>>>
>>> Tony
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------- Original Message --------
>>> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com> wrote:
>>>
>>>
>>> Hi all,
>>>
>>> When I joined the lightning community a few years ago, I was relatively
>>> new to open source software and specification work. Rusty really impressed
>>> on me on the importance of holding conversations, as much as possible in
>>> public.
>>>
>>> Practically speaking, this encompasses IRC, this mailing list, and
>>> github issues/PRs.
>>>
>>> The reason for this is twofold. It helps document the range of options
>>> considered for technical decisions and it provides an interface point for
>>> new participants to contribute to the discussion.
>>>
>>> Given some recent mails that were posted to this list, now seems like a
>>> good time to reiterate the importance and preference of public
>>> communication whenever possible, especially for specification or technical
>>> discussions.
>>>
>>>
>>> ~ nifty
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230511/c3c983e8/attachment-0001.html>;

📅 Original date posted:2020-05-06 📝 Original message: Hi ...

2023-06-09T13:00:11Z

In reply to nevent1q…z5y3
_________________________

📅 Original date posted:2020-05-06
📝 Original message:
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 <antoine.riard at gmail.com>
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 <luke at dashjr.org> 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-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200506/ce5bff4d/attachment.html>;

📅 Original date posted:2020-05-14 📝 Original message: > ...

2023-06-09T13:00:09Z

In reply to nevent1q…kl23
_________________________

📅 Original date posted:2020-05-14
📝 Original message:
> 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.thyfronitis at 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-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200514/8cf2f0f1/attachment.html>;

📅 Original date posted:2022-06-04 📝 Original message:> ...

2023-06-07T23:10:02Z

In reply to nevent1q…0zce
_________________________

📅 Original date posted:2022-06-04
📝 Original message:> 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 at 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-request at lists.linuxfoundation.org> wrote:
>
>>
>> Date: Fri, 03 Jun 2022 18:39:34 +0000
>> From: alicexbt <alicexbt at protonmail.com>
>> To: Bitcoin Protocol Discussion
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
>> Message-ID:
>>
>> <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@
>> 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 developers like other
>> soft forks.
>>
>> /dev/fd0
>>
>>
>> Sent with Proton Mail secure email.
>>
>>
>> ------------------------------
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220604/a16a73a5/attachment-0001.html>;

📅 Original date posted:2022-04-26 📝 Original message:Hi ...

2023-06-07T23:08:20Z

In reply to nevent1q…awh7
_________________________

📅 Original date posted:2022-04-26
📝 Original message: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 does
not exist for a particular initiative

2. This is just a proposal for "pay to play", we should not let the wealthy
make consensus decisions.
- I agree that wealth should not be able to strong-arm decision making. But
the status quo seems even worse where we let publicly influential people
decide consensus in such a way where not only do they not "lose ammunition"
in the process of campaigning, but actually accrue it, creating really bad
long-term balances of power.

3. Enforcing this proposal requires its own soft fork.
- Yes. It does...and there's a certain cosmic irony to that, but before we
consider how to make this happen, I'd like to even discuss whether or not
it's a good idea.

4. This gives CoinJoin pool operators and L2 protocol implementations power
over deciding consensus.
- I see this as an improvement over the status quo

5. This encourages "spam"
- If you pay the fees, it's not spam.

The biggest question I'd like to pose to the forum is:
- Does a scheme like this afford us a better view into consensus than we
have today?
- Can it be gamed to give us a *worse* view into consensus? How?
- Does it measure the right thing? If not, what do you think is the right
thing to measure? (assuming we could)
- Should I write a BIP spec'ing this out in detail?

Cheers,
Keagan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/f3d1f2bf/attachment.html>;

📅 Original date posted:2022-04-25 📝 Original message:Hi AJ, ...

2023-06-07T23:07:05Z

In reply to nevent1q…wd99
_________________________

📅 Original date posted:2022-04-25
📝 Original message: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 at lists.linuxfoundation.org> wrote:

>
>
> On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns <aj at erisian.com.au> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/85ea01c2/attachment.html>;

📅 Original date posted:2021-06-23 📝 Original message:> ...

2023-06-07T22:54:17Z

In reply to nevent1q…hjmp
_________________________

📅 Original date posted:2021-06-23
📝 Original message:> 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 <billy.tetrud at gmail.com> 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.mcclelland at 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 at 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 at 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 at 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
>>>>> professional/expert way is accessible to anyone with a raspberry Pi and a
>>>>> web connection, which is a much lower barrier to entry than PoW.
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210623/b99b3f9f/attachment.html>;

📅 Original date posted:2021-06-23 📝 Original message:> ...

2023-06-07T22:54:16Z

In reply to nevent1q…ujrg
_________________________

📅 Original date posted:2021-06-23
📝 Original message:> 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 at 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 at 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 at 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
>>> professional/expert way is accessible to anyone with a raspberry Pi and a
>>> web connection, which is a much lower barrier to entry than PoW.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210623/799426cc/attachment.html>;

📅 Original date posted:2021-05-10 📝 Original message:To ...

2023-06-07T22:52:42Z

In reply to nevent1q…lw7k
_________________________

📅 Original date posted:2021-05-10
📝 Original message: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 at 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
> <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210510/a45a8038/attachment.html>;

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

2023-06-07T18:30:36Z

In reply to nevent1q…spgr
_________________________

📅 Original date posted:2021-03-06
📝 Original message: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 at lists.linuxfoundation.org> wrote:

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

📅 Original date posted:2021-03-05 📝 Original message:> A ...

2023-06-07T18:30:08Z

In reply to nevent1q…qqxh
_________________________

📅 Original date posted:2021-03-05
📝 Original message:> 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 at 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.mcclelland at 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 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 at 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 <
>>> loneroassociation at 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 <c1.devrandom at niftybox.net>
>>>> wrote:
>>>>
>>>>> Hi Ryan and Andrew,
>>>>>
>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
>>>>> bitcoin-dev at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210305/654d8299/attachment-0001.html>;

📅 Original date posted:2021-03-05 📝 Original message:It is ...

2023-06-07T18:30:07Z

In reply to nevent1q…40je
_________________________

📅 Original date posted:2021-03-05
📝 Original message: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 at 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 <
> loneroassociation at 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 <c1.devrandom at niftybox.net>
>> wrote:
>>
>>> Hi Ryan and Andrew,
>>>
>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
>>> bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210305/24e78df4/attachment-0001.html>;

📅 Original date posted:2021-03-10 📝 Original message:LORD ...

2023-06-07T18:29:29Z

In reply to nevent1q…wfct
_________________________

📅 Original date posted:2021-03-10
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of Ryan Grant via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 6 March 2021 1:04 AM
> *To:* Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Taproot NACK
>
> On Thu, Mar 4, 2021 at 8:48 PM LORD HIS EXCELLENCY JAMES HRMH via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210310/9f72b3f9/attachment-0001.html>;

📅 Original date posted:2021-02-26 📝 Original message:Hi ...

2023-06-07T18:29:14Z

In reply to nevent1q…4z79
_________________________

📅 Original date posted:2021-02-26
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210226/b25852a4/attachment.html>;

📅 Original date posted:2021-02-23 📝 Original message:I ...

2023-06-07T18:29:00Z

In reply to nevent1q…2kp9
_________________________

📅 Original date posted:2021-02-23
📝 Original message: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 at 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% fewer than 70% of
> miners are signaling for Taproot at this time. If X% is small the
> increased orphan rate caused by the LOT=true miners will cause it to
> activate anyways. If X% is larger, then there will be a consensus split.
>
>
>
> *# 80% on LOT=true, 20% LOT=False*
> - Case 1: Activates ahead of time Anyways
>
> No issues.
>
> - Case 2: Fails to Activate before timeout...
>
> A% + B% + C% = 20%
>
> A% (upgraded, signal activate) remain on majority chain with LOT=false,
> blocks mined universally valid.
>
> B% (upgraded, not signaling) succeeds in activating and maintaining
> consensus, blocks are temporarily lost during the final period, but
> consensus re-emerges.
>
> C% (not upgraded/not signalling) both fail to activate (not upgraded) and
> blocks are rejected (not signaling) during mandatory signalling.
> Essentially becomes an SPV miner, should still not select transactions
> improperly given mempool policy, but may mine a bad tip.
>
> (I argue that group B is irrational entirely, as in this case the majority
> has upgraded, inevitably winning, and is orphaning their blocks so B should
> effectively be 0% or can be combined with group C as being somehow not
> upgraded if they are unable to switch once it becomes clear after say the
> first 100 blocks in the period that LOT > 50%. The only difference in
> lumping B with C is that group C SPV mines after the fork and B should, in
> theory, have full validation.).
>
>
>
> Apologies if my base analysis is off -- happy to take corrections.
>
>
> My overall summary is thus:
>
> 1) People care what Core releases because we assume the majority will
> likely run it. If core were a minority project, we wouldn't really care
> what core released.
> 2) People are upset with LOT=true being suggested as release parameters
> because of the *narrative* that it puts devs in control.
> 3) LOT=true having a sizeable minority running it presents major issues to
> majority LOT=false in terms of lost blocks during the final period and in
> terms of a longer term fork.
> 4) Majority LOT=true has no long term instability on consensus (majority
> LOT=true means the final period always activates, any instability is short
> lived + irrational).
> 5) On the balance, the safer parameter to release *seems* to be LOT=true.
> But because devs are sensitive to control narrative, LOT=false is preferred
> by devs.
> 6) Almost paradoxically, choosing a *less safe* option for a narrative
> reason is more of a show of dev control than choosing a more safe option
> despite appearances.
> 7) This all comes down to if we think that a reasonable number of
> important nodes will run LOT=true.
> 8) This all doesn't matter *that much* because taproot will have many
> opportunities to activate before the brinksmanship period.
>
> As a plan of action, I think that means that either:
>
> A) Core should release LOT=true, as a less disruptive option given stated
> community intentions to do LOT=true
> B) Core community should vehemently anti-advocate running LOT=true to
> ensure the % is as small as possible
> C) Do nothing
> D) Core community should release LOT=false and vehemently advocate
> manually changing to LOT=true to ensure the % is supermajority, but leaving
> it as a user choice.
>
>
> Overall, I worry that plan B has a mild Streissand effect and would result
> in boosting LOT=true (which could be OK, so long as LOT=true +
> LOT=false+signal yes becomes the large majority, but would be not fun for
> anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C
> most likely ends up with some % doing LOT=true anyways. D feels a little
> silly, but maybe a good tradeoff.
>
> If I had to summarize the emotional dynamic among developers around
> LOT=true, I think devs wish it didn't exist because it is clear LOT=true
> *creates* the issues here. LOT=false would be fine if the LOT=true strategy
> didn't exist at all. But unfortunately the cat is out of the bag and cannot
> be put back in. To validate the emotions, I think it is fine to be angry
> about LOT=true and not like it, but we should either accept that it is most
> likely to create consensus OR we should find a new game theoretic
> activation strategy with better pro-social equilibriums.
>
> Personally, I think with either plan the ultimate risk of forking is low
> given probability to activate before timeout, so we should just pick
> something and move on, accepting that we aren't setting a precedent by
> which all future forks should abide. Given my understanding of the
> tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't
> move to hold back a plan of LOT=false (but would probably take mitigative
> steps on community advocacy if it looks like there is non majority but non
> negligible LOT=true uptake).
>
> Cheers,
>
> Jeremy
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210223/5d65c6e3/attachment-0001.html>;

📅 Original date posted:2021-02-18 📝 Original message:Hi ...

2023-06-07T18:28:52Z

In reply to nevent1q…fx33
_________________________

📅 Original date posted:2021-02-18
📝 Original message: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 at 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 <lf-lists at mattcorallo.com
> <mailto:lf-lists at mattcorallo.com>> 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.
> >
> > Bitcoin is a consensus system. The absolute worst outcome at all
> possible is to have it fall out of consensus.
> >
> > Matt
> >
> >> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >>
> >>
> >> Right, that is one option. Personally I would prefer a Bitcoin Core
> release sets LOT=false (based on what I have
> >> heard from Bitcoin Core contributors) and a community effort
> releases a version with LOT=true. I don't think users
> >> should be forced to choose something they may have no context on
> before they are allowed to use Bitcoin Core.
> >>
> >> My current understanding is that roasbeef is planning to set
> LOT=false on btcd (an alternative protocol
> >> implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided
> on Bitcoin Knots.
> >>
> >>
> >>
> >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com
> <mailto:ZmnSCPxj at protonmail.com>> wrote:
> >>
> >> Good morning all,
> >>
> >> > "An activation mechanism is a consensus change like any other
> change, can be contentious like any other
> >> change, and we must resolve it like any other change. Otherwise
> we risk arriving at the darkest timeline."
> >> >
> >> > Who's we here?
> >> >
> >> > Release both and let the network decide.
> >>
> >> A thing that could be done, without mandating either LOT=true
> or LOT=false, would be to have a release that
> >> requires a `taprootlot=1` or `taprootlot=0` and refuses to
> start if the parameter is not set.
> >>
> >> This assures everyone that neither choice is being forced on
> users, and instead what is being forced on users,
> >> is for users to make that choice themselves.
> >>
> >> Regards,
> >> ZmnSCPxj
> >>
> >> >
> >> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >> >
> >> > > Thanks for your response Ariel. It would be useful if you
> responded to specific points I have made in the
> >> mailing list post or at least quote these ephemeral "people"
> you speak of. I don't know if you're responding
> >> to conversation on the IRC channel or on social media etc.
> >> > >
> >> > > > The argument comes from a naive assumption that users
> MUST upgrade to the choice that is submitted into
> >> code. But in fact this isn't true and some voices in this
> discussion need to be more humble about what users
> >> must or must not run.
> >> > >
> >> > > I personally have never made this assumption. Of course
> users aren't forced to run any particular software
> >> version, quite the opposite. Defaults set in software versions
> matter though as many users won't change them.
> >> > >
> >> > > > Does no one realize that it is a very possible outcome
> that if LOT=true is released there may be only a
> >> handful of people that begin running it while everyone else
> delays their upgrade (with the very good reason of
> >> not getting involved in politics) and a year later those
> handful of people just become stuck at the moment of
> >> MUST_SIGNAL, unable to mine new blocks?
> >> > >
> >> > > It is a possible outcome but the likely outcome is that
> miners activate Taproot before LOT is even
> >> relevant. I think it is prudent to prepare for the unlikely but
> possible outcome that miners fail to activate
> >> and hence have this discussion now rather than be unprepared
> for that eventuality. If LOT is set to false in a
> >> software release there is the possibility (T2 in
> >>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> >> <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>;)
> of individuals or a
> >> proportion of the community changing LOT to true. In that sense
> setting LOT=false in a software release
> >> appears to be no more safe than LOT=true.
> >> > >
> >> > > > The result: a wasted year of waiting and a minority of
> people who didn't want to be lenient with miners
> >> by default.
> >> > >
> >> > > There is the (unlikely but possible) possibility of a
> wasted year if LOT is set to false and miners fail
> >> to activate. I'm not convinced by this perception that LOT=true
> is antagonistic to miners. I actually think it
> >> offers them clarity on what will happen over a year time period
> and removes the need for coordinated or
> >> uncoordinated community UASF efforts on top of LOT=false.
> >> > >
> >> > > > An activation mechanism is a consensus change like any
> other change, can be contentious like any other
> >> change, and we must resolve it like any other change. Otherwise
> we risk arriving at the darkest timeline.
> >> > >
> >> > > I don't know what you are recommending here to avoid "this
> darkest timeline". Open discussions have
> >> occurred and are continuing and in my mailing list post that
> you responded to **I recommended we propose
> >> LOT=false be set in protocol implementations such as Bitcoin
> Core**. I do think this apocalyptic language
> >> isn't particularly helpful. In an open consensus system
> discussion is healthy, we should prepare for bad or
> >> worst case scenarios in advance and doing so is not
> antagonistic or destructive. Mining pools have pledged
> >> support for Taproot but we don't build secure systems based on
> pledges of support, we build them to minimize
> >> trust in any human actors. We can be grateful that people like
> Alejandro have worked hard on
> >> taprootactivation.com <http://taprootactivation.com>; (and this
> effort has informed the discussion) without
> >> taking pledges of support as cast iron guarantees.
> >> > >
> >> > > TL;DR It sounds like you agree with my recommendation to
> set LOT=false in protocol implementations in my
> >> email :)
> >> > >
> >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <
> arielluaces at gmail.com
> >> <mailto:arielluaces at gmail.com>> wrote:
> >> > >
> >> > > > Something what strikes me about the conversation is the
> emotion surrounding the letters UASF.
> >> > > > It appears as if people discuss UASF as if it's a massive
> tidal wave of support that is inevitable, like
> >> we saw during segwit activation. But the actual definition is
> "any activation that is not a MASF".
> >> > > > A UASF can consist of a single node, ten nodes, a
> thousand, half of all nodes, all business' nodes, or
> >> even all the non mining nodes. On another dimension it can have
> zero mining support, 51% support, 49% support,
> >> or any support right up against a miner activation threshold.
> >> > > > Hell a UASF doesn't even need code or even a single node
> running as long as it exists as a possibility
> >> in people's minds.
> >> > > > The only thing a UASF doesn't have is miner support above
> an agreed activation threshold (some number
> >> above %51).
> >> > > > I say this because it strikes me when people say that
> they are for LOT=true with the logic that since a
> >> UASF is guaranteed to happen then it's better to just make it
> default from the beginning. Words like
> >> coordination and safety are sometimes sprinkled into the
> argument.
> >> > > > The argument comes from a naive assumption that users
> MUST upgrade to the choice that is submitted into
> >> code. But in fact this isn't true and some voices in this
> discussion need to be more humble about what users
> >> must or must not run.
> >> > > > Does no one realize that it is a very possible outcome
> that if LOT=true is released there may be only a
> >> handful of people that begin running it while everyone else
> delays their upgrade (with the very good reason of
> >> not getting involved in politics) and a year later those
> handful of people just become stuck at the moment of
> >> MUST_SIGNAL, unable to mine new blocks? Or attracting a
> minority of miners, activating, and forking off into a
> >> minority fork. Then a lot=false could be started that ends up
> activating the feature now that the stubborn
> >> option has ran its course.
> >> > > > The result: a wasted year of waiting and a minority of
> people who didn't want to be lenient with miners
> >> by default. The chains could be called BitcoinLenient and
> BitcoinStubborn.
> >> > > > How is that strictly safer or more coordinated?
> >> > > > I may be in the minority, or maybe a silent majority, or
> maybe a majority that just hasn't considered
> >> this as a choice but honestly if there is contention about
> whether we're going to be stubborn or lenient with
> >> miners for Taproot and in the future then I prefer to just not
> activate anything at all. I'm fine for calling
> >> bitcoin ossified, accepting that segwit is Bitcoin's last
> network upgrade. Taproot is amazing but no new
> >> feature is worth a network split down the middle.
> >> > > > Maybe in 10 or 20 years, when other blockchains implement
> features like Taproot and many more, we will
> >> become envious enough to put aside our differences on how to
> behave towards miners and finally activate Taproot.
> >> > > > An activation mechanism is a consensus change like any
> other change, can be contentious like any other
> >> change, and we must resolve it like any other change. Otherwise
> we risk arriving at the darkest timeline.
> >> > > > Cheers
> >> > > > Ariel Lorenzo-Luaces
> >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> >> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >> > > >
> >> > > > > Yesterday (February 16th) we held a second meeting on
> Taproot
> >> > > > > activation on IRC which again was open to all. Despite
> what appeared
> >> > > > > to be majority support for LOT=false over LOT=true in
> the first
> >> > > > > meeting I (and others) thought the arguments had not
> been explored in
> >> > > > > depth and that we should have a follow up meeting
> almost entirely
> >> > > > > focused on whether LOT (lockinontimeout) should be set
> to true or
> >> > > > > false.
> >> > > > >
> >> > > > > The meeting was announced here:
> >> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> >> <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> >
> >> > > > >
> >> > > > > In that mailing list post I outlined the arguments for
> LOT=true (T1 to
> >> > > > > T6) and arguments for LOT=false (F1 to F6) in their
> strongest form I
> >> > > > > could. David Harding responded with an additional
> argument for
> >> > > > > LOT=false (F7) here:
> >> > > > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> >> <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> >
> >> > > > >
> >> > > > > These meetings are very challenging given they are open
> to all, you
> >> > > > > don’t know who will attend and you don’t know most
> people’s views in
> >> > > > > advance. I tried to give time for both the LOT=true
> arguments and the
> >> > > > > LOT=false arguments to be discussed as I knew there was
> support for
> >> > > > > both. We only tried evaluating which had more support
> and which had
> >> > > > > more strong opposition towards the end of the meeting.
> >> > > > >
> >> > > > > The conversation log is here:
> >> > > > > http://gnusha.org/taproot-activation/2021-02-16.log <
> http://gnusha.org/taproot-activation/2021-02-16.log>;
> >> > > > >
> >> > > > > (If you are so inclined you can watch a video of the
> meeting here.
> >> > > > > Thanks to the YouTube account “Bitcoin” for setting up
> the livestream:
> >> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <
> https://www.youtube.com/watch?v=vpl5q1ovMLM>;)
> >> > > > >
> >> > > > > A summary of the meeting was provided by Luke Dashjr on
> Mastodon here:
> >> > > > >
> https://bitcoinhackers.org/@lukedashjr/105742918779234566
> >> <https://bitcoinhackers.org/@lukedashjr/105742918779234566>;
> >> > > > >
> >> > > > > Today's #Bitcoin #Taproot meeting was IMO largely
> unproductive, but we
> >> > > > > did manage to come to consensus on everything but
> LockinOnTimeout.
> >> > > > >
> >> > > > > Activation height range: 693504-745920
> >> > > > >
> >> > > > > MASF threshold: 1815/2016 blocks (90%)
> >> > > > >
> >> > > > > Keep in mind only ~100 people showed for the meetings,
> hardly
> >> > > > > representative of the entire community.
> >> > > > >
> >> > > > > So, these details remain JUST a proposal for now.
> >> > > > >
> >> > > > > It seems inevitable that there won't be consensus on
> LOT.
> >> > > > >
> >> > > > > Everyone will have to choose for himself. :/
> >> > > > >
> >> > > > > Personally I agree with most of this. I agree that
> there wasn’t
> >> > > > > overwhelming consensus for either LOT=true or
> LOT=false. However, from
> >> > > > > my perspective there was clearly more strong opposition
> (what would
> >> > > > > usually be deemed a NACK in Bitcoin Core review
> terminology) from
> >> > > > > Bitcoin Core contributors, Lightning developers and
> other community
> >> > > > > members against LOT=true than there was for LOT=false.
> Andrew Chow
> >> > > > > tried to summarize views from the meeting in this
> analysis:
> >> > > > >
> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> >> <
> https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>;
> >> > > > >
> >> > > > > I am also aware of other current and previous Bitcoin
> Core
> >> > > > > contributors and Lightning developers who didn’t attend
> the meeting in
> >> > > > > person who are opposed to LOT=true. I don’t want to put
> them in the
> >> > > > > spotlight for no reason but if you go through the
> conversation logs of
> >> > > > > not only the meeting but the weeks of discussion prior
> to this meeting
> >> > > > > you will see their views evaluated on the
> ##taproot-activation
> >> > > > > channel. In addition, on taprootactivation.com <
> http://taprootactivation.com>; some mining pools
> >> > > > > expressed a preference for lot=false though I don’t
> know how strong
> >> > > > > that preference was.
> >> > > > >
> >> > > > > I am only one voice but it is my current assessment
> that if we are to
> >> > > > > attempt to finalize Taproot activation parameters and
> propose them to
> >> > > > > the community at this time our only option is to
> propose LOT=false.
> >> > > > > Any further delay appears to me counterproductive in
> our collective
> >> > > > > aim to get the Taproot soft fork activated as early as
> possible.
> >> > > > >
> >> > > > > Obviously others are free to disagree with that
> assessment and
> >> > > > > continue discussions but personally I will be
> attempting to avoid
> >> > > > > those discussions unless prominent new information
> comes to light or
> >> > > > > various specific individuals change their minds.
> >> > > > >
> >> > > > > Next week we are planning a code review of the Bitcoin
> Core PR #19573
> >> > > > > which was initially delayed because of this LOT
> discussion. As I’ve
> >> > > > > said previously that will be loosely following the
> format of the
> >> > > > > Bitcoin Core PR review club and will be lower level and
> more
> >> > > > > technical. That is planned for Tuesday February 23rd at
> 19:00 UTC on
> >> > > > > the IRC channel ##taproot-activation.
> >> > > > >
> >> > > > > Thanks to the meeting participants (and those who
> joined the
> >> > > > > discussion on the channel prior and post the meeting)
> for engaging
> >> > > > > productively and in good faith.
> >> > >
> >> > > --
> >> > > Michael Folkson
> >> > > Email: michaelfolkson at gmail.com <mailto:
> michaelfolkson at gmail.com>
> >> > > Keybase: michaelfolkson
> >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> > > _______________________________________________
> >> > > bitcoin-dev mailing list
> >> > > bitcoin-dev at lists.linuxfoundation.org <mailto:
> bitcoin-dev at lists.linuxfoundation.org>
> >> > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >>
> >>
> >>
> >>
> >> --
> >> Michael Folkson
> >> Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com>
> >> Keybase: michaelfolkson
> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto:
> bitcoin-dev at lists.linuxfoundation.org>
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> >
> >
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com>
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210218/a2f47541/attachment-0001.html>;

📅 Original date posted:2020-05-08 📝 Original message:> ...

2023-06-07T18:24:24Z

In reply to nevent1q…w63v
_________________________

📅 Original date posted:2020-05-08
📝 Original message:> 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 <braydon at purse.io> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200508/dd8331af/attachment-0001.html>;

📅 Original date posted:2020-05-07 📝 Original message:I ...

2023-06-07T18:24:23Z

In reply to nevent1q…n7sc
_________________________

📅 Original date posted:2020-05-07
📝 Original message: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 <antoine.riard at gmail.com>
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 <keagan.mcclelland at gmail.com>
> 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 <antoine.riard at gmail.com>
>> 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 <luke at dashjr.org> 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-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200506/26bac9b9/attachment.html>;