Corey Haddad [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-12 to 2022-07-07
💬 Posted a total of 12 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:11:09

- reply

📅 Original date posted:2022-07-07
📝 Original message:>Billy,
>
>Proof of work and the difficulty adjustment function solve literally
everything you are talking about already.
>Bitcoin does not need active economic governanance by devs or meddlers.
>Please stop spamming this list with this nonsensical thread.
>
>Love,
>John
Sorry John, but this is a divisive comment. You are the spammer here. While
it is unclear why you are trying to harm the Bitcoin development process,
you are, and anyone reading this should know that.
Proof of work and the difficulty adjustment have no capability to ensure
that the amount of security is adequate or reasonable.The only proximate
incentive-compatible feedback mechanisms would either make the security too
low or too high, and not approach 'just right'. If the price falls, and the
hashrate goes down, people might conclude that Bitcoin is looking
vulnerable to attack and therefore sell, which would be a negative feedback
loop. Conversely, if a price rise leads to a higher hashrate, people might
think Bitcoin is now even more secure than before and buy, causing a
positive feedback loop. These are not stable equilibria.
PoW and the difficulty adjustments hold block times at 10 minutes, and by
the same token, keep coin issuance roughly on schedule. They have also
turned out to - thus far - have charted a reasonable (albeit predetermined)
course through the various hash-based attacks that lurk out there in the
world. Without any sort or restorative force that guides the security
budget to an optimum, or even towards a reasonable range, we have to
recognize that we are just lucky that Satoshi got it right. When navigating
via dead reckoning, the uncertainty accumulates over time and distance.
Eventually external corrections are needed. We absolutely need to keep
apprised of the current and future threats, assess Bitcoin's resilience in
the face of those threats, and when needed make changes to ensure Bitcoin
remains secure.
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/37458d86/attachment-0001.html>

2023-06-07 23:10:54

- reply

📅 Original date posted:2022-07-06
📝 Original message:>Bitcoin's finite supply is the main argument for people investing in it,
the whole narrative around bitcoin is based on its finite supply. While it
has its flaws and basically condemns bitcoin to be only used as a store >of
value (and not as a currency), I don't think it's worth questioning it at
this point.
>
>Just my 2 sats.
>
>Giuseppe.
A finite supply alone is not enough to give something value, as it must
also be useful in some way. In the case of Bitcoin, various forms of
cryptographic security must all work - and work together - to make Bitcoin
useful. If the only realistic (fair, efficient & proportionate) way to pay
for Bitcoin's security was by having some inflation scheme that violated
the 21 million cap, then agreeing to break the limit would probably be what
makes sense, and in the economic interest of its users and holders.
There will always be competitive pressures with respect to efficiency, and
both being over-secured and under-secured would be economically inefficient
for a crypto currency, and thereby laving room for a more optimally-secured
competitor to gain ground. Currently there is zero feedback in the Bitcoin
system between what we might think is the optimum amount of security and
what actually exists. There is also zero agreement on how much security
would constitute such an optimum. Figuring out how much security is needed,
or even better, figuring out a way to have a market mechanism to answer
that question, will be an important project.
Another option, if we were to decide we are over-secured in the short term,
would be to soft-fork in a reduction in the current and near-future mining
rewards, by somehow locking the coins in a contract that deprived the miner
of the full reward, and then using that contract to pay the rewards out far
in the future, should at some point we feel the security budget was
insufficient. Anthony Towns presented a form of this concept in greater
detail at a Scaling Bitcoin conference some years ago. While this solution,
if employed, would only work for some finite amount of time, it is possible
that could give additional decades before the accumulated security budget
was exhausted.
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220706/87d2ce52/attachment.html>

2023-06-07 23:10:05

- reply

📅 Original date posted:2022-06-12
📝 Original message:Even if demand for block space is currently not needed to pay for security
due to the block rewards, demand for BTC itself is needed for those rewards
to be worth anything.
Bitcoin, as a proof of work system, is only secure at scale. Therefore
continued growth and user adoption are both critical for Bitcoin's
security. Perhaps the question then becomes
who feels that Bitcoin is inevitable, and who feels it is possible that it
can damaged or destroyed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220612/cd752803/attachment.html>

2023-06-07 23:07:50

- reply

📅 Original date posted:2022-04-22
📝 Original message:>*A change that increases the number of use cases of Bitcoin affects all
users and is *not* non-invasive. More use cases means more blockchain usage
which increases the price of a transaction for *everyone*.*
This manages to be both incorrect and philosophically opposed to what
defines success of the project . Neither the number of ways that people
figure out how to innovatively harness Bitcoin's existing capabilities, nor
the number or complexity of any optional transaction types that the Bitcoin
protocol supports have any bearing on transaction fees. Demand for
blockspace from transactions, which is just plain *use* - and not *use
cases* - is what could drive up transaction fees.
On the philosophical level, as designers of the system, we all hope and
work to make Bitcoin so useful, appealing, and secure that there is massive
demand for blockspace, even in the face of high transaction fees. As an
individual thinking only of their next on-chain transaction, it is
understandable that one might hope for low fees and partially-filled
blocks. Longer term, the health of the system can both be measured by and
itself depends on high transaction demand and fee pressure.
If you were trying to argue that CTV is invasive because it may increase
transaction demand and therefore cost users more fees, that is 1) an
endorsement of CTV's desirability and 2) reveals that you consider any
increased free-market competition (i.e. more demand) to be "invasive".
*>I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
users. *
As for Peter Todd's "any change of Bitcoin must benefit *all* users", that
is absolutely a reasonable thing to consider. However, in order to make
practical use of that maxim, we must adopt in our minds a *generic*, or
"model user", and then replicate them so that we may meaningfully
understand a least a proxy for "all users". In reality, there will always
be someone (and at this point, probably a "user" too) who wouldn't benefit
from a change, or at least think they won't. Some users of Bitcoin may even
want Bitcoin to fail, so we cannot afford assume that people have alignment
of goals or vision just by virtue of being a 'user'.
Corey
> _______________________________________________
> 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/20220422/4cbf6200/attachment-0001.html>

2023-06-07 23:07:38

- reply

📅 Original date posted:2022-04-22
📝 Original message:If none of the alternative proposals have been developed as much as CTV, it
seems reasonable to interpret that as a lack of interest in those
alternative proposals themselves.
That should not be interpreted as lack of interest in covenants. Perhaps if
CTV didn't exist, we would have seen more progress on the alternatives.
It's entirely reasonable to assume that people who are interested in
covenants have put their energy and attention primarily behind CTV, and
that is why it is the furthest along. It shouldn't be a requisite to
improving Bitcoin that we have multiple, competing proposals for a
similar use case that have all been debated, implemented and tested before
we will be okay with integrating one of them. That may be the ideal, but it
shouldn't be a requirement.
If we can find consensus of moving forward with one of the proposals, and
there are concrete commitments to develop the alternatives over the next
few months, I would suggest that would be something worth waiting for. In
the absence of such consensus and commitments, the ask here is that CTV be
set aside in favor of an unlikely hypothetical.
Corey
On Fri, Apr 22, 2022 at 2:40 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On 4/21/22 6:20 PM, David A. Harding wrote:
> > [Rearranging Matt's text in my reply so my nitpicks come last.]
> >
> > On 21.04.2022 13:02, Matt Corallo wrote:
> >> I agree, there is no universal best, probably. But is there a concrete
> >> listing of a number of use-cases and the different weights of things,
> >> plus flexibility especially around forward-looking designs?
> >
> > I'm sure we could make a nice list of covenant usecases, but I don't
> know how we would assign
> > reasonable objective weights to the different things purely through
> group foresight. I know I'm
> > skeptical about congestion control and enthusiastic about
> joinpools---but I've talked to developers
> > I respect who've had the opposite opinions from me about those things.
> The best way I know of to
> > reconcile our differing opinions is to see what real Bitcoin users
> actually pay for. But to do
> > that, I think they must have a way to use covenants in something like
> the production environment.
>
> To get good data for this kind of question you'd need much longer than
> five years, sadly. As we've
> seen over and over again in Bitcoin deploying very nontrivial things takes
> at least five years,
> often more. While vaults may be deployed relatively more quickly, the fact
> that we haven't seen
> (AFAIK) *anyone* deploy some of the key-deletion-based vault designs that
> have been floating around
> for some time is indication that even that probably wouldn't be deployed
> quickly.
>
> >> You're also writing off [...] a community of
> >> independent contributors who care about Bitcoin working together to
> >> make decisions on what is or isn't the "right way to go" [...]. Why are
> you
> >> suggesting its something that you "don't know how to do"?
> >
> > You said we should use the best design. I said the different designs
> optimize for different things,
> > so it's unlikely that there's an objective best. That implies to me
> that we either need to choose a
> > winner (yuck) or we need to implement more than one of the designs. In
> either of those cases,
> > choosing what to implement would benefit from data about how much the
> thing will be used and how
> > much users will pay for it in fees.
>
> I agree, there is no objective "best" design. But we can sill explore
> design tradeoffs and utility
> for different classes of covenants. I've seen relatively little of this so
> far, and from what I have
> seen its not been clear that CTV is really a good option, sadly.
>
>
> >> Again, you're writing off the real and nontrivial risk of doing a fork
> >> to begin with.
> >
> > I agree this risk exists and it isn't my intention to write it off---my
> OP did say "we [must be]
> > absolutely convinced CTV will have no negative effects on the holders or
> receivers of non-CTV
> > coins." I haven't been focusing on this in my replies because I think
> the other issues we've been
> > discussing are more significant. If we were to get everyone to agree to
> do a transitory soft fork,
> > I think the safety concerns related to a CTV soft fork could be
> mitigated the same way we've
> > mitigated them for previous soft forks: heaps of code review/testing and
> making sure a large part of
> > the active community supports the change.
>
> I'm not sure I made my point here clear - the nontrivial and real risk I
> was referring to was not
> avoidable with "moar code review" or "careful analysis to make sure the
> proposed fork doesn't cause
> damage". I mean issues that keep cropping up in many changes like "people
> start threatening to run a
> fork-causing client" or "some miners aren't validating blocks and end up
> creating a fork" or "some
> people forget to upgrade and follow such a fork" or..... there's lots and
> lots of risks to a doing a
> fork that come from the process and nature of forks, that have nothing to
> do with the actual details
> of the fork itself.
>
> 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/20220422/b344c2cb/attachment.html>

2023-06-07 22:54:49

- reply

📅 Original date posted:2021-06-30
📝 Original message:We cannot prevent people from choosing to take an action based on an
unconfirmed transaction. Even though it is trivial to have a
double-spending transaction confirmed, accepting a 0-conf tx can be
rational in many cases. 0-conf can be interpreted as the customer
signaling their 'intent to pay', and where there is an established
relationship between customer and merchant, or where there merchant is
providing a cancelable e-service, signaling intent may be enough. These use
cases do not depend on making it difficult for the user to attempt to
double-spend the merchant.
Bitcoin is a system designed around a consensus on the blockchain, not the
mempool. I am in favor of providing the spender of bitcoins with all
possible tools and methods to help them submit their transactions -
double-spending or not - to miners for consideration. More than making RBF
the default, I would prefer to see nodes forward any transaction
conflicting transaction, so long as it has a higher fee. Is there a reason
this would be undesirable?
Corey
On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the parties trust each other, rbf is still opt-in. Just don't do it?
>
> On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > services providers are offering zero-conf channels, where you can
>> start to spend instantly [0]. I believe that's an interesting usage
>>
>> I agree those are interesting and useful cases. I suppose I should
>> clarify that when I asked if bitcoin should continue supporting 0-conf
>> transactions, I meant: should we make design decisions based on whether it
>> makes raw 0-conf transactions more or less difficult to double spend on? I
>> do think 0-conf transactions can be useful in situations where there is
>> some level of trust (either direct trust between the interacting parties,
>> or disperse trust that most people won't try to double spend, perhaps
>> because the transaction is small or their identity is tied to it). Fidelity
>> bonds sound like an interesting way to mitigate sybil attacks in a
>> reputation system.
>>
>> On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard <antoine.riard at gmail.com>
>> wrote:
>>
>>> > Do we as a community want to support 0-conf payments in any way at this
>>> > point? It seems rather silly to make software design decisions to
>>> > accommodate 0-conf payments when there are better mechanisms for fast
>>> > payments (ie lightning).
>>>
>>> Well, we have zero-conf LN channels ? Actually, Lightning channel
>>> funding transactions should be buried under a few blocks, though few
>>> services providers are offering zero-conf channels, where you can start to
>>> spend instantly [0]. I believe that's an interesting usage, though IMHO as
>>> mentioned we can explore different security models to make 0-conf safe
>>> (reputation/fidelity-bond).
>>>
>>> > One question I have is: how does software generally inform the user
>>> about
>>> 0-conf payment detection?
>>>
>>> Yes generally it's something like an "Unconfirmed" annotation on
>>> incoming txn, though at least this is what Blockstream Green or Electrum
>>> are doing.
>>>
>>> > But I
>>> suppose it would depend on how often 0-conf is used in the bitcoin
>>> ecosystem at this point, which I don't have any data on.
>>>
>>> There are few Bitcoin services well-known to rely on 0-conf. Beyond how
>>> much of the Bitcoin traffic is tied to a 0-conf is a hard question, a lot
>>> of 0-confs service providers are going to be reluctant to share the
>>> information, for a really good reason you will learn a subset of their
>>> business volumes.
>>>
>>> I'll see if I can come up with some Fermi estimation on this front.
>>>
>>> [0] https://www.bitrefill.com/thor-turbo-channels/
>>>
>>> Le mer. 16 juin 2021 à 20:58, Billy Tetrud <billy.tetrud at gmail.com> a
>>> écrit :
>>>
>>>> Russel O'Connor recently opined
>>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019061.html>
>>>> that RBF should be standard treatment of all transactions, rather than as a
>>>> transaction opt-in/out. I agree with that. Any configuration in a
>>>> transaction that has not been committed into a block yet simply can't be
>>>> relied upon. Miners also have a clear incentive to ignore RBF rules and
>>>> mine anything that passes consensus. At best opting out of RBF is a weak
>>>> defense, and at worst it's simply a false sense of security that is likely
>>>> to actively lead to theft events.
>>>>
>>>> Do we as a community want to support 0-conf payments in any way at this
>>>> point? It seems rather silly to make software design decisions to
>>>> accommodate 0-conf payments when there are better mechanisms for fast
>>>> payments (ie lightning).
>>>>
>>>> One question I have is: how does software generally inform the user
>>>> about 0-conf payment detection? Does software generally tell the user
>>>> something along the lines of "This payment has not been finalized yet. All
>>>> recipients should wait until the transaction has at least 1 confirmation,
>>>> and most recipients should wait for 6 confirmations" ? I think unless we
>>>> pressure software to be very explicit about what counts as finality, users
>>>> will simply continue to do what they've always done. Rolling out this
>>>> policy change over the course of a year or two seems fine, no need to rush.
>>>> But I suppose it would depend on how often 0-conf is used in the bitcoin
>>>> ecosystem at this point, which I don't have any data on.
>>>>
>>>> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF
>>>>> as the Bitcoin Core's default replacement policy in version 24.0. As a
>>>>> reminder, the next release is 22.0, aimed for August 1st, assuming
>>>>> agreement is reached, this policy change would enter into deployment phase
>>>>> a year from now.
>>>>>
>>>>> Even if this replacement policy has been deemed as highly
>>>>> controversial a few years ago, ongoing and anticipated changes in the
>>>>> Bitcoin ecosystem are motivating this proposal.
>>>>>
>>>>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>>>>>
>>>>> As explained in "On Mempool Funny Games against Multi-Party Funded
>>>>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
>>>>> funded transactions by propagating an RBF opt-out double-spend of its
>>>>> contributed input before the honest transaction is broadcasted by the
>>>>> protocol orchester. DoSes are qualified in the sense of either an attacker
>>>>> wasting timevalue of victim's inputs or forcing exhaustion of the
>>>>> fee-bumping reserve.
>>>>>
>>>>> This affects a series of Bitcoin protocols such as Coinjoin, onchain
>>>>> DLCs and dual-funded LN channels. As those protocols are still in the early
>>>>> phase of deployment, it doesn't seem to have been executed in the wild for
>>>>> now. That said, considering that dual-funded are more efficient from a
>>>>> liquidity standpoint, we can expect them to be widely relied on, once
>>>>> Lightning enters in a more mature phase. At that point, it should become
>>>>> economically rational for liquidity service providers to launch those DoS
>>>>> attacks against their competitors to hijack user traffic.
>>>>>
>>>>> Beyond that, presence of those DoSes will complicate the design and
>>>>> deployment of multi-party Bitcoin protocols such as payment
>>>>> pools/multi-party channels. Note, Lightning Pool isn't affected as there is
>>>>> a preliminary stage where batch participants are locked-in their funds
>>>>> within an account witnessScript shared with the orchestrer.
>>>>>
>>>>> Of course, even assuming full-rbf, propagation of the multi-party
>>>>> funded transactions can still be interfered with by an attacker, simply
>>>>> broadcasting a double-spend with a feerate equivalent to the honest
>>>>> transaction. However, it tightens the attack scenario to a scorched earth
>>>>> approach, where the attacker has to commit equivalent fee-bumping reserve
>>>>> to maintain the pinning and might lose the "competing" fees to miners.
>>>>>
>>>>> # RBF opt-out as a Mempools Partitions Vector
>>>>>
>>>>> A longer-term issue is the risk of mempools malicious partitions,
>>>>> where an attacker exploits network topology or divergence in mempools
>>>>> policies to partition network mempools in different subsets. From then a
>>>>> wide range of attacks can be envisioned such as package pinning [1],
>>>>> artificial congestion to provoke LN channels closure or manipulation of
>>>>> fee-estimator's feerate (the Core's one wouldn't be affected as it relies
>>>>> on block confirmation, though other fee estimators designs deployed across
>>>>> the ecosystem are likely going to be affected).
>>>>>
>>>>> Traditionally, mempools partitions have been gauged as a spontaneous
>>>>> outcome of a distributed systems like Bitcoin p2p network and I'm not aware
>>>>> it has been studied in-depth for adversarial purposes. Though, deployment
>>>>> of second-layer
>>>>> protocols, heavily relying on sanity of a local mempool for
>>>>> fee-estimation and robust propagation of their time-sensitive transactions
>>>>> might lead to reconsider this position. Acknowledging this, RBF opt-out is
>>>>> a low-cost partitioning tool, of which the existence nullifies most of
>>>>> potential progresses to mitigate malicious partitioning.
>>>>>
>>>>>
>>>>> To resume, opt-in RBF doesn't suit well deployment of robust
>>>>> second-layers protocol, even if those issues are still early and deserve
>>>>> more research. At the same time, I believe a meaningful subset of the
>>>>> ecosystem are still relying
>>>>> on 0-confs transactions, even if their security is relying on far
>>>>> weaker assumptions (opt-in RBF rule is a policy rule, not a consensus one)
>>>>> [2] A rapid change of Core's mempool rules would be harming their quality
>>>>> of services and should be
>>>>> weighed carefully. On the other hand, it would be great to nudge them
>>>>> towards more secure handling of their 0-confs flows [3]
>>>>>
>>>>> Let's examine what could be deployed ecosystem-wise as enhancements to
>>>>> the 0-confs security model.
>>>>>
>>>>> # Proactive security models : Double-spend Monitoring/Receiver-side
>>>>> Fee-Topping with Package Relay
>>>>>
>>>>> From an attacker viewpoint, opt-in RBF isn't a big blocker to
>>>>> successful double-spends. Any motivated attacker can modify Core to
>>>>> mass-connect to a wide portion of the network, announce txA to this subset,
>>>>> announce txA' to the
>>>>> merchant. TxA' propagation will be encumbered by the
>>>>> privacy-preserving inventory timers
>>>>> (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an attacker has no care
>>>>> to respect.
>>>>>
>>>>> To detect a successful double-spend attempt, a Bitcoin service should
>>>>> run few full-nodes with well-spread connection graphs and unlinkable
>>>>> between them, to avoid being identified then maliciously partitioned from
>>>>> the rest of the network.
>>>>>
>>>>> I believe this tactic is already deployed by few Bitcoin services, and
>>>>> even one can throw flame at it because it over consumes network resources
>>>>> (bandwidth, connection slots, ...), it does procure a security advantage to
>>>>> the ones doing it.
>>>>>
>>>>> One further improvement on top of this protection could be to react
>>>>> after the double-spend detection by attaching a CPFP to the merchant
>>>>> transaction, with a higher package feerate than the double-spend. Expected
>>>>> deployment of package-relay as a p2p mechanism/mempool policy in Bitcoin
>>>>> Core should enable it to do so.
>>>>>
>>>>> # Reactive security models : EconomicReputation-based Compensations
>>>>>
>>>>> Another approach could be to react after the fact if a double-spend
>>>>> has been qualified. If the sender is already known to the service provider,
>>>>> the service account can be slashed. If the sender is a low-trusted
>>>>> counterparty to the merchant, "side-trust" models could be relied on. For
>>>>> e.g a LN pubkey with a stacked reputation from your autopilot, LSATs, stake
>>>>> certificates, a HTLC-as-a-fidelity-bond, ... The space is quite wide there
>>>>> but I foresee those trust-minimized, decentralized solutions being adopted
>>>>> by the LN ecosystem to patch the risks when you enter in a channel/HTLC
>>>>> operation with an anonymous counterparty.
>>>>>
>>>>> What other cool new tools could be considered to enhance 0-confs
>>>>> security ?
>>>>>
>>>>> To conclude, let's avoid replaying the contentious threads of a few
>>>>> years ago. What this new thread highlights is the fact that a transaction
>>>>> relay/mempool acceptance policy might be beneficial to some class of
>>>>> already-deployed
>>>>> Bitcoin applications while being detrimental to newer ones. How do we
>>>>> preserve the current interests of 0-confs users while enabling upcoming
>>>>> interests of fancy L2s to flourish is a good conversation to have. I think.
>>>>>
>>>>> If there is ecosystem agreement on switching to full-RBF, but 0.24
>>>>> sounds too early, let's defer it to 0.25 or 0.26. I don't think Core has a
>>>>> consistent deprecation process w.r.t to policy rules heavily relied-on by
>>>>> Bitcoin users, if we do so let sets a precedent satisfying as many folks as
>>>>> we can.
>>>>>
>>>>> Cheers,
>>>>> Antoine
>>>>>
>>>>> [0]
>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>>>>
>>>>> [1] See scenario 3 :
>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
>>>>>
>>>>> [2]
>>>>> https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121
>>>>>
>>>>> [3] And the LN ecosystem does have an interest to fix zero-confs
>>>>> security, if "turbo-channels"-like become normalized for mobile nodes
>>>>> _______________________________________________
>>>>> 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/20210630/45e377b6/attachment-0001.html>

2023-06-07 17:52:55

- reply

📅 Original date posted:2016-08-28
📝 Original message:*One of my biggest fears about using any wallet is the "whoops, cosmic ray
flipped a bit while producing receiving address; SFYL!" possibility. For
high value cold storage, I always generate my addresses on two independent
machines using two different pieces of software. Am I nuts for doing that?*
A randomly flipped bit would be extremely unlikely to yield a valid
address, however, I still think it you are wise to use independent routes
to confirm that your addresses match the keys. I do the same when I
generating my cold storage key pairs. I think malicious address
substitution is an under appreciated attack vector.
Regarding this thread in general, would it make sense for this proposal to
include standards for multi-sig wallet interoperability? A whole spectrum
of attacks would be made less likely - and easy for typical users to guard
against - by using wallets on separate devices AND where the wallet
software was written and provided by different parties.
On Mon, Aug 22, 2016 at 9:50 AM, Moral Agent via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> It would be nice if the detached signer and the normal wallet could both
> verify the correctness of generated addresses before you cause coins to be
> sent there.
>
> e.g. the hardware wallet could give its master public key to Bitcoin Core
> and you can thereafter generate your receiving addresses on Core, with the
> option to have the HW wallet validate them.
>
> One of my biggest fears about using any wallet is the "whoops, cosmic ray
> flipped a bit while producing receiving address; SFYL!" possibility. For
> high value cold storage, I always generate my addresses on two independent
> machines using two different pieces of software. Am I nuts for doing that?
>
> With the above scheme, you are pretty well protected from losing money if
> your HW wallet is defective. You could still lose it if the HW wallet was
> evil of course, but that strikes me as much more likely to be discovered
> quickly.
>
> _______________________________________________
> 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/20160828/65c0f30a/attachment.html>

2023-06-07 17:49:36

- reply

📅 Original date posted:2016-03-03
📝 Original message:Since the root cause of what you are trying to address is the reward
having, I'd suggest considering an adjustment to the having schedule.
Instead of their being a large supply shock every four years, perhaps the
reward could drop every 52,500 blocks (yearly), or even at each difficulty
adjustment, in such a way that the inflation curve is smoothed out. The
exponential decay rate would be preserved, so overall economic philosophy
would be preserved.
I'm guessing hesitance to this approach would lie in a reluctance to tinker
with Bitcoin's 'economic contract', and slippery slope concerns about might
be the next change (21M?). However, I think it could actually increase
confidence in the system if the community is able to demonstrate a good
process for making such decisions, and show that we can separate the
meaningful underlying principles, such as the coin limit and overall
inflation rate, from what is more akin to an implementation detail, as I
consider the large-step reward reduction to be.
I'm not too worried about the impact of the having as is, but adjusting the
economic parameter would be a safer and simpler way to address the concerns
than to tinker with the difficulty targeting mechanism, which is at the
heart of Bitcoin's security
On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We are coming up on the subsidy halving this July, and there have been some
> concerns raised that a non-trivial number of miners could potentially drop
> off
> the network. This would result in a significantly longer block interval,
> which
> also means a higher per-block transaction volume, which could cause the
> block
> size limit to legitimately be hit much sooner than expected. Furthermore,
> due
> to difficulty adjustment being measured exclusively in blocks, the time
> until
> it adjusts to compensate would be prolonged.
>
> For example, if 50% of miners dropped off the network, blocks would be
> every
> 20 minutes on average and contain double the transactions they presently
> do.
> Even double would be approximately 850-900k, which potentially bumps up
> against the hard limit when empty blocks are taken into consideration. This
> situation would continue for a full month if no changes are made. If more
> miners drop off the network, most of this becomes linearly worse, but due
> to
> hitting the block size limit, the backlog would grow indefinitely until the
> adjustment occurs.
>
> To alleviate this risk, it seems reasonable to propose a hardfork to the
> difficulty adjustment algorithm so it can adapt quicker to such a
> significant
> drop in mining rate. BtcDrak tells me he has well-tested code for this in
> his
> altcoin, which has seen some roller-coaster hashrates, so it may even be
> possible to have such a proposal ready in time to be deployed alongside
> SegWit
> to take effect in time for the upcoming subsidy halving. If this slips, I
> think it may be reasonable to push for at least code-readiness before July,
> and possibly roll it into any other hardfork proposed before or around that
> time.
>
> I am unaware of any reason this would be controversial, so if anyone has a
> problem with such a change, please speak up sooner rather than later. Other
> ideas or concerns are of course welcome as well.
>
> Thanks,
>
> Luke
> _______________________________________________
> 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/20160303/89c572a7/attachment-0001.html>

2023-06-07 17:48:46

- reply

📅 Original date posted:2016-02-07
📝 Original message:We don't have any evidence of how fast nodes will upgrade when faced with
an impending hard fork, but it seems like a very safe assumption that the
upgrade pace will be significantly faster. The hard fork case it is:
"upgrade or be kicked off the network". In the previous cases it has been,
"here's the latest and greatest, give it a go!". Also, there will be
alerts sent out warning people of the situation, prompting them to take
action.
It is unclear if this will translate into more or less than 6x the adoption
speed of previous instances, but the idea that it would be faster is
solid. 28 days is aggressive, but again, it is only 28 days from when the
fork triggers. Compatible software is already available for anyone who
wants to prepare.
It is also of significance that this proposed fork, and this debate, has
been going on for many, many months. If someone proposed a forking concept
today, wrote the BIP tomorrow, deployed it next week, miners adopted it
instantly, and 28 days later it was the flag day, those 28 days would be in
a different context. There is no surprise here.
On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
> it Gavin --
>
> ~
> "We can look at the adoption of the last major Bitcoin core release to
> guess how long it might take people to upgrade. 0.11.0 was released on 12
> July, 2015. Twenty eight days later, about 38% of full nodes were running
> that release. Three months later, about 50% of the network was running
> that release, and six months later about 66% of the network was running
> some flavor of 0.11."
>
> On what grounds do you think it is reasonable to assume that this update
> will roll out 6x faster than previous data suggested, as oppose to your own
> observation of 66% adoption in 6 month. or do you believe 38% node
> upgrade-coverage (in 28 days ) on the network for a hard fork is good
> enough?
>
> There are no harm in choosing a longer grace period but picking one short
> as 28 days you risk on alienating the nodes who do not upgrade with the
> aggressive upgrade timeline you proposed.
> ~~
>
> When Gavin writes "Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said,
> I surveyed several of the biggest infrastructure providers and the btcd
> lead developer and they all agree "28 days is plenty of time."
>
> For individuals... why would it take somebody longer than 28 days to
> either download and restart their bitcoind, or to patch and then re-run
> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
> 2000000)?"
>
> ~~
>
> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
> propositional a priori logic, but empirical evidence that. As for why
> people take longer, who knows, we simply know from passed experience that
> it in fact does take longer.
>
> It's extremely frustrating to read Gavin's comments, it's hard to believe
> he is engaging in earnest discussion.
>
> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > > > If you have a node that is "old" your node will stop getting new
>> > > > blocks. The node will essentially just say "x-hours behind" with "x"
>> > > > getting larger every hour. Funds don't get confirmed. etc.
>> > >
>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> > > blocks confirming a large 10000 BTC payment. If you're just a normal
>> end
>> > > user (or perhaps an automated system), you'll figure that payment is
>> good
>> > > and irreversibly hand over the title to the house.
>> >
>> > There will be approximately zero percentage of hash power left on the
>> > weaker branch of the fork, based on past soft-fork adoption by miners
>> (they
>> > upgrade VERY quickly from 75% to over 95%).
>>
>> I'm assuming there are literally ZERO miners left on the weaker branch.
>> The attacker in this scenario simply rents hashing for a few days in
>> advance
>> to build his fake chain, then broadcasts the blocks to the unsuspecting
>> merchant at ~10 block intervals so it looks like everything is working
>> normal
>> again. There are lots of mining rental services out there, and miners
>> quite
>> often do not care to avoid selling hashrate to the highest bidder
>> regardless
>> of what they're mining. 10 blocks worth costs a little more than 250 BTC -
>> soon, that will be 125 BTC.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> 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/20160207/db587ac0/attachment.html>

2023-06-07 17:46:34

- reply

📅 Original date posted:2015-12-17
📝 Original message:A planned hardfork, similar to certain softforks, leaves users with some
reduction in security. It does not leave them defenseless. Consider the
following:
1: Hard to be robbed on the basis of hashpower.
In reality the old chain will see mining all but stop, and blocks would be
hours to days apart even if a couple percentage points of hashpower failed
to switch over. Six confirmations would certainly take days. If the fork
can be scheduled at the beginning of a difficulty period, the old chain
would almost certainly not even ever make it to the next retargeting.
2: Hard to be robber on the basis of awareness.
Expect there to be fairly widespread coverage in the Bitcoin press, and as
the fork draws near, maybe coverage in business and tech publications.
Further, the alert keys will certainly be used, so node operators will get
the message directly.
3: There still needs to be a targeted attack by a fraudster on an unaware
node operator.
To fall victim, one needs to give up something of value to an attacker in
exchange for Bitcoins (on the old chain). The typical uninitiated
full-node user (probably a small subset anyway) is typically going to be
buying bitcoin from a trusted source, and then saving or spending them, or
perhaps gambling. They are not, typically, going to be providing a service
or selling goods in exchange for Bitcoin unless they are at least somewhat
aware of what is going on in the Bitcoin space. It's possible, of course,
but we are talking about small numbers here of people who fit the above.
All three parts of the above would have to go perfectly wrong for someone
to loose out. Someone somewhere will probably get scammed as a result of a
hardfork. That stinks, and we should make reasonable efforts to help them
avoid that fate. But at this point in Bitcoin's development, it is still
in beta, it's still an economic experiment, and we can't allow the software
to become hamstrung out of fear that some inattentive user might bungle
their security. If they merely waited for 6 confirmations, as is the
standard advice, they would be waiting for days. If that along doesn't
give them a hint that something is wrong, it might still be too early days
for them to be playing with Bitcoin for anything important.
I support a hardfork deployment that takes 80% of hashpower activate + a
4-month delay.
On Wed, Dec 16, 2015 at 9:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There are at least 2 proposals on the table:
>
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
> equals to 2MB actual limit
>
> 2. BIP102: 2MB actual limit
>
> Since the actual limits for both proposals are approximately the same, it
> is not a determining factor in this discussion
>
> The biggest advantage of SWSF is its softfork nature. However, its
> complexity is not comparable with any previous softforks we had. It is
> reasonable to doubt if it could be ready in 6 months
>
> For BIP102, although it is a hardfork, it is a very simple one and could
> be deployed with ISM in less than a month. It is even simpler than BIP34,
> 66, and 65.
>
> So we have a very complicated softfork vs. a very simple hardfork. The
> only reason makes BIP102 not easy is the fact that it's a hardfork.
>
> The major criticism for a hardfork is requiring everyone to upgrade. Is
> that really a big problem?
>
> First of all, hardfork is not a totally unknown territory. BIP50 was a
> hardfork. The accident happened on 13 March 2013. Bitcoind 0.8.1 was
> released on 18 March, which only gave 2 months of grace period for everyone
> to upgrade. The actual hardfork happened on 16 August. Everything completed
> in 5 months without any panic or chaos. This experience strongly suggests
> that 5 months is already safe for a simple hardfork. (in terms of
> simplicity, I believe BIP102 is even simpler than BIP50)
>
> Another experience is from BIP66. The 0.10.0 was released on 16 Feb 2015,
> exactly 10 months ago. I analyze the data on https://bitnodes.21.co and
> found that 4600 out of 5090 nodes (90.4%) indicate BIP66 support.
> Considering this is a softfork, I consider this as very good adoption
> already.
>
> With the evidence from BIP50 and BIP66, I believe a 5 months
> pre-announcement is good enough for BIP102. As the vast majority of miners
> have declared their support for a 2MB solution, the legacy 1MB fork will
> certainly be abandoned and no one will get robbed.
>
>
> My primary proposal:
>
> Now - 15 Jan 2016: formally consult the major miners and merchants if they
> support an one-off rise to 2MB. I consider approximately 80% of mining
> power and 80% of trading volume would be good enough
>
> 16 - 31 Jan 2016: release 0.11.3 with BIP102 with ISM vote requiring 80%
> of hashing power
>
> 1 Jun 2016: the first day a 2MB block may be allowed
>
> Before 31 Dec 2016: release SWSF
>
>
>
> My secondary proposal:
>
> Now: Work on SWSF in a turbo mode and have a deadline of 1 Jun 2016
>
> 1 Jun 2016: release SWSF
>
> What if the deadline is not met? Maybe pushing an urgent BIP102 if things
> become really bad.
>
>
> In any case, I hope a clear decision and road map could be made now. This
> topic has been discussed to death. We are just bringing further uncertainty
> if we keep discussing.
>
>
> Matt Corallo via bitcoin-dev 於 2015-12-16 15:50 寫到:
>
>> A large part of your argument is that SW will take longer to deploy
>> than a hard fork, but I completely disagree. Though I do not agree
>> with some people claiming we can deploy SW significantly faster than a
>> hard fork, once the code is ready (probably a six month affair) we can
>> get it deployed very quickly. It's true the ecosystem may take some
>> time to upgrade, but I see that as a feature, not a bug - we can build
>> up some fee pressure with an immediate release valve available for
>> people to use if they want to pay fewer fees.
>>
>> On the other hand, a hard fork, while simpler for the ecosystem to
>> upgrade to, is a 1-2 year affair (after the code is shipped, so at
>> least 1.5-2.5 from today if we all put off heads down and work). One
>> thing that has concerned me greatly through this whole debate is how
>> quickly people seem to think we can roll out a hard fork. Go look at
>> the distribution of node versions on the network today and work
>> backwards to get nearly every node upgraded... Even with a year
>> between fork-version-release and fork-activation, we'd still kill a
>> bunch of nodes and instead of reducing their security model, lead them
>> to be outright robbed.
>>
>>
> _______________________________________________
>
> 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/20151216/5e55d210/attachment.html>

2023-06-07 17:40:37

- reply

📅 Original date posted:2015-09-21
📝 Original message:If it turns out that the blocksize divide is hinging on differing developer
views on the nature of the threat posed by governments, perhaps it would be
better to defer to people who specialize in that area. There are plenty of
them operating in the Bitcoin space. I am familiar with some of the United
States based policy people, such as Jerry Brito, Alex Fowler, Constance
Choi, Jim Harper, Patrick Murck, etc.. If they are not sure how to frame
their ideas as they relate to this debate, maybe the devs could pose some
questions for them to answer. If the bitcoin policy people are not of
help, maybe we should turn to some political philosophers or something.
The main idea here is that if this is a politics question, please consider
you may be outside your area of expertise.
On Sun, Sep 20, 2015 at 5:11 PM, Dave Scotese via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mike wrote:
> ... Obama would like to restrict guns, but can't, because they are too
> popular (in the USA).
> ... Governments tolerate this sort of abuse [black markets] only because
> they believe, I think correctly, that Bitcoin can have great benefits for
> their ordinary voters and for now are willing to let the tech industry
> experiment.
>
> Those two reasons must be recognized for their differences. What does it
> mean that something is "too popular" if the ultimate goal of government is
> "great benefits for their ordinary voters"? It means the government
> assumes that some things are bad for people even though they are popular.
> Crystal meth and heroin come to mind. This is a natural concern of all
> decent parents for their children, and the reason that cultures for
> millennia have had rites of passage, wherein the child takes on the
> responsibility of determining for him or her self whether or not a popular
> thing provides great benefits. That responsibility is the birthright of
> every human being. Why is there an institution that usurps it? How do the
> people within that institution benefit from being part of it?
>
> Some history to study and answer these questions includes:
>
> - The origination of public schooling as motivated by Johann Fichte's
> public letters to his king in response to Prussia's loss to Napolean at
> Jena.
> - Franz Oppenheimer's book, The State, tracing the origination of the
> idea of a state, or group of people who make up and enforce laws.
> - Carroll Quigley's history book, Tragedy and Hope.
> - Larken Rose's book, Kicking the Dragon.
> - The Republic, by Plato, but only once you understand those other
> books.
> - If you want a shortcut, John Taylor Gatto did a five-hour interview
> which is now titled "The Ultimate History Lesson with John Taylor Gatto."
> It is heavily sourced by its producer in case anyone wants to verify the
> information he provides.
>
> I'm "notplato" for a reason.
>
> notplato
>
>
> _______________________________________________
> 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/20150920/0e792cc4/attachment-0001.html>

2023-06-07 17:34:09

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Tur, Aug 11, 2015 at 07:08 AM, *Mark Friedenbach* via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
wrote:
>Neither one of those assertions is clear. Keep in mind the goal is to have
>Bitcoin survive active censorship. Presumably that means being able to run
>a node even in the face of a hostile ISP or government. Furthermore, it
>means being location independent and being able to move around. In many
>places the higher the bandwidth requirements the fewer the number of ISPs
>that are available to service you, and the more visible you are.
>It may also be necessary to be able to run over Tor. And not just today's
>Tor which is developed, serviced, and supported by the US government, but a
>Tor or I2P that future governments have turned hostile towards and actively
>censor or repress. Or existing authoritative governments, for that matter.
>How much bandwidth would be available through those connections?
>It may hopefully never be necessary to operate under such constraints,
>except by freedom seeking individuals within existing totalitarian regimes.
>However the credible threat of doing so may be what keeps Bitcoin from
>being repressed in the first place. Lose the capability to go underground,
>and it will be pressured into regulation, eventually.
I agree on the importance of having the credible threat of being able to
operate in the underground, and for the reasons you outlined. However, I
see that threat as being inherent in the now-public-knowledge that a system
like Bitcoin can exist. The smart governments already know that
Bitcoin-like systems are unstoppable phenomena, that they can operate over
Tor and I2P, that they can and do run without central servers, and that
they can be run on commodity hardware without detection. Bitcoin itself
does not need to constantly operate in survival-mode, hunkered down, and
always ready for big brother’s onslaught, to benefit from the protection of
the ‘credible threat’.
It’s important to accurately asses the level of threat the Bitcoin system
faces from regulation, legislation, and government ‘operations’. If we are
too paranoid, we are going to waste resources or forgo opportunities in the
name of, essentially, baseless fear. When I got involved with this project
in 2012, no one really knew how governments were going to react. Had an
all out war-on-Bitcoin been declared, I think it’s pretty safe to say the
structure of the network would look different than it does today. We would
probably be discussing ways to disguise Bitcoin traffic to look like VoIP
calls, not talking about how to best scale the network. In light of the
current regulatory climate surrounding Bitcoin, I believe the best security
against a state-sponsored / political crackdown to be gained at this time
comes from growing the user base and use cases, as opposed to hardening and
fortifying the protocol. Uber is a great example of this form of
security-though-adoption, as was mentioned earlier today on this mailing
list.
If there are security or network-hardening measures that don’t come at the
expense of growing the user base and use cases, then there is no reason not
to adopt them. The recent improvements in Tor routing are a great example
of a security improvement that in no meaningful way slows Bitcoin’s
potential growth. How does this relate to the Blocksize debate? Let’s
accept that 8 MB blocks might cause a little bit, and perhaps even a
‘medium bit’ (however that is measured), of centralization. Although the
network might be slightly more vulnerable to government attack, if millions
more people are able to join the system as a result, I’d wager the overall
security situation would be stronger, owning to greatly decreased risk of
attack.
-Corey (CubicEarth)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/41b60844/attachment.html>

2023-06-07 15:46:11

- reply