Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Corey Haddad via bitcoin-dev]

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Corey Haddad via bitcoin-dev]

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Corey Haddad via bitcoin-dev]

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

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

[Corey Haddad via bitcoin-dev]

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Corey Haddad via bitcoin-dev]

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

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Corey Haddad via bitcoin-dev]

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@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@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 
>> 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  a
>>> écrit :
>>>
 Russel O'Connor recently opined
 
 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
 

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Corey Haddad via bitcoin-dev]

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

[bitcoin-dev] Fees and the block-finding process

[Corey Haddad via bitcoin-dev]

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