Nostr notes by Keagan McClelland [ARCHIVE]

📅 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:2023-05-19 🗒️ Summary of this ...

2023-06-09T13:13:13Z

In reply to nevent1q…9fkc
_________________________

📅 Original date posted:2023-05-19
🗒️ Summary of this message: To spend the to_local output or HTLC outputs, they must first become spendable after the delay period, and LND automatically handles their submission.
📝 Original message:
Hi Benjamin,

Keep in mind that the to_local output is only spendable after the delay
period which means it is not a valid transaction (and won't show up in the
mempool) until the output becomes spendable. This is also true for HTLC
outputs if the channel type has anchors. The delay period for HTLCs is only
one block if you are trying to redeem an HTLC (instead of timing it out).
LND normally automatically handles the submission of these transactions
when they become viable. Submitting them prior will do nothing.

I will let others comment on how to actually generate this with lncli or
chantools or the like, since I'm unsure of how to do so off the top of my
head.

Stay Inspired,
Keags

On Fri, May 5, 2023 at 9:19 PM Benjamin Weintraub via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Thank you, Ken. I have a follow up question as well.
>
> Context: I’m playing around with some failure scenarios in LND. Say Alice
> is paying Bob, before Bob is able to send the fulfillment (which includes
> the HTLC preimage), Alice’s node dies and becomes unreachable.
>
> Bob has already received the commitment for the updated balance and
> already has the preimage, so he force closes the channel.
>
> My understanding is that he will submit the updated commitment to the
> blockchain as well as the channel closing transaction (after the CSV
> timeout) which spends his to_local and the HTLC output.
>
> Here is my problem. After using `lncli closechannel --force ...` , I only
> see the commitment transaction in the mempool, not the subsequent
> HTLC/to_local spend. How can I generate the transaction that spends the
> to_local and HTLC output? If there's a way to generate it with lnd, that
> would be ideal.
>
> Thanks in advance!
>
> Ben
> ------------------------------
> *From:* Ken Sedgwick <ksedgwic at bonsai.com>
> *Sent:* Sunday, April 30, 2023 14:30
> *To:* Benjamin Weintraub <weintraub.b at northeastern.edu>
> *Cc:* Lightning-dev at lists.linuxfoundation.org <
> lightning-dev at lists.linuxfoundation.org>
> *Subject:* Re: [Lightning-dev] Spending `to_local` output of commitment
>
> Ben,
>
> The necessary witness is described here:
>
> https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local-output
>
> Regards,
>
> Ken
>
> On Sat, Apr 29, 2023 at 7:57 PM Benjamin Weintraub via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> I have a question about commitments. If a peer force closes a channel by
> sending a commitment to the blockchain, what kind of witness script is
> needed to redeem the `to_local` funds? (assuming the `to_self_delay` has
> elapsed.) It seems that the transaction described here is for cooperative
> closures:
> https://github.com/lightning/bolts/blob/c74a3bbcf890799d343c62cb05fcbcdc952a1cf3/03-transactions.md#closing-transaction
> . But for force closures, I would think that the txin would need to be
> the `to_local` txout of the commitment.
>
> Concretely, I have commited the following transaction on a local simnet
> bitcoin blockchain and mined 500 blocks on top of it. I want to spend
> vout[2], how can I generate such a transaction?
>
>
> {
> "hash":
> "47d15337bb3c29c7c2881dd7cd912604b401ed221c66ea6f781b456d4983d451",
> "size": 444,
> "vsize": 279,
> "weight": 1113,
> "version": 2,
> "locktime": 551351761,
> "vin": [
> {
> "txid":
> "0248025b9447df8267d02d14c34ab9b269f52cd827132c70159a55cbf27ab3c1",
> "vout": 0,
> "scriptSig": {
> "asm": "",
> "hex": ""
> },
> "txinwitness": [
> "",
>
> "3045022100d3f52ca04d6a71587c29592931e542b16a47f3e9e577f1869b416547d00c62dd0220485da35ad31ff71b4263b1a25f0ba9f35990e1c8d5ac848365bbd588c3ce83d701",
>
> "3044022057fc3878e17a865c12d57b7885ed48f0d6122bd9e00511c8eac150180d1508d502205fd1d0674a41b3c0118d0b6c19b1c77d35fc95bb89f929da6478f22e94dbf5ce01",
>
> "5221038acdafe305edd06e91706ee687a091be306f0f29bcbda52dadde084bbaa36c902103d8fd53b9b43638c2255e1abd6f134a0232d2fba65527252c4eb81f926ddf50ad52ae"
> ],
> "sequence": 2161061453
> }
> ],
> "vout": [
> {
> "value": 0.0000033,
> "n": 0,
> "scriptPubKey": {
> "asm": "0
> 45ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
> "hex":
> "002045ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1qghkgvfzrwm28qqx2vkf8swazda4j4ese5fxg7hadyjdccutf2htqysq3qz"
> ]
> }
> },
> {
> "value": 0.0000033,
> "n": 1,
> "scriptPubKey": {
> "asm": "0
> 502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
> "hex":
> "0020502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1q2q4pweztxdzg959r7kyanps67m3pqk5m0t7n7hp93m7f3wm2amksa0fysc"
> ]
> }
> },
> {
> "value": 0.0002,
> "n": 2,
> "scriptPubKey": {
> "asm": "0
> 045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
> "hex":
> "0020045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1qq3248lrcjj20zmhlfnazy8gzjns5p7mewuh0ad7c897s4swye7zsyrm5pc"
> ]
> }
> },
> {
> "value": 0.009761,
> "n": 3,
> "scriptPubKey": {
> "asm": "0
> 2d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
> "hex":
> "00202d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1q94gu5ssdpd4t2myhegnrr4esfjddjqjj2t48rua037tnv9neqshqm4z7yr"
> ]
> }
> }
> ],
> "blockhash":
> "0fa78bc7e9f6e0a60be71bb5fb2eaaf42a97895bb057f09d7cbb2c49120fa61d",
> "confirmations": 500,
> "time": 1682451410,
> "blocktime": 1682451410
> }
>
>
>
> Thanks in advance,
>
> Ben
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
> --
> Ken Sedgwick
> Bonsai Software, Inc.
> http://www.bonsai.com/ken/
> (510) 269-7334
> ken at bonsai.com
> Public Key: http://www.bonsai.com/ken/ken.asc
> GPG Fingerprint: 4695 E5B8 F781 BF85 4326 9639 BBFC E515 8602 5550
>
> _______________________________________________
> 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/20230519/7c2a9e2b/attachment.html>;

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

2023-06-09T13:13:10Z

In reply to nevent1q…qjay
_________________________

📅 Original date posted:2023-05-11
🗒️ Summary of this message: A message advises Jorge to consider how his emails will be perceived by others and communicate in a way that seeks common ground and demonstrates good faith.
📝 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:2023-05-19 📝 Original message: Hi ...

2023-06-09T13:08:43Z

In reply to nevent1q…mevv
_________________________

📅 Original date posted:2023-05-19
📝 Original message:
Hi Benjamin,

Keep in mind that the to_local output is only spendable after the delay
period which means it is not a valid transaction (and won't show up in the
mempool) until the output becomes spendable. This is also true for HTLC
outputs if the channel type has anchors. The delay period for HTLCs is only
one block if you are trying to redeem an HTLC (instead of timing it out).
LND normally automatically handles the submission of these transactions
when they become viable. Submitting them prior will do nothing.

I will let others comment on how to actually generate this with lncli or
chantools or the like, since I'm unsure of how to do so off the top of my
head.

Stay Inspired,
Keags

On Fri, May 5, 2023 at 9:19 PM Benjamin Weintraub via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Thank you, Ken. I have a follow up question as well.
>
> Context: I’m playing around with some failure scenarios in LND. Say Alice
> is paying Bob, before Bob is able to send the fulfillment (which includes
> the HTLC preimage), Alice’s node dies and becomes unreachable.
>
> Bob has already received the commitment for the updated balance and
> already has the preimage, so he force closes the channel.
>
> My understanding is that he will submit the updated commitment to the
> blockchain as well as the channel closing transaction (after the CSV
> timeout) which spends his to_local and the HTLC output.
>
> Here is my problem. After using `lncli closechannel --force ...` , I only
> see the commitment transaction in the mempool, not the subsequent
> HTLC/to_local spend. How can I generate the transaction that spends the
> to_local and HTLC output? If there's a way to generate it with lnd, that
> would be ideal.
>
> Thanks in advance!
>
> Ben
> ------------------------------
> *From:* Ken Sedgwick <ksedgwic at bonsai.com>
> *Sent:* Sunday, April 30, 2023 14:30
> *To:* Benjamin Weintraub <weintraub.b at northeastern.edu>
> *Cc:* Lightning-dev at lists.linuxfoundation.org <
> lightning-dev at lists.linuxfoundation.org>
> *Subject:* Re: [Lightning-dev] Spending `to_local` output of commitment
>
> Ben,
>
> The necessary witness is described here:
>
> https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local-output
>
> Regards,
>
> Ken
>
> On Sat, Apr 29, 2023 at 7:57 PM Benjamin Weintraub via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> I have a question about commitments. If a peer force closes a channel by
> sending a commitment to the blockchain, what kind of witness script is
> needed to redeem the `to_local` funds? (assuming the `to_self_delay` has
> elapsed.) It seems that the transaction described here is for cooperative
> closures:
> https://github.com/lightning/bolts/blob/c74a3bbcf890799d343c62cb05fcbcdc952a1cf3/03-transactions.md#closing-transaction
> . But for force closures, I would think that the txin would need to be
> the `to_local` txout of the commitment.
>
> Concretely, I have commited the following transaction on a local simnet
> bitcoin blockchain and mined 500 blocks on top of it. I want to spend
> vout[2], how can I generate such a transaction?
>
>
> {
> "hash":
> "47d15337bb3c29c7c2881dd7cd912604b401ed221c66ea6f781b456d4983d451",
> "size": 444,
> "vsize": 279,
> "weight": 1113,
> "version": 2,
> "locktime": 551351761,
> "vin": [
> {
> "txid":
> "0248025b9447df8267d02d14c34ab9b269f52cd827132c70159a55cbf27ab3c1",
> "vout": 0,
> "scriptSig": {
> "asm": "",
> "hex": ""
> },
> "txinwitness": [
> "",
>
> "3045022100d3f52ca04d6a71587c29592931e542b16a47f3e9e577f1869b416547d00c62dd0220485da35ad31ff71b4263b1a25f0ba9f35990e1c8d5ac848365bbd588c3ce83d701",
>
> "3044022057fc3878e17a865c12d57b7885ed48f0d6122bd9e00511c8eac150180d1508d502205fd1d0674a41b3c0118d0b6c19b1c77d35fc95bb89f929da6478f22e94dbf5ce01",
>
> "5221038acdafe305edd06e91706ee687a091be306f0f29bcbda52dadde084bbaa36c902103d8fd53b9b43638c2255e1abd6f134a0232d2fba65527252c4eb81f926ddf50ad52ae"
> ],
> "sequence": 2161061453
> }
> ],
> "vout": [
> {
> "value": 0.0000033,
> "n": 0,
> "scriptPubKey": {
> "asm": "0
> 45ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
> "hex":
> "002045ec86244376d47000ca6592783ba26f6b2ae619a24c8f5fad249b8c716955d6",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1qghkgvfzrwm28qqx2vkf8swazda4j4ese5fxg7hadyjdccutf2htqysq3qz"
> ]
> }
> },
> {
> "value": 0.0000033,
> "n": 1,
> "scriptPubKey": {
> "asm": "0
> 502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
> "hex":
> "0020502a17644b334482d0a3f589d9861af6e2105a9b7afd3f5c258efc98bb6aeeed",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1q2q4pweztxdzg959r7kyanps67m3pqk5m0t7n7hp93m7f3wm2amksa0fysc"
> ]
> }
> },
> {
> "value": 0.0002,
> "n": 2,
> "scriptPubKey": {
> "asm": "0
> 045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
> "hex":
> "0020045553fc789494f16eff4cfa221d0294e140fb79772efeb7d8397d0ac1c4cf85",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1qq3248lrcjj20zmhlfnazy8gzjns5p7mewuh0ad7c897s4swye7zsyrm5pc"
> ]
> }
> },
> {
> "value": 0.009761,
> "n": 3,
> "scriptPubKey": {
> "asm": "0
> 2d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
> "hex":
> "00202d51ca420d0b6ab56c97ca2631d7304c9ad9025252ea71f3af8f97361679042e",
> "reqSigs": 1,
> "type": "witness_v0_scripthash",
> "addresses": [
> "sb1q94gu5ssdpd4t2myhegnrr4esfjddjqjj2t48rua037tnv9neqshqm4z7yr"
> ]
> }
> }
> ],
> "blockhash":
> "0fa78bc7e9f6e0a60be71bb5fb2eaaf42a97895bb057f09d7cbb2c49120fa61d",
> "confirmations": 500,
> "time": 1682451410,
> "blocktime": 1682451410
> }
>
>
>
> Thanks in advance,
>
> Ben
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
> --
> Ken Sedgwick
> Bonsai Software, Inc.
> http://www.bonsai.com/ken/
> (510) 269-7334
> ken at bonsai.com
> Public Key: http://www.bonsai.com/ken/ken.asc
> GPG Fingerprint: 4695 E5B8 F781 BF85 4326 9639 BBFC E515 8602 5550
>
> _______________________________________________
> 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/20230519/7c2a9e2b/attachment.html>;

📅 Original date posted:2023-05-11 📝 Original message: ...

2023-06-09T13:08:40Z

In reply to nevent1q…fgnh
_________________________

📅 Original date posted:2023-05-11
📝 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-08 📝 Original message: > ...

2023-06-09T13:00:13Z

In reply to nevent1q…x4gm
_________________________

📅 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/lightning-dev/attachments/20200508/dd8331af/attachment-0001.html>;

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

2023-06-09T13:00:12Z

In reply to nevent1q…nun8
_________________________

📅 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/lightning-dev/attachments/20200506/26bac9b9/attachment.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:2023-05-10 🗒️ Summary of this ...

2023-06-07T23:21:47Z

In reply to nevent1q…jplw
_________________________

📅 Original date posted:2023-05-10
🗒️ Summary of this message: A proposed BIP aims to establish a shared vocabulary for various components and aspects of transactions to avoid confusion and improve communication.
📝 Original message:Concept ACK,

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

Stay Inspired,
Keags

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

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

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

2023-06-07T23:21:33Z

In reply to nevent1q…thte
_________________________

📅 Original date posted:2023-05-10
🗒️ Summary of this message: All transactions in the blockchain are economically motivated. The best way to handle "non-economic" transactions is to reduce the necessary chain footprint of supposed "economically motivated" transactions.
📝 Original message:Erik,

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

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

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

Food for thought.

Stay Inspired,
Keags

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

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

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

2023-06-07T23:21:14Z

In reply to nevent1q…dnls
_________________________

📅 Original date posted:2023-05-19
🗒️ Summary of this message: A proposed password format improves upon BIP39 by allowing themed sentences with a regular grammatical structure, while keeping the same entropy and checksum.
📝 Original message:Good day Yuri,

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

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

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

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

Stay Inspired,
Keags

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

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

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

2023-06-07T23:10:07Z

In reply to nevent1q…ypkm
_________________________

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

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

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

Keagan

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

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

2023-06-07T23:09:53Z

In reply to nevent1q…uzew
_________________________

📅 Original date posted:2022-05-18
📝 Original message:> One must also analyze all the covenants that one *could* author using a
primitive

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

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

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

Keagan

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

> note of clarification:
>
> this is from the perspective of a developer trying to build infrastructure
> for covenants. from the perspective of bitcoin consensus, a covenant
> enforcing primitve would be something like OP_TLUV and less so it's use in
> conjunction with other opcodes, e.g. OP_AMOUNT.
>
> One must also analyze all the covenants that one *could* author using a
> primitive, in some sense, to demonstrate that our understanding is
> sufficient. As a trivial example, you could use
> OP_DELETE_BITCOIN_ENTIRELY_IF_KNOWS_PREIMAGE_TO_X_OR_TLUV and just because
> you could use it safely for TLUV would not mean we should add that opcode
> if there's some way of using it negatively.
>
> Cheers,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
>
>
> On Tue, Apr 12, 2022 at 10:33 AM Jeremy Rubin <jeremy.l.rubin at gmail.com>
> wrote:
>
>> Sharing below a framework for thinking about covenants. It is most useful
>> for modeling local covenants, that is, covenants where only one coin must
>> be examined, and not multi-coin covenants whereby you could have issues
>> with protocol forking requiring a more powerful stateful prover. It's the
>> model I use in Sapio.
>>
>> I define a covenant primitive as follows:
>>
>> 1) A set of sets of transaction intents (a *family)*, potentially
>> recursive or co-recursive (e.g., the types of state transitions that can be
>> generated). These intents can also be represented by a language that
>> generates the transactions, rather than the literal transactions
>> themselves. We do the family rather than just sets at this level because to
>> instantiate a covenant we must pick a member of the family to use.
>> 2) A verifier generator function that generates a function that accepts
>> an intent that is any element of one member of the family of intents and a
>> proof for it and rejects others.
>> 3) A prover generator function that generates a function that takes an
>> intent that is any element of one member of the family and some extra data
>> and returns either a new prover function, a finished proof, or a rejection
>> (if not a valid intent).
>> 4) A set of proofs that the Prover, Verifier, and a set of intents are
>> "impedance matched", that is, all statements the prover can prove and all
>> statements the verifier can verify are one-to-one and onto (or something
>> similar), and that this also is one-to-one and onto with one element of the
>> intents (a set of transactions) and no other.
>> 5) A set of assumptions under which the covenant is verified (e.g., a
>> multi-sig covenant with at least 1-n honesty, a multisig covenant with any
>> 3-n honesty required, Sha256 collision resistance, DLog Hardness, a SGX
>> module being correct).
>>
>> To instantiate a covenant, the user would pick a particular element of
>> the set of sets of transaction intents. For example, in TLUV payment pool,
>> it would be the set of all balance adjusting transactions and redemptions. *Note,
>> we can 'cleave' covenants into separate bits -- e.g. one TLUV + some extra
>> CTV paths can be 'composed', but the composition is not guaranteed to be
>> well formed.*
>>
>> Once the user has a particular intent, they then must generate a verifier
>> which can receive any member of the set of intents and accept it, and
>> receive any transaction outside the intents and reject it.
>>
>> With the verifier in hand (or at the same time), the user must then
>> generate a prover function that can make a proof for any intent that the
>> verifier will accept. This could be modeled as a continuation system (e.g.,
>> multisig requires multiple calls into the prover), or it could be
>> considered to be wrapped as an all-at-once function. The prover could be
>> done via a multi-sig in which case the assumptions are stronger, but it
>> still should be well formed such that the signers can clearly and
>> unambiguously sign all intents and reject all non intents, otherwise the
>> covenant is not well formed.
>>
>> The proofs of validity of the first three parts and the assumptions for
>> them should be clear, but do not require generation for use. However,
>> covenants which do not easily permit proofs are less useful.
>>
>> We now can analyze three covenants under this, plain CTV, 2-3 online
>> multisig, 3-3 presigned + deleted.
>>
>> CTV:
>> 1) Intent sets: the set of specific next transactions, with unbound
>> inputs into it that can be mutated (but once the parent is known, can be
>> filled in for all children).
>> 2) Verifier: The transaction has the hash of the intent
>> 3) Prover: The transaction itself and no other work
>> 4) Proofs of impedance: trivial.
>> 5) Assumptions: sha256
>> 6) Composition: Any two CTVs can be OR'd together as separate leafs
>>
>> 2-3 Multisig:
>> 1) Intent: All possible sets of transactions, one set selected per
>> instance
>> 2) Verifier: At least 2 signed the transition
>> 3) Prover: Receive some 'state' in the form of business logic to enforce,
>> only sign if that is satisfied. Produce a signature.
>> 4) Impedance: The business logic must cover the instance's Intent set and
>> must not be able to reach any other non-intent
>> 5) Assumptions: at least 2 parties are 'honest' for both liveness and for
>> correctness, and the usual suspects (sha256, schnorr, etc)
>> 6) Composition: Any two groups can be OR'd together, if the groups have
>> different signers, then the assumptions expand
>>
>> 3-3 Presigned:
>> Same as CTV except:
>> 5) Assumptions: at least one party deletes their key after signing
>>
>>
>> You can also think through other covenants like TLUV in this model.
>>
>> One useful question is the 'cardinality' of an intent set. The useful
>> notion of this is both in magnitude but also contains. Obviously, many of
>> these are infinite sets, but if one set 'contains' another then it is
>> definitionally more powerful. Also, if a set of transitions is 'bigger'
>> (work to do on what that means?) than another it is potentially more
>> powerful.
>>
>> Another question is around composition of different covenants inside of
>> an intent -- e.g., a TLUV that has a branch with a CTV or vice versa. We
>> consider this outside the model, analysis should be limited to "with only
>> these covenants what could you build". Obviously, one recursive primitive
>> makes all primitives recursive.
>>
>> Another question is 'unrollability'. Can the intents, and the intents of
>> the outputs of the intents, be unrolled into a representation for a
>> specific instantiation? Or is that set of possible transactions infinite?
>> How infinite? CTV is, e.g., unrollable.
>>
>>
>> Last note on statefulness: The above has baked into it a notion of
>> 'statelessness', but it's very possible and probably required that provers
>> maintain some external state in order to prove (whether multisig or not).
>> E.g., a multisig managing an account model covenant may need to track who
>> is owed what. This data can sometimes be put e.g. in an op return, an extra
>> tapleaf branch, or just considered exogenous to the covenant. But the idea
>> that a prover isn't just deciding on what to do based on purely local
>> information to an output descriptor is important.
>>
>>
>> For Sapio in particular, this framework is useful because if you can
>> answer the above questions on intents, and prover/verifier generators, then
>> you would be able to generate tooling that could integrate your covenant
>> into Sapio and have things work nicely. If you can't answer these questions
>> (in code?) then your covenant might not be 'well formed'. The efficiency of
>> a prover or verifier is out of scope of this framework, which focuses on
>> the engineering + design, but can also be analyzed.
>>
>>
>> Grateful for any and all feedback on this model and if there are examples
>> that cannot be described within it,
>>
>> Jeremy
>>
>>
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>
> _______________________________________________
> 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/20220518/68ca4404/attachment-0001.html>;

📅 Original date posted:2022-05-09 📝 Original message:> ...

2023-06-07T23:09:24Z

In reply to nevent1q…zyee
_________________________

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

> > This requires *recursive* covenants.

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

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

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

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

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

Keagan

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

> > This requires *recursive* covenants.
>
> Actually, for practical use, any walled-garden requires *dynamic*
> covenants, not recursive covenants. CTV can get arbitrarily close to
> recursive covenants, because you can have an arbitrarily long string of
> covenants. But this doesn't help someone implement visacoin because CTV
> only allows a specific predefined iteration of transactions, meaning that
> while "locked" into the covenant sequence, the coins can't be used in any
> way like normal coins - you can't choose who you pay, the sequence is
> predetermined.
>
> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>;)
> don't automatically allow for practical walled gardens. Recursion
> definitely allows creating walled gardens, but those gardens would be
> impractically static. You could add millions of potential addresses to send
> to, which would "only" quadruple the size of your transactions, but if
> anyone creates a new address you want to send to, you wouldn't be able to.
> Everyone would have to have a single address whitelisted into every
> government-bitcoin output. If someone lost their key and needs to create a
> new wallet, suddenly no one would be able to pay them.
>
> In order to really build a wallet garden, infinite recursion isn't really
> necessary nor sufficient. You need to be able to dynamically specify
> destination addresses. For example, if you were a government that wants to
> make a walled garden where you (the government) could confiscate the funds
> whenever you wanted, you'd have to have a covenant that allows the end-user
> to specify an arbitrary public key to send money to. The covenant might
> require that user to send to another covenant that has a government spend
> path, but also has a spend path for that user-defined public key. That way,
> you (the government) could allow people to send to each other arbitrarily,
> while still ensuring that you (the government) could spend the funds no
> matter where they may have been sent. Even without recursive covenants, you
> could have arbitrarily long chains of these, say 1 million long, where at
> the end of the chain the user must send your coins back to the government
> who can then send them back with another million-long chain of covenants to
> work with.
>
> OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf>; can
> do this kind of dynamicness, and OP_PUSHOUTPUTSTACK
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>; can
> enable it for things like OP_TLUV and OP_CD. I personally think dynamic
> covenants are a *good* thing, as it enables more secure wallet vaults,
> among other things. And I'm not worried about a government creating a
> in-bitcoin visa-coin. Why? Because they can already do it today. They have
> been able to do it for 9 years already. How?
>
> Replace the covenant above with a multisig wallet. The government has 2
> keys, you have 1 key. Every time you make a transaction, you request the
> government's signature on it. The government then only signs if you're
> sending to a wallet they approve of. They might only sign when you're
> sending to another multisig wallet that the government has 2 of 3 keys for.
> Its a very similar walled garden, where the only difference is that the
> government needs to actively sign, which I'm sure wouldn't be a huge
> challenge for the intrepid dictator of the land. You want to add
> demurage fees? Easy, the government just spends the fee out of everyone's
> wallets every so often.
>
> On the other hand, OP_CTV *cannot* be used for such a thing. No
> combination of future opcodes can enable either recursion or dynamicness to
> an OP_CTV call.
>
>
>
> On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Jorge,
>>
>> > I think people may be scared of potential attacks based on covenants.
>> For example, visacoin.
>> > But there was a thread with ideas of possible attacks based on
>> covenants.
>> > To me the most scary one is visacoin, specially seeing what happened in
>> canada and other places lately and the general censorship in the west, the
>> supposed war on "misinformation" going on (really a war against truth imo,
>> but whatever) it's getting really scary. But perhaps someone else can be
>> more scared about a covenant to add demurrage fees to coins or something, I
>> don't know.
>> > https://bitcointalk.org/index.php?topic=278122
>>
>> This requires *recursive* covenants.
>>
>> At the time the post was made, no distinction was seen between recursive
>> and non-recursive covenants, which is why the post points out that
>> covenants suck.
>> The idea then was that anything powerful enough to provide covenants
>> would also be powerful enough to provide *recursive* covenants, so there
>> was no distinction made between recursive and non-recursive covenants (the
>> latter was thought to be impossible).
>>
>> However, `OP_CTV` turns out to enable sort-of covenants, but by
>> construction *cannot* provide recursion.
>> It is just barely powerful enough to make a covenant, but not powerful
>> enough to make *recursive* covenants.
>>
>> That is why today we distinguish between recursive and non-recursive
>> covenant opcodes, because we now have opcode designs that provides
>> non-recursive covenants (when previously it was thought all covenant
>> opcodes would provide recursion).
>>
>> `visacoin` can only work as a recursive covenant, thus it is not possible
>> to use `OP_CTV` to implement `visacoin`, regardless of your political views.
>>
>> (I was also misinformed in the past and ignored `OP_CTV` since I thought
>> that, like all the other covenant opcodes, it would enable recursive
>> covenants.)
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> 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/20220509/bfc87453/attachment.html>;

📅 Original date posted:2022-04-27 📝 Original ...

2023-06-07T23:08:30Z

In reply to nevent1q…7uqe
_________________________

📅 Original date posted:2022-04-27
📝 Original message:Felipe,

> For me, the consensus should follow the current line: discussions and
tests carried out by experts. We all know that the most important devs have
the most weight in discussions. And that's how it should be, because they
understand far better than any other lowly mortal. Consensus simply means
that there are not at least two or three important people opposing the idea
with solid arguments. Is it very subjective and difficult? Yes. For sure.
We all yearn for objective answers or methods. However, any method would
fail. At the end, after numerous discussions and an apparent consensus, the
objective answer and the real consensus will be obtained in the network, in
the nodes upgrading. If there is a big war, the network will end up
splitting in two, as it has in the past. To avoid any unwanted splits we
discuss for exhaustion here in the list.

This is essentially an admission that devs have control over the protocol.
Users "having control" but deferring their judgement to devs is not
meaningfully different than devs "having control". Many people have
asserted, quite strongly, that this ought not be how Bitcoin governs
itself. I myself am on the fence about what is practically possible or not.
However, let's say that your supposition is correct. How would we protect
against a corollary scenario where a dev has a proposal that looks great
but has dark ends that no one notices yet, if the process for evaluation
more or less is to defer to "the most important devs" expertise? Presumably
we hash this out in forums like this, but in order to "override" the "most
important devs" we have to have a way (formalized or not) of deciding when
the "lesser experts" in aggregate have better judgement.

Erik,

> There are many challenges with on-chain voting, here are a few:

This may be hair-splitting but I feel it important to clarify that my
proposal isn't voting per se. Calling it that doesn't bug me, but the
mechanics are meaningfully different than a simple tally vote which is the
intuition that I think that term conveys. As Billy mentions this proposal
actually requires that miners block signals from inclusion in the block if
they themselves do not signal. I'm not necessarily claiming this is a
superior design overall, however the "flaw" you point out is by design in
this case. My goal in the proposal was really to give users a means of
applying direct economic pressure to miners, who do inevitably play a role
in BIP8/BIP9 activation procedure.

Ryan,

> - you're feeding the Chainalysis beasts, when hodlers move their UTXOs;

Definitely a frightening proposition I hadn't considered. It does open up
the possibility of tracking individual preferences and targeting of
political opponents.

> - yuk, it's voting.

I don't think the process of collecting information on user preference is
in and of itself bad. Where I think Bitcoiners really want to avoid voting
is this notion that 51% of the constituency can bully the other 49% into
whatever they want. No part of my proposal suggests this, nor is it
something I would want.

-----

I think there are a few questions surrounding the issue of soft fork
activation. Perhaps it warrants zooming out beyond even what my proposal
aims to solve. In my mind the most important questions surrounding this
process are:

1. In an ideal world, assuming we could, with perfect certainty, know
anything we wanted about the preferences of the user base, what would be
the threshold for saying "this consensus change is ready for activation"?
1a. Does that threshold change based on the nature of the consensus
change (new script type/opcode vs. block size reduction vs. blacklisting
UTXOs)?
1b. Do different constituencies (end users, wallets, exchanges,
coinjoin coordinators, layer2 protocols, miners) have a desired minimum or
maximum representation in this "threshold"?
2. Given an answer from #1, what tests can we devise to measure those
levels of support directly? If we can't measure it directly, can we measure
different indicators that would help us infer or solve for the knowledge we
want?
3. Can any of the answers to #2 be "gamed"? I'm defining "game" here to
mean that the measurement taken, diverges from the ground truth we are
trying to get at in such a way that its divergence would be undetectable.

If we do not answer these sorts of questions we can get technical consensus
through this messy process, but when it comes to assessing user consensus,
it is just going to devolve into dogma and demagoguery as we each have our
own perceptions or agendas and there is no rigorous way for anyone to
refute our claims. This would, again, be an admission that devs ultimately
do make protocol decisions. Perhaps it's unavoidable and we are doomed to
this painful process of arguing with one another until there's only one
opinion left standing (either because of merit or just plain old grit).
However, if this is the case, I don't think we can honestly claim that devs
don't control the protocol (as a group).

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

Keagan

On Wed, Apr 27, 2022 at 11:22 AM <micaroni at gmail.com> wrote:

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

2023-06-07T23:07:49Z

In reply to nevent1q…s6tw
_________________________

📅 Original date posted:2022-04-21
📝 Original message:Good day Michael,

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

This seems silly to me.

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

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

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

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

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

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

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

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

Feel free to resist this if you want. In some sense that's what the Speedy
Trial procedure is for. However, I think your case would be more compelling
if you actually had some sort of affirmative argument for why CTV induces
systemic risk to non-users of the opcode. Expressing uncertainty over
whether it is the globally optimal solution (to a problem that cannot be
globally defined due to diverse interests) is not persuasive to me and many
others in the community.

Keagan

On Thu, Apr 21, 2022 at 12:16 PM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Ok so we've had to scramble a bit as I don't think anyone except perhaps
> Jeremy thought that there would be a Speedy Trial signaling period for a
> CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>
> (I have to take what he says at face value. I can understand why one would
> be skeptical.)
>
> Understandably this has angered and surprised a few people including some
> of those who have voiced opposition to a CTV soft fork activation being
> attempted in the first place [2].
>
> As I've said in a previous post [3] the Bitcoin Core 23.0 release
> candidate (and older versions) does not include any CTV code or CTV
> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not
> signal for CTV. If by some chance CTV was to activate through some other
> software release Bitcoin Core releases would not apply CTV rules but they
> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to
> prepare for an eventuality where the miner signaling threshold might be
> reached but the community wants to prevent the attempted soft fork from
> activating. (I personally don't think a 90 percent miner signaling
> threshold will be reached but I wouldn't want to bet Bitcoin's future on
> it.)
>
> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but
> I'm open to better names. I certainly don't want to discourage those who
> dislike or oppose UASFs from contributing to this effort and potentially
> ultimately running a URSF release. If you don't want this rushed CTV soft
> fork to activate we are all on the same side whatever we call it.
>
> For now I've set up a ##ursf channel on Libera IRC to monitor developments
> and discuss working on an additional release that if run may ultimately
> reject blocks that signal for CTV.
>
> The intention of this would be to provide additional direction and
> incentive to miners that the community does not want this soft fork to be
> activated. To repeat running a Bitcoin Core release will not signal for a
> CTV soft fork out the box. If a miner runs a Bitcoin Core release it will
> not signal for CTV.
>
> Apologies that this is rushed. But as always with Jeremy caution and
> conservatism seems to be thrown out the window and we have to react to
> that. It goes without saying that this is not how Bitcoin consensus changes
> should be attempted.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
> [2]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> [3]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.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/20220421/9b2b5a9c/attachment-0001.html>;

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

2023-06-07T23:07:06Z

In reply to nevent1q…d5z2
_________________________

📅 Original date posted:2022-04-25
📝 Original message:> BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period.

Thanks for the clarification.

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

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

Keagan

On Mon, Apr 25, 2022 at 11:00 AM Anthony Towns <aj at erisian.com.au> wrote:

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

2023-06-07T23:01:44Z

In reply to nevent1q…82mn
_________________________

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

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

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

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

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

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

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

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

It is quite likely less damaging to consensus to have frequent but strictly
sequenced soft forks so that if one of the new rules is contentious the
break can happen cleanly. That said, if Core or any other client wishes to
cut a release of the software with the parameters bundled into a single
release, that is a significantly more palatable state of affairs, as you
can still pipeline signaling and activation. However, the protocol itself
adopting a tendency to activate unrelated proposals in bundles is a recipe
for disaster.

Respectfully,
Keagan

[1] https://www.truthcoin.info/blog/protocol-upgrade-terminology

On Sat, Oct 16, 2021 at 12:57 PM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> > Interesting discussion. Correct me if I'm wrong: but putting too many
> features together in one shot just can't make things harder to debug in
> production if something very unexpected happens. It's a basic principle
> of software engineering.
>
> Soft fork features can (and should) obviously be tested thoroughly on
> testnet, signet, custom signets, sidechains etc on a standalone basis and a
> bundled basis. But whether or not it is a basic principle of general
> software engineering kind of misses the point. Security critical software
> clearly isn't engineered in the same way as a new social media app. Bugs
> are easily reverted in a new social media app. A consensus change is
> extremely hard to revert and probably requires a hard fork, a level of
> central coordination we generally attempt to avoid and a speed of
> deployment that we also attempt to avoid. On top of that we aren't just
> dealing with security critical software. One of the most important
> objectives is to keep all the nodes on the network in consensus.
> Introducing a consensus change before we are comfortable there is community
> consensus for it is a massive effective bug in itself. The network can
> split in multiple ways e.g. part of the network disagrees on whether to
> activate the consensus change, part of the network disagrees on how to
> resist that consensus change, part of the network disagrees on how to
> activate that consensus change etc
>
> In addition, a social media app can experiment in production whether
> Feature A works, whether Feature B works or whether Feature A and B work
> best together. In Bitcoin if we activate consensus Feature A, later decide
> we want consensus Feature B but find out that by previously activating
> Feature A we can't have Feature B (it is now unsafe to activate it) or its
> design now has to be suboptimal because we have to ensure it can safely
> work in the presence of Feature A we have made a mistake by activating
> Feature A in the first place. Decentralized security critical consensus
> changes are an emerging field in itself and really can't be treated like
> any other software project. This will become universally understood I'm
> sure over time.
>
> --Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Interesting discussion. Correct me if I'm wrong: but putting too many
> features together in one shot just can't make things harder to debug in
> production if something very unexpected happens. It's a basic principle
> of software engineering.
>
> Change. Deploy. Nothing bad happened? Change it a little more. Deployment.
> Or: Change, change, change. Deploy. Did something bad happen? What change
> caused the problem?
>
> On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote:
>> > > ... in this post I will argue against frequent soft forks with a
>> single or
>> > minimal
>> > > set of features and instead argue for infrequent soft forks with
>> batches
>> > > of features.
>> > I think this type of development has been discussed in the past and has
>> been
>> > rejected.
>>
>> > AJ: - improvements: changes might not make everyone better off, but we
>> > don't want changes to screw anyone over either -- pareto
>> > improvements in economics, "first, do no harm", etc. (if we get this
>> > right, there's no need to make compromises and bundle multiple
>> > flawed proposals so that everyone's an equal mix of happy and
>> > miserable)
>>
>> I don't think your conclusion above matches my opinion, for what it's
>> worth.
>>
>> If you've got two features, A and B, where the game theory is:
>>
>> If A happens, I'm +100, You're -50
>> If B happens, I'm -50, You're +100
>>
>> then even though A+B is +50, +50, then I do think the answer should
>> generally be "think harder and come up with better proposals" rather than
>> "implement A+B as a bundle that makes us both +50".
>>
>> _But_ if the two features are more like:
>>
>> If C happens, I'm +100, You're +/- 0
>> If D happens, I'm +/- 0, You're +100
>>
>> then I don't have a problem with bundling them together as a single
>> simultaneous activation of both C and D.
>>
>> Also, you can have situations where things are better together,
>> that is:
>>
>> If E happens, we're both at +100
>> If F happens, we're both at +50
>> If E+F both happen, we're both at +9000
>>
>> In general, I think combining proposals when the combination is better
>> than the individual proposals were is obviously good; and combining
>> related proposals into a single activation can be good if it is easier
>> to think about the ideas as a set.
>>
>> It's only when you'd be rejecting the proposal on its own merits that
>> I think combining it with others is a bad idea in principle.
>>
>> For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx
>> and CHECKSIGADD together because they do have synergies like that; we
>> didn't bundle ANYPREVOUT and graftroot despite the potential synergies
>> because those features needed substantially more study.
>>
>> The nulldummy soft-fork (bip 147) was deployed concurrently with
>> the segwit soft-fork (bip 141, 143), but I don't think there was any
>> particular synergy or need for those things to be combined, it just
>> reduced the overhead of two sets of activation signalling to one.
>>
>> Note that the implementation code for nulldummy had already been merged
>> and were applied as relay policy well before activation parameters were
>> defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becoming
>> an active soft fork.
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> 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/20211230/6bc5d2f3/attachment-0001.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-18 📝 Original ...

2023-06-07T22:53:46Z

In reply to nevent1q…xgu3
_________________________

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

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

Keagan

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

> > Ultimately all currency security derives from energy consumption.
> > Everything eventually resolves down to proof-of-work.
> This is ideology. Yes, without energy and work, not many things happen.
> But the amounts of energy and work to achieve a goal vary widely. Detailed
> analysis comparing one alternative with the other in depth is required.
> And I would not look for order-of-magnitude improvements, 25% better is
> also a big deal, if discovered.
>
> > * Proof-of-space simply moves the work to the construction of more
> storage devices.
> One needs a cost/benefit analysis, not just an account of the cost. For
> example, if PoW could do calculations that are otherwise useful (maybe
> solve a queue of standardized math-jobs, such as climate simulations) there
> would be more benefit, or, let's say the data storage in proof-of-space is
> useful.
>
> > * Proof-of-stake simply moves the work to stake-grinding attacks.
> Simply not true, there are PoS implementations that are immune to
> stake-grinding attacks, and even where not, the possible amount of
> computations is limited compared to PoW
>
> > * The optical proof-of-work simply moves the work to the construction of
> more miners.
> The idea was to shift from energy to cap-ex. We can get a
> financial penalty for misbehavior from three sources:
> - cost of energy/labor (PoW)
> - cost of capital (PoS)
> - cost of cap-ex
> There might be a better mix than PoW only. I have written code for mixed
> PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense,
> but the environmental impact needs to be analyzed, it could also make it
> worse than just the use of electricity. At least electricity as such does
> not leave waste behind. Mining in orbit with solar power would be totally
> acceptable.
>
> > At least, proof-of-work is honest about its consumption of resources.
> Agreed, but we can't be satisfied with that. If we try hard enough we can
> do better.
>
> Cheers
> Claus
>
> On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> > A few things jump out at me as I read this proposal
>> >
>> > First, deriving the hardness from capex as opposed to opex switches the
>> privilege from those who have cheap electricity to those who have access to
>> chip manufacturers/foundries. While this is similarly the case for Bitcoin
>> ASICS today, the longevity of the PoW algorithm has led to a better
>> distribution of knowledge and capital goods required to create ASICS. The
>> creation of a new PoW of any kind, hurts this dimension of decentralization
>> as we would have to start over from scratch on the best way to build,
>> distribute, and operate these new pieces of hardware at scale. While I have
>> not combed over the PoW proposed here in fine detail, the more complicated
>> the algorithm is, the more it privileges those with specific knowledge
>> about it and the manufacturing process.
>> >
>> > The competitive nature of Bitcoin mining is such that miners will be
>> willing to spend up to their expected mining reward in their operating
>> costs to continue to mine. Let's suppose that this new PoW was adopted,
>> miners will continue to buy these chips in ever increasing quantities,
>> turning the aforementioned CAPEX into a de facto OPEX. This has a few
>> consequences. First it just pushes the energy consumption upstream to the
>> chip manufacturing process, rather than eliminating it. And it may trade
>> some marginal amount of the energy consumption for the set of resources it
>> takes to educate and create chip manufacturers. The only way to avoid that
>> cost being funneled back into more energy consumption is to make the
>> barrier to understanding of the manufacturing process sufficiently
>> difficult so as to limit the proliferation of these chips. Again, this
>> privileges the chip manufacturers as well as those with close access to the
>> chip manufacturers.
>> >
>> > As far as I can tell, the only thing this proposal actually does is
>> create a very lucrative business model for those who sell this variety of
>> chips. Any other effects of it are transient, and in all likelihood the
>> transient effects create serious centralization pressure.
>> >
>> > At the end of the day, the energy consumption is foundational to the
>> system. The only way to do away with authorities, is to require
>> competition. This competition will employ ever more resources until it is
>> unprofitable to do so. At the base of all resources of society is energy.
>> You get high energy expenditure, or a privileged class of bitcoin
>> administrators: pick one. I suspect you'll find the vast majority of
>> Bitcoin users to be in the camp of the energy expenditure, since if we pick
>> the latter, we might as well just pack it in and give up on the Bitcoin
>> experiment.
>>
>>
>> Keagan is quite correct.
>> Ultimately all currency security derives from energy consumption.
>> Everything eventually resolves down to proof-of-work.
>>
>> * Proof-of-space simply moves the work to the construction of more
>> storage devices.
>> * Proof-of-stake simply moves the work to stake-grinding attacks.
>> * The optical proof-of-work simply moves the work to the construction of
>> more miners.
>> * Even government-enforced fiat is ultimately proof-of-work, as the
>> operation and continued existence of any government is work.
>>
>> It is far better to move towards a more *direct* proof-of-work, than to
>> add more complexity and come up with something that is just proof-of-work,
>> but with the work moved off to somewhere else and with additional moving
>> parts that can be jammed or hacked into.
>>
>> When considering any new proof-of-foo, it is best to consider all effects
>> until you reach the base physics of the arrow of time, at which point you
>> will realize it is ultimately just another proof-of-work anyway.
>>
>> At least, proof-of-work is honest about its consumption of resources.
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> 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/20210518/8db39423/attachment-0001.html>;

📅 Original date posted:2021-05-17 📝 Original message:A few ...

2023-06-07T22:53:39Z

In reply to nevent1q…n8e7
_________________________

📅 Original date posted:2021-05-17
📝 Original message:A few things jump out at me as I read this proposal

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

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

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

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

Keagan

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

> Hi Bitcoin Devs,
>
> We would like to share with you a draft proposal for a durable, low
> energy Bitcoin proof of work.
>
> ----
>
> <pre>
> BIP: ?
> Title: Durable, Low Energy Bitcoin PoW
> Author: Michael Dubrovsky <mike+bip[at]powx.org>, Bogdan Penkovsky
> <bogdan+bip[at]powx.org>
> Discussions-To: <mike+bip[at]powx.org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/PoWx-Org/obtc/wiki/BIP
> Status: Draft
> Type: Standards Track
> Created: 2021-05-13
> License: BSD-2-Clause
> OPL
> </pre>
>
>
> == Simple Summary ==
>
> Bitcoin's energy consumption is growing with its value (see Figure below).
> Although scaling PoW is necessary to maintain the security of the network,
> reliance on massive energy consumption has scaling drawbacks and leads to
> mining
> centralization. A major consequence of the central role of local
> electricity
> cost in mining is that today, most existing and potential participants in
> the
> Bitcoin network cannot profitably mine Bitcoin even if they have the
> capital to
> invest in mining hardware. From a practical perspective, Bitcoin adoption
> by
> companies like Tesla (which recently rescinded its acceptance of Bitcoin as
> payment) has been hampered by its massive energy consumption and perceived
> environmental impact.
>
> [[ ]]
>
> Figure. Bitcoin price and estimated Bitcoin energy consumption.
> Data sources: [https://cbeci.org Cambridge Bitcoin Electricity
> Consumption Index], [https://www.coindesk.com CoinDesk].
>
> We propose a novel proof-of-work paradigm for Bitcoin--Optical
> proof-of-work. It
> is designed to decouple Bitcoin mining from energy and make it feasible
> outside
> of regions with low electricity costs. ''Optical proof-of-work'' (oPoW) is
> a
> modification of Hashcash that is most efficiently computed using a new
> class of
> photonic processors. Without compromising the cryptographic or
> game-theoretical
> security of Hashcash, oPoW shifts the operating expenses of mining (OPEX),
> to
> capital expenses (CAPEX)--i.e. electricity to hardware. oPoW makes it
> possible
> for billions of new miners to enter the market simply by investing in a
> low-energy photonic miner. Shifting to a high-CAPEX PoW has the added
> benefit of
> making the hashrate resilient to Bitcoin's price fluctuations - once
> low-OPEX
> hardware is operating there is no reason to shut it down even if the value
> of
> mining rewards diminishes. oPoW is backward compatible with GPUs, FPGAs,
> and
> ASICs meaning that a transitional period of optical and traditional
> hardware
> mining in parallel on the network is feasible
>
> More information is available here: [https://www.powx.org/opow].
>
> == Abstract ==
>
> As Bitcoin gained utility and value over the preceding decade, the
> network incentivized the purchase of billions of dollars in mining
> equipment and electricity. With the growth of competition, home mining
> became unprofitable. Even the most sophisticated special-purpose
> hardware (ASIC miners) doesn’t cover its energy costs unless the miner
> also has direct access to very cheap electricity. This heavy reliance
> on energy makes it difficult for new miners to enter the market and
> leads to hashrate instability as miners shut off their machines when
> the price of Bitcoin falls. Additionally as the network stores ever
> more value, the percentage of world energy consumption that is
> associated with Bitcoin continues to grow, creating the potential for
> scaling failure and a general backlash. To ensure that Bitcoin can
> continue scaling and reach its full potential as a world currency and
> store of value, we propose a low-energy proof-of-work paradigm for
> Bitcoin. ''Optical proof of work (oPoW)'' is designed to decouple
> Bitcoin’s security from massive energy use and make bitcoin mining
> feasible outside of regions with low electricity costs. ''Optical
> proof-of-work'' is a modification of Hashcash that is most efficiently
> computed using a new class of photonic processors that has emerged as
> a leading solution for ultra-low energy computing over the last 5
> years. oPoW shifts the operating expenses of mining (OPEX), to capital
> expenses (CAPEX)–i.e. electricity to hardware, without compromising
> the cryptographic or game-theoretical security of Hashcash. We provide
> an example implementation of oPoW, briefly discuss its cryptographic
> construction as well as the working principle of photonic processors.
> Additionally, we outline the potential benefits of oPoW to the bitcoin
> network, including geographic decentralization and democratization of
> mining as well as hashrate resilience to price fluctuations.
>
> == Copyright ==
>
> This BIP is dual-licensed under the Open Publication License and BSD
> 2-clause license.
>
> == Motivation ==
>
> As Bitcoin has grown over the past decade from a small network run by
> hobbyists to a global currency, the underlying Proof of Work protocol
> has not been updated. Initially pitched as a global decentralized
> network (“one CPU-one vote”), Bitcoin transactions today are secured
> by a small group of corporate entities. In practice, it is only
> feasible for [http://archive.is/YeDwh entities that can secure access
> to abundant, inexpensive energy]. The economics of mining limit
> profitability to places like Iceland, Texas, or Western China. Besides
> the negative environmental externalities, which may be significant,
> mining today is performed primarily with the consent (and in many
> cases, partnership) of large public utilities and the governments that
> control them. Although this may not be a problem in the short term, in
> the long term it stands to erode the censorship resistance and
> security of Bitcoin and other public blockchains through potential
> regulation or [https://arxiv.org/pdf/1605.07524.pdf partitioning
> attacks].
>
> Recent events, such as the
> [https://twitter.com/MustafaYilham/status/1384278267067203590 ~25%
> hashrate crash due to coal-powered grid failure in china] and Tesla’s
> rescinding of its acceptance of Bitcoin as a form of payment, show
> that there are practical real-world downsides to Proof of Works’s
> massive reliance on energy.
>
> [[ ]]
>
> Whether on not the Bitcoin community accepts this common criticism as
> entirely valid, it has real-world effects which will only get worse
> over time. Eliminating the exponentially growing energy use currently
> built into Bitcoin without eliminating the security of PoW would be
> ideal and should not be a partisan issue.
>
> New consensus mechanisms have been proposed as a means of securing
> cryptocurrencies whilst reducing energy cost, such as various forms of
> Proof of Stake and Proof of Space-Time. While many of these
> alternative mechanisms offer compelling guarantees, they generally
> require new security assumptions, which have not been stress-tested by
> live deployments at any adequate scale. Consequently, we still have
> relatively little empirical understanding of their safety. Completely
> changing the Bitcoin paradigm is likely to introduce new unforeseen
> problems. We believe that the major issues discussed above can be
> resolved by improving rather than eliminating Bitcoin’s fundamental
> security layer—Proof of Work. Instead of devising a new consensus
> architecture to fix these issues, it is sufficient to shift the
> economics of PoW. The financial cost imposed on miners need not be
> primarily composed of electricity. The situation can be significantly
> improved by reducing the operating expense (OPEX)—energy—as a major
> mining component. Then, by shifting the cost towards capital expense
> (CAPEX)—mining hardware—the dynamics of the mining ecosystem becomes
> much less dependent on electricity prices, and much less electricity
> is consumed as a whole.
>
> Moreover, a reduction in energy consumption automatically leads to
> geographically distributed mining, as mining becomes profitable even
> in regions with expensive electricity. Additionally, lower energy
> consumption will eliminate heating issues experienced by today’s
> mining operations, which will further decrease operating cost as well
> as noise associated with fans and cooling systems. All of this means
> that individuals and smaller entities would be able to enter the
> mining ecosystem simply for the cost of a miner, without first gaining
> access to cheap energy or a dedicated, temperature-controlled data
> center. To a degree, memory-hard PoW schemes like
> [https://github.com/tromp/cuckoo Cuckoo Cycle], which increase the use
> of SRAM in lieu of pure computation, push the CAPEX/OPEX ratio in the
> right direction by occupying ASIC chip area with memory. To maximize
> the CAPEX to OPEX ratio of the Optical Proof of Work algorithm, we
> developed [https://assets.pubpub.org/xi9h9rps/01581688887859.pdf
> ''HeavyHash''] [1]. HeavyHash is a cryptographic construction that
> takes the place of SHA256 in Hashcash. Our algorithm is compatible
> with ultra-energy-efficient photonic co-processors that have been
> developed for machine learning hardware accelerators.
>
> HeavyHash uses a proven digital hash (SHA3) packaged with a large
> amount of MAC (Multiply-and-Accumulate) computation into a Proof of
> Work puzzle. Although HeavyHash can be computed on any standard
> digital hardware, it becomes hardware efficient only when a small
> digital core is combined with a low-power photonic co-processor for
> performing MAC operations. oPoW mining machines will have a small
> digital core flip-chipped onto a large, low-power photonic chip. This
> core will be bottlenecked by the throughput of the digital to analog
> and analog to digital converters. A prototype of such analogue optical
> matrix multiplier can be seen in the figure below.
>
> [[ ]]
>
> Figure. TOP: Photonic Circuit Diagram, A. Laser input (1550nm, common
> telecom wavelength) B. Metal pads for controlling modulators to
> transduce electrical data to optical C. Metal pads for tuning mesh of
> directional couplers D. Optical signal exits here containing the
> results of the computation and is output to fibers via a grating
> coupler the terminus of each waveguide. E. Alignment circuit for
> aligning fiber coupling stage. Bottom: a photograph of a bare oPoW
> miner prototype chip before wire and fiber bonding. On the right side
> of the die are test structures (F).
>
> The ''HeavyHash'' derives its name from the fact that it is bloated or
> weighted with additional computation. This means that a cost
> comparable oPoW miner will have a much lower nominal hashrate compared
> to a Bitcoin ASIC (HeavyHashes/second vs. SHA256 Hashes/second in
> equivalent ASIC). We provide the cryptographic security argument of
> the HeavyHash function in Section 3 in
> [https://assets.pubpub.org/xi9h9rps/01581688887859.pdf Towards Optical
> Proof of Work] [1]. In the article, we also provide a game-theoretic
> security argument for CAPEX-heavy PoW. For additional information, we
> recommend reading
> [
> https://uncommoncore.co/wp-content/uploads/2019/10/A-model-for-Bitcoins-security-and-the-declining-block-subsidy-v1.02.pdf
> this article].
>
> While traditional digital hardware relies on electrical currents,
> optical computing uses light as the basis for some of or all of its
> operations. Building on the development and commercialization of
> silicon photonic chips for telecom and datacom applications, modern
> photonic co-processors are silicon chips made using well-established
> and highly scalable silicon CMOS processes. However, unlike cutting
> edge electronics which require ever-smaller features (e.g. 5 nm),
> fabricated by exponentially more complex and expensive machinery,
> silicon photonics uses old fabrication nodes (90 nm). Due to the large
> de Broglie wavelength of photons, as compared to electrons, there is
> no benefit to using the small feature sizes. The result is that access
> to silicon photonic wafer fabrication is readily available, in
> contrast to the notoriously difficult process of accessing advanced
> nodes. Moreover, the overall cost of entry is lower as lithography
> masks for silicon photonics processes are an order of magnitude
> cheaper ($500k vs. $5M). Examples of companies developing optical
> processors for AI, which will be compatible with oPoW include
> [https://lightmatter.co/ Lightmatter], [https://www.lightelligence.ai/
> Lightelligence], [https://luminous.co/ Luminous],
> [
> https://www.intel.com/content/www/us/en/architecture-and-technology/silicon-photonics/silicon-photonics-overview.html
> Intel], and other more recent entrants.
>
> == Specification ==
>
> === HeavyHash ===
>
> The HeavyHash is performed in three stages:
>
> # Keccak hash
> # Matrix-vector multiplication
> # Keccak of the result xorred with the hashed input
>
> Note that the most efficiently matrix-vector multiplication is
> performed on a photonic miner. However, this linear algebra operation
> can be performed on any conventional computing hardware (CPU, GPU,
> etc.), therefore making the HeavyHash compatible with any digital
> device.
>
> The algorithm’s pseudo-code:
>
> <pre>// M is a Matrix 64 x 64 of Unsigned 4 values
>
> // 256-bitVector
> x1 <- keccak(input)
>
> // Reshape the obtained bitvector
> // into a 64-vector of unsigned 4-bit values
> x2 <- reshape(x1, 64)
>
> // Perform a matrix-vector multiplication.
> // The result is 64-vector of 14-bit unsigned.
> x3 <- vector_matrix_mult(x2, M)
>
> // Truncate all values to 4 most significant bits.
> // This is due to the specifics of analog
> // computing by the photonic accelerator.
> // Obtain a 64-vector of 4-bit unsigned.
> x4 <- truncate_to_msb(x3, 4)
>
> // Interpret as a 256-bitvector
> x5 <- flatten(x4)
>
> // 256-bitVector
> result <- keccak(xor(x5, x1))</pre>
>
> Which in C can be implemented as:
>
> <pre>
> static void heavyhash(const uint16_t matrix[64][64], void* pdata,
> size_t pdata_len, void* output)
> {
> uint8_t hash_first[32] __attribute__((aligned(32)));
> uint8_t hash_second[32] __attribute__((aligned(32)));
> uint8_t hash_xored[32] __attribute__((aligned(32)));
>
> uint16_t vector[64] __attribute__((aligned(64)));
> uint16_t product[64] __attribute__((aligned(64)));
>
> sha3_256((uint8_t*) hash_first, 32, (const uint8_t*)pdata, pdata_len);
>
> for (int i = 0; i < 32; ++i) {
> vector[2*i] = (hash_first[i] >> 4);
> vector[2*i+1] = hash_first[i] & 0xF;
> }
>
> for (int i = 0; i < 64; ++i) {
> uint16_t sum = 0;
> for (int j = 0; j < 64; ++j) {
> sum += matrix[i][j] * vector[j];
> }
> product[i] = (sum >> 10);
> }
>
> for (int i = 0; i < 32; ++i) {
> hash_second[i] = (product[2*i] << 4) | (product[2*i+1]);
> }
>
> for (int i = 0; i < 32; ++i) {
> hash_xored[i] = hash_first[i] ^ hash_second[i];
> }
> sha3_256((uint8_t*)output, 32, (const uint8_t*)hash_xored, 32);
> }
> </pre>
>
> === Random matrix generation ===
>
> The random matrix M (which is a HeavyHash parameter) is obtained in a
> deterministic way and is changed every block. Matrix M coefficients
> are generated using a pseudo-random number generation algorithm
> (xoshiro) from the previous block header. If the matrix is not full
> rank, it is repeatedly generated again.
>
> An example code to obtain the matrix M:
>
> <pre>
> void generate_matrix(uint16_t matrix[64][64], struct xoshiro_state *state)
> {
> do {
> for (int i = 0; i < 64; ++i) {
> for (int j = 0; j < 64; j += 16) {
> uint64_t value = xoshiro_gen(state);
> for (int shift = 0; shift < 16; ++shift) {
> matrix[i][j + shift] = (value >> (4*shift)) & 0xF;
> }
> }
> }
> } while (!is_full_rank(matrix));
> }
>
> static inline uint64_t xoshiro_gen(struct xoshiro_state *state) {
> const uint64_t result = rotl64(state->s[0] + state->s[3], 23) +
> state->s[0];
>
> const uint64_t t = state->s[1] << 17;
>
> state->s[2] ^= state->s[0];
> state->s[3] ^= state->s[1];
> state->s[1] ^= state->s[2];
> state->s[0] ^= state->s[3];
>
> state->s[2] ^= t;
>
> state->s[3] = rotl64(state->s[3], 45);
>
> return result;
> }
> </pre>
>
> == Discussion ==
>
> === Geographic Distribution of Mining Relative to CAPEX-OPEX Ratio of
> Mining Costs ===
>
> Below is a simple model showing several scenarios for the geographic
> distribution of mining activity relative to the CAPEX/OPEX ratio of
> the cost of operating a single piece of mining hardware. As the ratio
> of energy consumption to hardware cost decreases, geographic
> variations in energy cost cease to be a determining factor in miner
> distribution.
>
> Underlying assumptions: 1. Electricity price y is fixed in time but
> varies geographically. 2. Every miner has access to the same hardware.
> 3. Each miner’s budget is limited by both the cost of mining equipment
> as well as the local cost of the electricity they consume
>
> budget = a(p+ey),
>
> where a is the number of mining machines, p is the machine price, e is
> the total energy consumption over machine lifetime, and y is
> electricity price.
>
> Note that in locations where mining is not profitable, hashrate is zero.
>
> [[ ]]
>
> [[ ]]
>
> [[ ]]
>
>
> An interactive version of this diagram can be found
> [https://www.powx.org/opow here].
>
> === Why does CAPEX to OPEX shift lead to lower energy consumption? ===
>
> A common misconception about oPoW is that it makes mining “cheaper” by
> enabling energy-efficient hardware. There is no impact on the dollar
> cost of mining a block, rather the mix of energy vs. hardware
> investment changes from about 50/50 to 10/90 or better. We discuss
> this at length and rigorously in our paper[1].
>
> === Working Principles of Photonic Processors ===
>
> Photonics accelerators are made by fabricating waveguides in silicon
> using standard lithography processes. Silicon is transparent to
> infrared light and can act as a tiny on-chip fiber optical cable.
> Silicon photonics found its first use during the 2000s in transceivers
> for sending and receiving optical signals via fiber and has advanced
> tremendously over the last decade.
>
> By encoding a vector into optical intensities passing through a series
> of parallel waveguides, interfering these signals in a mesh of tunable
> interferometers (acting as matrix coefficients), and then detecting
> the output using on-chip Germanium photodetectors, a matrix-vector
> multiplication is achieved. A generalized discussion of matrix
> multiplication setups using photonics/interference can be found in
> [https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.73.58 Reck
> et al.] and [https://arxiv.org/abs/1506.06220 Russell et al.] A
> detailed discussion of several integrated photonic architectures for
> matrix multiplication and corresponding tuning algorithms can be found
> in [https://arxiv.org/pdf/1909.06179.pdf Pai et al.]
>
> Below is a conceptual representation of a 3D-packaged oPoW mining
> chip. Note that the majority of the real estate and cost comes from
> the photonic die and the laser, with only a small digital SHA3 die
> needed (as opposed to a conventional miner of the same cost, which
> would have many copies of this die running in parallel).
>
> [[ ]]
>
> === Block Reward Considerations ===
>
> Although it is out of the scope of this proposal, the authors strongly
> recommend the consideration of a change in the block reward schedule
> currently implemented in Bitcoin. There is no clear way to incentivize
> miners with transaction fees only, as has been successfully shown in
> [https://www.cs.princeton.edu/~smattw/CKWN-CCS16.pdf On the
> Instability of Bitcoin Without the Block Reward] and other
> publications, therefore looking a decade or two ahead it will be
> important to implement a fixed block reward or to slow the decay of
> the block reward to maintain the security of the network. Given that
> oPoW miners have low operating costs, once a large number of machines
> are running the reward level sufficient to keep them in operation and
> providing robust security can potentially be significantly smaller
> than in the case of the current SHA256 ASICs securing Bitcoin.
>
> === Implementation on the Bitcoin Network ===
>
> A hard fork is not necessarily required for the Bitcoin network to
> test and eventually implement oPoW. It’s possible to add oPoW as a
> dual PoW to Bitcoin as a soft fork. Tuning the parameters to ensure
> that, for example, 99.9% of the security budget would be earned by
> miners via the SHA256 Hashcash PoW and 0.1% via oPoW would create
> sufficient incentive for oPoW to be stress-tested and to incentivize
> the manufacture of dedicated oPoW miners. If this test is successful,
> the parameters can be tuned continuously over time, e.g. oPoW share
> doubling at every halving, such that oPoW accounts for some target
> percentage (up to 100% in a complete SHA256 phase-out).
>
> == Endnotes ==
>
> With significant progress in optical and analog
> matrix-vector-multiplication chipsets over the last year, we hope to
> demonstrate commercial low-energy mining on our network in the next 6
> months. The current generation of optical matrix processors under
> development is expected to have 10x better energy consumption per MAC
> operation than digital implementations, and we expect this to improve
> by another order of magnitude in future generations.
>
> PoWx will also be publishing the designs of the current optical miner
> prototypes in the near term under an open-source hardware license.
>
> == Acknowledgments ==
>
> We thank all the members of the Bitcoin community who have already
> given us feedback over the last several years as well as others in the
> optical computing community and beyond that have given their input.
>
>
>
>
> [1] M. Dubrovsky et al. Towards Optical Proof of Work, CES conference
> (2020) https://assets.pubpub.org/xi9h9rps/01581688887859.pdf
>
> [2]
> https://sciencex.com/news/2020-05-powering-bitcoin-silicon-photonics-power.html
>
> [3] KISS random number generator
> http://www.cse.yorku.ca/~oz/marsaglia-rng.html
>
>
>
>
> ----
> We have taken into account the moderator's comments we received previously.
>
>
>
> Bogdan and Mike,
>
> PoWx
> _______________________________________________
> 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/20210517/666f63d9/attachment-0001.html>;

📅 Original date posted:2021-05-17 📝 Original message:In ...

2023-06-07T22:53:34Z

In reply to nevent1q…na2n
_________________________

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

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

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

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

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

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

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

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

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

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

Keagan

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

> Hello, list
>
> >Hello centralisation. Might as well just have someone sign miner keys,
> and get
> >rid of PoW entirely...
> >No, it is not centralization -
>
> No, it is not centralization, as:
>
> (a) different miners could use different standards / certifications for
> 'green' status, there are many already;
>
>
> >> That does not refute the claim at all. Just because you can choose from
> multiple centralized authorities, which are well known and can collude, it
> does not mean it is decentralized by any reasonable definition of the term.
>
> (b) it does not affect stability of the network in a material way, rather
> creates small (12.5% of revenue max) incentive to move to green sources of
> energy (or buy carbon credits) and get certified - miners who would choose
> to run dirty energy will still be able to do so.
> and
>
>
> >> Who is to issue these credits? A centralized entity I guess ... There
> is no place for such in Bitcoin.
>
> If I am to concede on the point that *voluntarily* green-status miner
> certification is 'centralization', can you please explain *in detail* why
> aren't 'bitcoin.org' and GitHub repo similar examples of
> 'centralization'? You make a correct point that bitcoin.org and the
> GitHub repo are not 'official' things of Bitcoin network, however nowhere
> in my proposals on green miner certification I was suggesting to introduce
> an 'official' certificate for such a thing. May be I mis-formulated my
> ideas, in that case I apologize:
>
> The only thing which I suggested was to introduce an option to have some
> transactions encrypted in the mempool to allow Bitcoin users some control
> over who mines their transaction - full stop. Users could then decide how
> to use this functionality themselves, and such functionality could have
> uses way beyond 'green miners' - for example, some users might prefer to
> send their transactions *directly to trusted miners* to prevent certain
> quantum computer enabled attacks (e.g. when there is a window of
> opportunity to steal coins if you have fast QC when you spend even from
> p2phk address). Another example - if users are given some flexibility whom
> to send the transactions, they might actually want to steer them away from
> huge mining pools such as Antpool to support small independent miners, smth
> of this sort - which actually would boost diversity in the network.
>
> You may or may not agree that climate change is real, or may or may not
> agree that Bitcoin energy consumption is a problem - I respectfully submit
> it is not the right forum to find truth on these topics. We are discussing
> ideas which *might *make Bitcoin a better solution for users who care
> about certain things, *without *making it worse for somebody else (like
> you, for example - who don't like centralization in any form).
>
> >> (c) nothing is being proposed beyond what is already possible - Antpool
> can go green today, and solicit users to send them signed transactions
> directly instead of adding them to a public mempool, under the pretext that
> it would make the transfer 'greener'.
>
> >> And if there was an economic advantage in doing so, miners would quite
> likely already implement that. Yet, somehow, they are not doing that.
>
> Arguments of the sort 'if something could be done or should have been done
> - it would be done already' are flawed, in my opinion, as following the
> same logic nothing (including Bitcoin itself) should have been done ever.
> As a matter of fact, we are working on a green miner initiative with
> certain miners, having a call with Hut8 in 20 minutes myself - and I know
> that we are not the only ones. Green crypto initiatives are actually
> widespread, and the solutions will be popping up soon.
>
> >> Please stop with the carbon credit nonsense. There is likely no such
> thing to exist on a free market and no one is interested in these state
> regulations.
>
> Please read this Wikipedia Article:
> https://en.wikipedia.org/wiki/Carbon_offset
>
> "There are two types of markets for carbon offsets, compliance and
> *voluntary*" [emphasis added].
>
> Voluntary carbon offset markets are actually growing really fast.
>
> >> Just because a big company is controlled by people who do not
> understand Bitcoin, it does not make the issue valid. There are no such
> environmental concerns once you understand how Bitcoin and free market
> work. Don't help to spread the FUD.
>
> I respectfully submit that people who know how to launch rockets to the
> sky and beam high-speed internet from the satellites to every place on
> earth are at least capable of understanding how Bitcoin works. There is
> even an english expression which reads 'it is not a rocket science' which I
> think fits especially nicely in this particular case :)
>
> >> Once people stop spreading FUD, the price will likely skyrocket. Start
> with yourself please.
>
> I guess you misinterpret my intentions, I think it doesn't matter what
> Bitcoin price is - my personal interest is the widest possible adoption of
> blockchain as a peer-to-peer way to transfer value between consenting
> individuals free from government control or intervention. Environmental
> concerns are real and at least some parts of the community are clearly
> interested to at least discuss this matter (e.g. I am not the one who
> started this thread).
>
> Please don't be dismissive, it is an open forum and everybody is entitled
> to his/her/its own opinion.
> _______________________________________________
> 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/20210517/961c4aaa/attachment-0001.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-04-22 📝 Original message:Hi ...

2023-06-07T22:52:02Z

In reply to nevent1q…d0kw
_________________________

📅 Original date posted:2021-04-22
📝 Original message:Hi Jeremy,

First off, thank you for putting this together and trying to organize
discussion around a repeatable process for soft-fork upgrades. As I read
this I am struggling to identify the complete set of problems that this
process is attempting to solve for. My best understanding of the gridlock
that happened around the LOT parameter of BIP 8 is the fact that a flag day
finale of the deployment had the *optics* of being developer controlled,
despite the fact that upgrades are voluntary and opt in since there is no
automatic upgrade mechanism within Bitcoin Core. So I am generally
unconvinced by that argument. The alternative (the advancement of various
LOT=false proposals including ST) is that we are letting the miners
*actually* exert a level of control over the protocol by imbuing them with
the power to veto these proposals. At a 10% signalling threshold needed to
block the upgrade, in addition to the fact that mining is an enterprise
engaged in by a comparatively small portion of the user base, the
constituency required to block proposals under this model is remarkably
small. I don't think anyone is satisfied with the idea of indefinitely
letting miners have veto power over proposals. So the question is, "what
then?".

The particular gripe I have with the situation is that I generally believe
that *any* LOT=false deployment that is ultimately upheld (not reattempted)
is a ceding of control of the protocol to the miners, at the very least in
that instance if not more generally due to the possible emboldening of more
non-cooperative actors for personal gain at the expense of other network
participants. On the other hand, any LOT=false deployment that is
immediately followed up with something approximating a LOT=true/flag
day/UASF deployment is ultimately a charade and can be handily replaced
with LOT=true with an extended timeline. The common rebuttal I hear from
this is that a LOT=false deployment "helps us learn something" and is
usually an appeal to the difference between stated and revealed preference.
However, I have not been able to get past the idea of exactly what we plan
to learn from this? If we do not trust stated preferences for protocol
changes, and we *only* trust revealed preference, then it seems like the
only thing we can learn is that "miners will not voluntarily make this
upgrade" and any arguments about why are ultimately as speculative as the
stated preferences prior to any Soft Fork deployment at all. As such, I
don't think we learn basically anything useful.

Against the above backdrop, it is hard for me to think that a LOT=false
policy is *ever* sensible. In this case, I have advocated for ST because I
think it will either activate quickly, or prove out in general that a
LOT=false policy just doesn't work (quickly). In all of the discussions I
have been party to, I have not once witnessed someone who would accept the
final upholding of a miner veto on Taproot in particular, yet in the same
session, many of those participants are advocating for LOT=false anyway.
This seems incoherent to me.

So what are we actually solving for?

The idea as I understand it is to distribute power among Bitcoin's
different constituencies in such a way that we A. block "bad upgrades"
always, and B. do our best to activate "good upgrades". However, I feel it
necessary to caution against the fetishization of triumvirate governance
for its own sake. In my mind, anything that doesn't generally respect the
notion that the users are in control of the protocol is not too dissimilar
from the decentralization theater that some Bitcoiners criticize various
altcoins for.

So why not just UASF from the getgo?

This I have started to understand more clearly but still get hung up on
certain details. I think the only universal claim about this is "avoid deep
chain splits at all costs" where "deep" is anything that is going to ruin
upper layers of Bitcoin including institutional operations practices. For
as long as I've been developing applications on top of Bitcoin the
"generally accepted default" seems to be that 6 block reorgs are the
"untouchable limit". However, this is where the details become really
important. By definition, blocks conforming to soft-fork rules are accepted
by the pre-fork implementations. In the other direction, there exists a
subset of blocks that can be produced by pre-fork miners that will not be
accepted by the soft-fork rules. So, in this case, the risk incurred by the
SF clients is that the chain halts. The risk incurred by the pre-fork
implementations is that there are reorgs that result in economic losses.
However, in order for the reorgs to actually occur, miners have to
persistently mine invalid blocks. The reason I make the distinction about
"persistently" is that pre-fork implementations *will accept* soft-fork
compliant blocks. This means that the same incentive structures that cause
miners to switch to mining atop new blocks instead of continuing to mine
atop older ones, apply just as much in this case. Chain convergence is
*guaranteed* with as little as 51% (though this is eventual, and may not be
an acceptable threshold if you're trying to keep the probability of deep
reorgs to some astronomically low threshold). Furthermore, chain
convergence is probable with far less than that threshold, though I'm less
sure of this claim and am open to a rebuttal on this.

The only wrench in the above line of reasoning is the issue of forced
signaling. I've never been a fan of forced signaling. The only thing it
guards against is apathy, which I think is solved with even the threat of
having your mined blocks being reorged out by including invalid
transactions in them.

So to summarize my understanding of what's going on here: we don't want
MASF due to concentration of power, we don't want UASF because of the risk
of chain split. The only way to reconcile this is to show miners that users
more strongly value work done on a chain enforcing the soft fork rules than
one that doesn't, ideally with costly signaling. This is the only way users
can effectively exercise an override on miner preference in a backwards
compatible way and substantially reduces or eliminates chain split risk. I
don't think the proposal above does anything to alleviate this issue. In
fact, if I read it correctly, it rules out the possibility of any UASF
altogether by making it such that a failed MASF forces the users to
hard-fork the protocol. I think that this would be rather tragic since
avoidance of hard forks is one of the biggest victories that came out of
2017. I apologize for not addressing the proposal in a more direct way and
engaging with the details, however, I don't think that discussing the
process makes any sense until we can agree what is being solved, and what
risks are flat out unacceptable. Perhaps laying those out in a
followup response can make it easier for me to engage with the actual
process.

In my mind any proposal that doesn't include a mechanism for gathering
reliable information about user-preference in a way that is sybil resistant
doesn't make any meaningful progress on a consensus change process. I have
only two ideas in this area and both of them don't seem fantastic. The
first one, fork futures, has been discussed at length by people more
experienced than I. The second, is a mechanism that makes mining
transactions that express fork preference (in an as-yet undefined way)
contingent upon the block signaling for it. The details of how to pull that
off may make it such that it is DOA, but it would at least give users a way
to broadcast a costly signal of their preference.

Keagan

On Thu, Apr 22, 2021 at 4:57 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> This letter is particularly aimed at addressing Rusty Russell's quest for
> a development process that respects all groups in a balance of powers.
> However, in the spirit of open discussion, I'm sending it directly to the
> list.
>
> This proposal is aimed to be compatible with Taproot's ST, and I hope will
> help us form some rough consensus around what we try next. Some of the
> concepts here are synthesized from what I've seen discussed, but I haven't
> included citations of anyone's specific ideas as I'm not sure of the exact
> provenance -- I won't claim to have invented this per se, I'm trying to
> capture the zeitgeist of what anyone might think to be the process if
> pressed to draw it out. Lemme know how I did.
>
> The specific parameters are up for debate, but I'm trying to make sure
> I've captured the relevant state transitions.
>
> In this diagram time flows left-to-right, and transitions happen at the
> beginning, end, or middle of a block of time. It should be relatively clear
> when things happen, but if not, please ask to clarify.
>
> [image: Activation.png]
>
> Clarifications:
> - ST: Speedy trial, whereby > T% signals on a block activate the rule
> - neg-ST: Speedy Trial, whereby >X% signals on a block Reject the rule
> - neg-ST and ST at the same time on different bits: 11 or 00 are "abstain"
> votes and are discarded. only 10 or 01 are counted. The purpose of
> simultaneous bits is to allow both earlier lock in and to permit early
> failure, rather than just one or the other.
> - PoW Fork: If a new rule is active, but there is insufficient hashrate,
> the rule must be abandoned or PoW must be changed to minimize disruption.
> In order to minimize disruption, a node will consider an alternative PoW
> chain if < 1/4 of the typical hash rate is seen for a day. Alternative PoW
> is defined as SHA-256 10,000 layers, and starts at low difficulty. This is
> selected to be maximally similar to Bitcoin's existing PoW, but
> sufficiently different to obviate extant ASICS. A node will consider the
> new PoW to be equal in value to the old PoW, and will select between the
> two based on most-work. Work can be either within a single chain. The new
> PoW should have a difficulty adjustment every day for the first month, at
> which point, it will relax to every 2 weeks. The details of this should be
> described in a separate BIP.
> - PoW Fork Lockin: PoW fork is only *required* once the new rule is
> active. Thus it's not required in the case of mandatory signalling to force
> the signalling contemporaneously, but it can be used to commit to forking
> the PoW at some time in the future. It may make sense to not activate the
> new rule till the new PoW is active. The game theory of this should be
> studied carefully, it is my opinion that the safest option is to PoW fork
> during signalling as otherwise miners may protest progress at all.
> - Changes: Any time the underlying activation proposal is changed, the
> process is restarted. E.g., suppose taproot is rejected because Quantum
> Scaries, and we hash the key. The process restarts from the beginning.
> Restarts can only occur during quieting periods.
> - Quieting Period 1: In the first quieting period, if reached, the
> "Bitcoin Core Community" can release the next step, or change the BIP. I
> left out failing in this period as a change or a redeployment should always
> be attempted.
> - Quieting Period 2: In the second quieting period, the outcome is either
> to reject the change entirely or to agree to force it. The "Bitcoin Core
> Community" may also prepare the release at this stage, and sign, but should
> re-label the client as "Bitcoin Community's <Feature> Forcing Client". A
> release labeled "Bitcoin Core" may also be made without mandatory
> signalling and without forced activation can also be made, such a client
> should have (depending on if the flag day is to use signalling) either
> ability to activate in response to signalling or a hidden
> <feature>activeathash parameter to allow clients to enable the feature
> post-hoc of the activating block.
> - Forced Signalling: It's unclear to me the merit of forced signalling
> being 90% of 2016 blocks v.s. 90% of 100 blocks. A shorter forced signaling
> assuages certain concerns around lost hashrate -- 1 day of disruption is a
> lot better than 2 weeks.
> - Timeline: As spec'd above, this whole process takes about 2 years worst
> case. ST1 0 months; Quieting 1 at 3 months; ST2 at 6 months; Quieting 2 at
> 9 months, final attempt at 1 year. The Forcing client period should
> probably be 1 yr till active. This is *a bit* slower than the "BIP8
> LOT=True UASF Client", but I think not so much slower that it's unworkable.
>
> The most contentious part of this I intuit to be the PoW Fork -- please,
> let's avoid discussing the mechanic of how to most safely accomplish this.
> The main point of including it in this diagram is to emphasize that if you
> commit to being on a minority chain with because of a rule activation with,
> say, 5% hashrate, you would experience very tangible disruption. In theory,
> every fork upgrade (even signalled) entails such a risk, but we assume some
> level of miner honesty (unfortunately!) that they never signal falsely.
> This may be a bad assumption with mandatory signalling. The alternative is
> to permit hard forks in our diagram, and allow users to downgrade their
> client and deactivate this rule. Since this can lead to loss of funds, we
> do not consider this a safe option, and it is a hardfork as well so is
> technically compatible with the "PoW fork" branch.
>
>
> Questions I have:
>
> 1) What state transitions are missing from this diagram? Are there other
> paths that should be included?
> 2) Is it ever feasible to make a change to the upgrade and not restart the
> whole process?
> 3) How long should all of the periods be? Can the 1st 2 ST's be 3 month?
> Should we make the second one 6 month? Does it depend on previous signalled
> hashrate?
> 4) Do we ever adjust signalling thresholds?
> 5) Does forced signalling need to be 2016 blocks?
> 6) In the second ST should the min active height be allowed to be within
> signalling time if > 3 mo?
> 7) Under what circumstances would we *want* to skip the second ST period
> and directly signal? What would we lose by committing to not skipping it,
> ever (6 months?).
> 8) I purposefully left the purple edge from ST2 bit 2 to Quieting 2: in
> theory, this edge is not there because it is overruled by the neg-ST
> failing to fail. Under what circumstances might we give this precedence
> over neg-ST? E.g., signalling activate < 50%?
> 9) How much parameter flexibility do we have during Quieting periods?
> Should we be fixed beforehand?
> 10) who wants to write the software for any of this... *noses*
> 11) do we need to hard-code the PoW fork ahead of time? Or can it just be
> "prepared" as an alt binary in case of emergency?
>
>
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> 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/20210422/36f791a8/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Activation.png
Type: image/png
Size: 81125 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210422/36f791a8/attachment-0001.png>;

📅 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-04 📝 Original message:As one ...

2023-06-07T18:29:58Z

In reply to nevent1q…7xsr
_________________________

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

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

So that leads me to believe here that the folks who oppose LOT=true
primarily have an issue with forced signaling, which personally I don't
care about as much, not the idea of committing to a UASF from the get go.

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

Keagan

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

> Appologies as I've rearranged your comments in my reply.
>
> On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>>
>> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>>
> > After a normal and successful Core update with LOT=false, we will have
>> more data showing broad community support for the
>> > taproot upgrade in hand.
>>
>> I think this is one of the strongest arguments against a flag day
>> activation, but, as I described in more detail in the
>> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
>> aren't there enough already.
>>
>
> I agree with you. I also think we have plenty of evidence to proceed with
> taproot and could proceed with a PR for such a flag day activation. If
> there is support for it to be merged, that would be fantastic. I think we
> should proceed along these lines forthwith.
>
> However, the existence and/or release of a flag day activation code does
> not in of itself preclude concurrently developing and/or releasing a BIP8
> LOT=false deployment. Activating taproot is "idempotent" after all. We
> could even do a Core release with a flag day activation while we continue
> to discuss BIP8 LOT=false if that gets the ball rolling. Certainly having
> a flag day activation code merged would take a lot of pressure off further
> BIP8 LOT=false work.
>
> As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL
> state, then running BIP8 LOT=false alongside a flag day activation at
> timeout may be the way to go. Once a flag day deployment is released, the
> LOT=true people would have their guaranteed activation and would be less
> interested in an alternative client. And without a MUST_SIGNAL state, I
> believe the LOT=false deployment won't lead any hashpower that is following
> standardness rules to create invalid blocks.
>
>
>> > In the next release, 6 months later or so, Core could then confidently
>> deploy a BIP8 LOT=true
>>
>> Could you clarify what an acceptable timeline is, then? Six months from
>> release of new consensus rules to activation (in
>> the case of a one-year original window) seems incredibly agressive for a
>> flag-day activation, let alone one with
>> forced-signaling, which would require significantly higher level of
>> adoption to avoid network split risk. In such a
>> world, we'd probably get Taproot faster with a flag day from day one.
>>
>
> Whatever timeline people are in favour of. I think having a year or more
> between the LOT=true or flag day more and the anticipated second release
> date is fair myself.
> That would suggest a 2-year timeout from the start to give plenty of room.
>
> Of course, if we start with a flag day from the start then we can just do
> 1 year and we don't need a second deployment.
>
> We could also do a "Let’s see what happens" with a short 3 or 4-month
> deployment and still do a follow up activation if that is more agreeable.
> That would give a net of about 1.5 years or so because we don't need to
> anticipate the second relase date.
>
> I'm good with whatever, and I'm happy to make more concrete suggestions if
> that is necessary. I think there exist acceptable timelines here.
>
>
>> > client, should it prove to be necessary. A second Core deployment of
>> LOT=true would mitigate some of the concerns with
>> > LOT=false, but still provide a period beforehand to objective actions
>> taken by the community in support of taproot. We
>> > don't even have to have agreement today on a second deployment of
>> LOT=true after 6 months to start the process of a
>> > LOT=false deployment. The later deployment will almost certainly be
>> moot, and we will have 6 months to spend debating
>> > the LOT=true deployment versus doing a flag day activation or something
>> else.
>>
>
>
>> That was precisely the original goal with the LOT=false movement - do
>> something easy and avoid having to hash out all
>> the technical details of a second deployment. Sadly, that's no longer
>> tennable as a number of people are publicly
>> committed to deploying LOT=true software on the network ASAP.
>>
>
>
>
> First things last:
>
> > Even today, I still think that starting with BIP8 LOT=false is,
>> generally speaking, considered a reasonably safe
>> > activation method in the sense that I think it will be widely
>> considered as a "not wholly unacceptable" approach to
>> > activation.
>>
>> How do you propose avoiding divergent consensus rules on the network,
>> something which a number of commentors on this
>> list have publicly committed to?
>>
>
> Firstly, it is an open network. Anyone can join and run whatever
> consensus rules they want. People have run divergent consensus rules on
> the network in the past and it will continue to do so in the future.
> It is troublesome when it happens in mass, but it isn't fatal. We can't
> prevent it, and we should continue working to keep the protocol robust in
> the face of it.
> And we certainly shouldn't be bullied by anyone who comes threatening
> their own soft-fork.
>
> Even simply doing nothing may not prevent divergent consensus from
> appearing on the network. Playing conservative isn't playing it safe
> because there is nothing more conservative than doing nothing, which isn't
> guaranteed to be safe in this sense.
>
> Secondly, for the specific concern of people running BIP8 LOT=true
> clients, we could start with "Let’s see what happens" with a short 3 or 4
> month signaling period. A short enough signaling period is not
> "hijackable". We could add a longer LOCKED_IN period if there are worries
> about getting enough nodes upgraded in time for activation. I see other
> options as well.
>
> I keep being told that miners are ready and willing to activate, and
> taproot will probably activate in two months. All we have to do is get
> something out the door that does that. If taproot activates in two months,
> great. If it fails to activate we will learn so much in so little time.
> UASF's will get to say "I told you so" without waiting a year. Users will
> get to take active, meaningful and observable steps to demonstrate their
> desire for a taproot upgrade. Very little time will be wasted, in
> particular we don't have to finish debating how best to handle the unlikely
> scenario where taproot doesn't activate right away for whatever reason that
> is, an scenario that isn't even likely to occur.
>
> I'm still very optimistic. I see multiple plausible and potentially
> acceptable paths towards activation still open and we don't even have to
> choose only one. I can hardly wait to look at the forthcoming PRs for
> these possibilities.
>
>
>> Matt
>>
> _______________________________________________
> 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/20210304/c4aea744/attachment-0001.html>;

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

2023-06-07T18:29:40Z

In reply to nevent1q…p5ku
_________________________

📅 Original date posted:2021-03-01
📝 Original message:> Personally I consider this counterproductive. Apart from the complexity,
it’s not healthy. And the chain grows linearly with storage cost falling
exponentially, leading to a straightforward conclusion.

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

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

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

Keagan

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

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

2023-06-07T18:27:49Z

In reply to nevent1q…z2cm
_________________________

📅 Original date posted:2020-12-16
📝 Original message:I was just looking into the conventions around this yesterday! It seems
like this proposal is mostly just formalizing stuff that is already a tacit
standard. I'm glad to see that someone is documenting it somewhere more
"official".

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

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

Keagan

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

> BIP number 48 has not been assigned. Do not self-assign BIP numbers.
>
> Is this intended to be compatible with
> https://github.com/bitcoin/bips/pull/253 ?
>
> Luke
>
>
>
> On Wednesday 16 December 2020 14:10:28 dentondevelopment via bitcoin-dev
> wrote:
> > Here is the repo instead of a static link:
> > https://github.com/Fonta1n3/bips/blob/master/bip-0048.mediawiki
> >
> > Fontaine
> >
> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> >
> > On Wednesday, December 16, 2020 8:43 PM, dentondevelopment via
> bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > Hello,
> > >
> > > I would like to propose bip48 (taking bip44 as inspiration), with the
> > > purpose of documenting modern multi-sig derivations.
> > >
> > > Please see a rough draft of the proposed bip attached, comments/input
> > > welcome.
> > >
> > > Regards,
> > > Fontaine
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev 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/20201216/034a2dfd/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>;

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

2023-06-07T18:24:22Z

In reply to nevent1q…03pe
_________________________

📅 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/bitcoin-dev/attachments/20200506/ce5bff4d/attachment.html>;

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

2023-06-07T18:24:21Z

In reply to nevent1q…0dtl
_________________________

📅 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/bitcoin-dev/attachments/20200514/8cf2f0f1/attachment.html>;