npub1qg…nqm4r

Last Notes

2023-06-09 15:05:58 CEST

- reply

📅 Original date posted:2022-05-03
📝 Original message:
Zman,
I was not arguing for moving things from the edge, nor was I arguing to
make Taro a BOLT. Laolu is misinterpreting my message.
I was explaining that the capabilities that would allow Taro to interact
with LN have no special relationship to Taro alone and should be designed
to accommodate any outside layer/network.
I gave specific examples of requirements that LL is portraying as Taro
Layer design, that are really just new features for LN nodes that do not
need to be network/layer-specific:
- Making LN nodes aware of assets on other networks
- Establishing commitments for (atomic) swapping for payments/routing
- Supporting the ability to exchange and advertise exchange rates for
asset pairs
- Supporting other multi-asset routes when considering routing paths,
bridging nodes with alternate assets
I don't care whether this is framed as BOLT or BLIP content, as in the end
each implementation will do what it needs to stay relevant in the market. I
care that this is framed and designed correctly, so we aren't locked into
one specific outside layer. You could argue the degree to which the above
features need to exist in the network, and whether to restrict such
features to the "edge," but my point is that an LN node that wants to be
aware of an outside network, and extra assets in addition to Bitcoin, will
need such features, and such features are not Taro-specific.
Good morning John, and Laolu,
>
> > > but instead the requirement to add several feature concepts to LN that
> > > would allow tokens to interact with LN nodes and LN routing:
> >
> > From this list of items, I gather that your vision is actually pretty
> > different from ours. Rather than update the core network to understand
> the
> > existence of the various Taro assets, instead we plan on leaving the core
> > protocol essentially unchanged, with the addition of new TLV extensions
> to
> > allow the edges to be aware of and interact w/ the Taro assets. As an
> > example, we wouldn't need to do anything like advertise exchange rates in
> > the core network over the existing gossip protocol (which doesn't seem
> like
> > the best idea in any case given how quickly they can change and the
> existing
> > challenges we have today in ensuring speedy update propagation).
>
> Adding on to this, the American Call Option problem that arises when using
> H/PTLCs:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
>
> The above objection seems to be one reason for proposing multi-asset "on
> the edge" rather than have it widely deployed in the published Lightning
> Network.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220503/d3b236c6/attachment-0001.html>

2023-06-09 15:05:58 CEST

- reply

📅 Original date posted:2022-05-01
📝 Original message:
For those who do not know me, I have been pioneering the concept of "tokens
on Lightning" for roughly three years, first by researching Liquid, then by
securing funding for RGB and assisting that project for roughly 2 years,
then by researching and implementing OmniBOLT, etc, etc. I was pitching
tokens on Lightning back when Ryan Gentry (LL bizdev) still worked at
Multicoin Capital ;)
My general thinking was that if LN could scale Bitcoin, it could scale
tokens on Bitcoin too.
I am very familiar with Bitcoin sidechains and Bitcoin-anchored token
projects, and I think each has its own tradeoffs and arguments for
existing. I could easily argue the benefits of Taro over Liquid, or Liquid
over Taro, or Omni over Taro, or Taro over Omni, etc. In my estimation,
there is no clear winner, and all of them could be obsoleted by future tech
to come anyway.
That said, I believe that the correct approach to supporting "tokens on
Lightning" is to make it a separate concern from Taro, and that LL should
create a separate BOLT proposal from the current Taro BIPs to ensure it LN
standards have a genericized protocol that all LN implementations would be
interested in supporting.
Taro is not LN-native in any particular way, as it is simply a new design
for using Taproot and M-sum trees to establish token abstractions on-chain.
In practice, there is no such thing as issuing a token "on" Lightning, but
instead the requirement to add several feature concepts to LN that would
allow tokens to interact with LN nodes and LN routing:
- Making LN nodes aware of assets on other networks
- Establishing commitments for (atomic) swapping for payments/routing
- Supporting the ability to exchange and advertise exchange rates for
asset pairs
- Supporting other multi-asset routes when considering routing paths,
bridging nodes with alternate assets
- ...probably other stuff :)
So, I ask that Lightning Labs coordinate with the LN community to ensure
such support for other networks and other assets not be dedicated only to
Taro, and instead genericized enough so that other networks may compete
fairly in the market, for the sake of Bitcoiners, and that LN standards by
flexible enough to support future advances in token tech, other sidechains
and Bitcoin layers like Omni, RGB, Rootstock, Liquid, 1WP sidechains, etc,
etc.
Otherwise, we will be left with LL's advantage being that LND supports
Taro, and weird narratives that Taro is somehow superior because LND
specifically added support for it, without creating a generic spec or BOLT
that all nodes could adopt for multi-network, multi-asset LN-as-rails use
cases.
Finally, I want to state that I do not represent any specific token
networks solutions, and our company has not finalized which token networks
it will support. If you are trying to assume where my loyalties are, you
will be wrong. I simply want *all* LN implementations and all current and
future token solutions to get fair play and maximum interoperability.
Thanks!
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220501/1f7ad737/attachment.html>

2023-06-08 01:17:29 CEST

- reply

📅 Original date posted:2022-12-05
📝 Original message:>
> The perception seems to be that Core adding the full RBF option is
> increasing the risk to zero-conf users, but I'm not convinced that that is
> the case.
If this "perception" were not true, RBF & full-RBF would not be necessary
at all. Think about it.
It's always been the risk of getting double-spent out of hundreds or
> thousands of bitcoins that's worth seriously worrying about, which is much
> more the kind of attack a determined attacker is able to carry out.
The risk exposure to merchants providing zero-conf acceptance as a service
is finite, capped by their risk-tolerance, and capped by the current block
exposure. Merchants cap their exposure to be an amount worth less than the
value of this service.
It is highly inefficient and difficult for a miner to pull off an
industry-wide attack across diverse merchants to capture the current
maximum exposure in any given block, not to mention the enormous surface
area of legal risk across jurisdictions...
I don't think zero-conf opponents properly grasp that the risk exposure is
exact and perfectly, trustlessly manageable. I would like the opportunity
to spec the methods Bitrefill, Synonym, and most such merchants, use to
make it standard practice, as it is cheaper for merchants and more
convenient to Bitcoin consumers when merchants behave this way.
As has been pointed out by may others before, full RBF is aligned with
> miner (and user) economic incentives
This is a theory, not a fact. I can refute this theory by pointing out
several aspects:
1. RBF is actually a fee-minimization feature that allows users to game
the system to spend the *least* amount in fees that correlates to their
time-preference. Miners earn less when fees can be minimized (obviously).
This feature also comes at an expense (albeit small) to nodes providing
replacement service and propagation.
2. Miners care about max fees per block, not slightly increased fees on a
minority % of incidentally replaced txns when they happen to need it. They
want the most txns for the highest price per *block*. In order to qualify
for zero-conf acceptance, merchants require that the fee rate match or
exceed an amount that makes the txn likely to be included in the very next
block. This creates a priority competition from users with high
time-preference. This creates not only more fees for miners, but more txns
from more people using the chain for commerce. This is evidenced by stats
provided recently to this mailing list, but here are more numbers from
Bitrefill:
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282
3. Miners ultimately want what users want, as more users = more txns = more
fees = higher BTC price. For all of Bitcoin's history, more users have
wanted zero-conf than replacements. This is evidenced by first-seen policy
thriving for years without disruption (until engineers actively disrupted
it, using fallible theories as justification). This is also evidenced by
the UASF battle where miners capitulated to providing the type of blocks
that users demanded, to avoid uncertainty.
4. A replaceable mempool is inherently less valuable than a first-seen
policy mempool in that Bitcoin is ultimately a ledger for a *payments*
system where people are trying to pay and be paid with certainty. A
full-RBF system would result in more real-world doublespends to existing
merchants and p2p commerce, as it is impossible to fully teach all aspects
of Bitcoin dynamics to users, particularly when they have enjoyed many
years of first-seen behavior as status quo.
Zero-conf and first-seen policies are clearly more
incentive-compatible than RBF outright for these reasons.
The long-term 'what to do about it' is to use Lightning if you want fast
> payments with risk-free instant settlement
Many zero-conf proponents work on the bleeding edge of supporting
Lightning, including myself. Lightning is not risk-free and the base layer
should not be assuming it as a primary dependency for commercial payments.
The UX and complexity of supporting Lightning is still considerable,
adoption is still very low, and there are many unsolved attack vectors and
risks that remain untested due to Lightning's low prevalence.
Further, zero-conf is also useful as a tool in improving Lightning
onboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers
are only as good as the base layer, everything else is a tradeoff.
Bitcoin core 24 with the full RBF option is already out in the wild at
> around 5%+ of running nodes and growing, so it's too late to kill it.
This is pure speculation. If Bitcoin Core publishes an update without the
mistakenly-rushed feature, the mempoolfullrbf movement is likely to die on
the vine as users opt into the latest versions more and more, as evidenced
by all older versions decreasing in usage over time. The incentive to run
old versions, just to be able to force non-RBF txns to be treated as RBF,
is lower than the incentive and likelihood of updating. Frankly, such an
incentive is mostly obscure, vindictive, and perverse, IMO.
We should remove the mempoolfullrbf feature immediately from Bitcoin Core
distributions, as requested here:
https://github.com/bitcoin/bitcoin/pull/26525
This mistake demands correction, and no one has provided a
rational beneficial argument so far for breaking the user space and
disrupting mempool harmony.
If you would like further arguments and refutations of full-RBF, please
read all of the posts in my PR thread:
https://github.com/bitcoin/bitcoin/pull/26525
Thank you,
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
Date: Mon, 05 Dec 2022 12:21:44 +0000
> From: angus <angus at toaster.cc>
> To: Daniel Lipshitz <daniel at gap600.com>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
> danger
> Message-ID:
>
> <-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc>
>
> Content-Type: text/plain; charset="utf-8"
>
> Core adding full RBF is a change of node policy that may be highly
> inconvenient for zero-conf users, but there has always been and will always
> be a risk of a double-spend for anyone that treats zero-confirmation
> transactions as settled. It's literally in the name - this transaction has
> zero confirmations and no guarantee it'll make it into a block, and so has
> not yet settled.
>
> The perception seems to be that Core adding the full RBF option is
> increasing the risk to zero-conf users, but I'm not convinced that that is
> the case - someone wanting to double-spend attack you isn't going to be
> bothered to do so over a few thousand sats (unless they can do it thousands
> of times), and losing a few thousand sats to a double-spend isn't the
> biggest deal.
>
> It's always been the risk of getting double-spent out of hundreds or
> thousands of bitcoins that's worth seriously worrying about, which is much
> more the kind of attack a determined attacker is able to carry out. Such a
> determined attacker is much more likely to attempt and succeed at a sybil
> attack, or directly colluding with a miner. So your zero-conf risk
> increases non-linearly as the amount of bitcoin being transacted grows.
> (caveat: this paragraph is opinion).
>
> There does, however, seem to be a legitimate business for providing
> insurance/risk management for people that are willing to accept the
> zero-conf risk - it is pretty similar to accepting credit cards with a
> chargeback risk or any payment card with a capture risk, though there's
> no-one to mediate a dispute. On-chain is final.
>
> But what doesn't make any sense is trying to avoid Bitcoin Core and nodes
> from adopting a full RBF policy to try to protect this use case. As has
> been pointed out by may others before, full RBF is aligned with miner (and
> user) economic incentives and is a node policy, not consensus, so you can't
> even tell which nodes are doing it nor can you prevent them from doing so.
> Second, Bitcoin core 24 with the full RBF option is already out in the wild
> at around 5%+ of running nodes and growing, so it's too late to kill it.
>
> So my point is that relying on node policy as part of your protection for
> zero-conf transaction acceptance is fragile, and should not be relied upon.
> The protocol rules have always tacitly allowed double-spending before a
> confirmation, and it has always been clear that there's no consensus on
> which transactions have occurred until they have in a block and have
> at-least one confirmation.
>
> The long-term 'what to do about it' is to use Lightning if you want fast
> payments with risk-free instant settlement, or as above, accept the
> zero-conf risk and cover yourself with an insurance premium (e.g. a margin
> on transactions that goes into an insurance fund, and limiting max
> transaction amount so you're not exposed to uncoverable losses if you do
> get double-spend attacked)
>
> Angus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/f3d67ada/attachment-0001.html>

2023-06-08 01:15:51 CEST

- reply

📅 Original date posted:2022-10-27
📝 Original message:Anthony,
I took the time to read your whole post. Despite a diplomatic tone, I find
your takeaways from all your references to remain conveniently biased for
protecting the plan of RBF via passive aggression.
You show multiple examples where, when I read them, I assume the next thing
you will say will be "so we really should stop trying to impose optional
features, particularly when they affect existing use cases" but instead you
persist.
The problem is that RBF has already been an option for years, and anyone
that wants to use it can. Any escalation in Bitcoin Core code to support it
more deeply, or by default, is basically an unfair advantage to force the
market to do what it already has decided not to.
If wallets want to default to RBF, they can already do so, as evidenced by
Green Wallet (which I stopped using because it breaks the UX at Bitrefill).
Instead of Core devs admitting RBF is a minority use case, you seem to be
proposing that the market should now be obligated to prove it can defeat
RBF in a stronger form if it really wants to prove other use cases. This is
oppressive, dark-pattern design. We all know that Core has little ability
to sense the market, and the market has little ability to express itself to
Core. The idea that the market can always downvote or defeat a feature or
new complexity proposal is idealistic and unrealistic.
Superficial features should be decided at the surface (app level) not in
the protocol or node.
The default answer to ALL proposals is "No." Changes need to win market
acceptance, not get special access through Core devs baking them deeper and
deeper into the protocol and policies until everyone is forced into a new
design.
As I mentioned before, this behavior, if we are lucky, will result in more
mempool types, more implementations, and a more-difficult to modify
protocol, but ALL feature changes, default settings that make decisions for
users, and even all scaling changes, are speculative risks with
unpredictable outcomes.
I urge the culture of Core to respect these dynamics and become much more
conservative with proposing change. Please focus on efficiencies, bugs,
cleanup, reducing overhead, etc.
The current RBF movement feels like Core is strong-arming and shoe-horning
in a change that the market is not actually asking for. It is okay to leave
things as they are. It is okay if RBF remains a niche feature. It is not
okay for a small group of RBF-interested engineers to make commercial
Bitcoin use cases worse.
Let us realize the Bitcoin we already have. We already have a largely
unexplored canvas of taproot, lightning, UX, etc.
I expect the things I do with Bitcoin today to work FOREVER.
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
> Date: Thu, 27 Oct 2022 09:52:10 +1000
> From: Anthony Towns <aj at erisian.com.au>
> To: Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] On mempool policy consistency
> Message-ID: <Y1nIKjQC3DkiSGyw at erisian.com.au>
> Content-Type: text/plain; charset=us-ascii
>
> Hi *,
>
> TLDR: Yes, this post is too long, and there's no TLDR. If it's any
> consolation, it took longer to write than it does to read?
>
> On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> > I'm writing to propose deprecation of opt-in RBF in favor of full-RBF
>
> > 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.
>
> One precedent that seems to be being set here, which to me seems fairly
> novel for bitcoin core, is that we're about to start supporting and
> encouraging nodes to have meaningfully different mempool policies. From
> what I've seen, the baseline expectation has always been that while
> certainly mempools can and will differ, policies will be largely the same:
>
> Firstly, there is no "the mempool". There is no global mempool. Rather
> each node maintains its own mempool and accepts and rejects transaction
> to that mempool using their own internal policies. Most nodes have
> the same policies, but due to different start times, relay delays,
> and other factors, not every node has the same mempool, although they
> may be very similar.
>
> -
> https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-transactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by different
> nodes running core have been quite small, with essentially the following
> options available:
>
> -minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
>
> -mempoolexpiry - how long to keep txs in the mempool
>
> -datacarrier - reject txs creating OP_RETURN outputs
>
> -datacarriersize - maximum size of OP_RETURN data
>
> -permitbaremultisig - prevent relay of bare multisig
>
> -bytespersigop - changes how SIGOP accounting works for relay and
> mining prioritisation
>
> as well as these, marked as "debug only" options (only shown with
> -help-debug):
>
> -incrementalrelayfee - make it easier/harder to spam txs by only
> slightly bumping the fee; marked as a "debug only" option
>
> -dustrelayfee - make it easier/harder to create uneconomic utxos;
> marked as a "debug only" option
>
> -limit{descendant,ancestor}{count,size} - changes how large the
> transaction chains can be; marked as a "debug only" option
>
> and in theory, but not available on mainnet:
>
> -acceptnonstdtxn - relay/mine non standard transactions
>
> There's also the "prioritisetransaction" rpc, which can cause you to keep
> a low feerate transaction in your mempool longer than you might otherwise.
>
> I think that -minrelaytxfee, -maxmempool and -mempoolexpiry are the only
> ones of those options commonly set, and those only rarely result in any
> differences in the txs at the top of the mempool.
>
> There are also quite a few parameters that aren't even runtime
> configurable:
>
> - MAX_STANDARD_TX_WEIGHT
> - MIN_STANDARD_TX_NONWITNESS_SIZE (see also #26265)
> - MAX_P2SH_SIGOPS (see also #26348)
> - MAX_STANDARD_TX_SIGOPS_COST
> - MAX_STANDARD_P2WSH_STACK_ITEMS
> - MAX_STANDARD_P2WSH_STACK_ITEM_SIZE
> - MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE
> - MAX_STANDARD_P2WSH_SCRIPT_SIZE
> - MAX_STANDARD_SCRIPTSIG_SIZE
> - EXTRA_DESCENDANT_TX_SIZE_LIMIT
> - MAX_REPLACEMENT_CANDIDATES
>
> And other plausible options aren't configurable even at compile time
> -- eg, core doesn't implement BIP 125's inherited signalling rule so
> there's no way to enable it; core doesn't allow opting out of BIP 125
> rule 3 ratchet on absolute fee; core doesn't allow CPFP carveout with
> more than 1 ancestor; core doesn't allow opting out of LOW_S checks
> (even via -acceptnonstdtxn); etc.
>
> We also naturally have different mempool policies between different
> releases: eg, expansions of policy, such as allowing OP_RETURN or
> expanding it from 40 to 80 bytes or new soft forks where old nodes won't
> relay transactions that use the new; and also occassional restrictions
> in policy, such as the LOW_S requirement.
>
>
> While supporting and encouraging different mempool polices might be new
> for core, it's not new for knots: knots changes some of these defaults
> (-permitbaremultisig defaults to false, -datacarriersize is reduced to
> 42), allows the use of -acceptnonstdtxn on mainnet, and introduces new
> options including -spkreuse and -mempoolreplacement (giving the latter
> full rbf behaviour by default). Knots also includes a `-corepolicy`
> option to make it easy to get a configuration matching core's defaults.
>
>
> I think gmaxwell's take from Feb 2015 (in the context of how restrictive
> policy on OP_RETURN data should be) was a reasonable description for
> core's approach up until now:
>
> There is also a matter of driving competent design rather than lazy
> first thing that works. E.g. In stealth addresses the early proposals
> use highly inefficient single ECDH point per output instead of simply
> pooling them. Network behavior is one of the few bits of friction
> driving good technical design rather than "move fast, break things, and
> force everyone else onto my way of doing thing rather than discussing
> the design in public". No one wants to be an outright gatekeeper,
> but the network is a shared resource and it's perfectly reasonable
> node behavior to be stingy about the perpetual storage impact of the
> transactions they're willing to process, especially when it comes to
> neutral technical criteria like the amount of network irrelevant data
> stuffed in transactions.
>
> There is also a very clear pattern we've seen in the past where
> people take anything the system lets them do as strong evidence that
> they have a irrevocable right to use the system in that way, and that
> their only responsibility-- and if their usage harms the system it's
> the responsibility of the system to not permit it. [...
> ...] For mitigating these risks it's optimal if transactions
> seem as uniform and indistinguishable as reasonably possible.
>
> - https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-72564175
>
> Perhaps see also sdaftuar in Nov 2015,
>
> To me the most important question is, is priority something that miners
> want to use?
>
> If a non-negligible amount of hashpower intends to use it in their
> transaction selection, then I think it makes sense for nodes to use it
> too, because it's generally helpful to have your mempool predict the
> UTXO as much as possible, and for nodes to be able to have reasonable
> fee and priority estimates (which won't happen unless they track the
> priority transactions somehow -- I'm presuming that miners run with
> much bigger mempools than regular nodes).
>
> If the answer is no, then that's fine and I don't see a reason to push
> in this direction. I sort of assumed there was enough hashpower mining
> with priority, since last time I checked estimatepriority was still
> giving meaningful results for low-ish blockheights, but I haven't done
> any kind of real analysis.
>
> - https://github.com/bitcoin/bitcoin/pull/6992#issuecomment-155969455
>
> or in June 2019,
>
> What this PR is proposing is to get rid of a command-line option that is
> (a) a footgun for users and (b) does not reflect what I believe to be
> the understanding most users have, which is that [X txs] are expected
> to propagate well on the network.
>
> ..
>
> I don't think this rises to the level that Luke is concerned about,
> namely a prelude to forcing a common relay policy on all nodes. In
> particular I do agree it makes sense that we offer some ways of
> customizing policy parameters (eg the mempool size, min relay fee,
> etc). Instead, I think the justification for this change is that we
> should not support behaviors we think are harmful to the ecosystem
> overall and have no legitimate use-case, and we should eliminate ways
> that users might inadvertently shoot themselves in the foot.
>
> - https://github.com/bitcoin/bitcoin/pull/16171#issuecomment-500393271
>
> (or see discussion in https://github.com/bitcoin/bitcoin/pull/7219)
>
> I don't mean to imply the above are saying "there's one way to do
> things and it's this way", or that the old way of doing things should
> necessarily be the way we keep doing things. Just that previously core
> has tended towards designing a single policy that works as well as it
> can for everyone and the ecosystem as a whole. (I'm also not saying that
> fullrbf can't work well for everyone or the ecosystem as a whole)
>
>
> By contrast, I think the most common response to pushback against the
> full rbf option has been along the lines of "it's just an option, we
> don't want to force people", eg:
>
> Blaming the default false -mempoolfullrbf option for a full RBF network
> would be holding Bitcoin Core developers responsible for the decisions
> of individual node operators and miners. I don't think having the
> option (again, default false) can directly cause a full RBF network,
> and likewise, I don't think removing this option removes the "risk"
> of a full RBF network.
> - glozow
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274949400
>
> NACK. This is a default false option.
> - achow101
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
>
> Erecting artificial barriers to prevent or make it difficult for users
> to do what they want to do, is not appropriate behaviour.
> - luke-jr
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1290721905
>
> I'm in general against removing options.
> - instagibbs
> https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292030700
>
> I think this differs from what core has done in the past, in that
> previously we've tried to ensure a new policy is good for everyone (or as
> nearly as it can be), and then enabled it as soon as it's implemented.
> Any options that have been added have either been to control resource
> usage in ways that don't significantly effect tx propagation, to
> allow people to revert to the old behaviour when the new behaviour is
> controversial (eg the -mempoolreplacement=0 option from 0.12 to 0.18),
> and to make it easier to test/debug the implementation.
>
> Giving people a new relay behaviour they can opt-in to when we aren't
> confident enough to turn on by default doesn't match the approach I've
> seen core take in the past.
>
>
> If this is going to be an ongoing shift in how core sees relay/mempool
> policy, I think that's significant and worth paying attention to.
>
> I don't think it's necessary to have that shift to roll out full rbf.
> The other approach would be either:
>
> * set -mempoolfullrbf=true as the default for 24.0, and just have the
> command line param there in case people want to do a
> "UserRejectedMempoolPolicy" campaign to get everyone to opt-out
>
> * revert it for now because we don't think mainnet is ready for fullrbf
> yet, and introduce it as default true for 25.0 or 26.0 or 27.0 or
> to activate at some scheduled date in that timeframe (potentially
> backporting it to previous releases to help with adoption too,
> whatever). same effect as the previous option, just with a bit more
> advanced notice and time to prepare
>
> I don't think anyone's proposed the first (which I interpret as "most of
> us don't think mainnet is ready for fullrbf today"), but the comments
> above are all pushback by people arguing against (the first step of)
> the second approach, and they seem to be winning the day.
>
> It's also possible that this is something of a one time thing: full rbf
> has been controversial for ages, but widely liked by devs, and other
> attempts (eg making it available in knots) haven't actually achieved
> much of a result in practice. So maybe this is just a special case and
> not a precedent, and when people propose other default false options,
> there will be substantially more resistance to them being merged,
> despite all the talk about users having options that's going on right now.
>
>
> Assuming it is the change of direction it appears to be -- and all of
> the above is really just justification for that assumption -- then like
> I said, I think it's worth seriously considering what it means for people
> to choose their own relay/mempool policies and for you to expect to have
> different mempool policies to many or most of your potential peers.
>
>
> One thing maybe worth noting is that is that you can still only choose
> your policy from options that people write code for -- if it wasn't
> something you could get by running knots or compiling a rejected PR
> yourself, it won't magically become more possible now. Presumably it
> would mean that once a PR is written, it might get better review (rather
> than being dismissed as not suitable for everyone), and there would be
> less maintenance burden than if it had to be manually rebased every
> release, though (or at least the maintenance burden would be shared
> across everyone working on the codebase).
>
>
> The second thing is that whatever your relay policy is, you still
> need a path all the way to miners through nodes that will accept your
> transaction at every step. If you're making your mempool more restrictive
> (eg -permitbaremultisig=0, -datacarrier=0), that's easy for you (though
> you're making life more difficult for people who do create those sorts
> of txs); but if you want a more permissive policy (package relay,
> version-3-rbf, full-rbf), you might need to do some work.
>
> The cutoff for that is probably something like "do 30% of listening
> nodes have a compatible policy"? If they do, then you'll have about a
> 95% chance of having at least one of your outbound peers accept your tx,
> just by random chance. If erlay allows increasing your outbound count to
> 12 connections instead of 8; that might reduce down to needing just 20%
> of listening nodes (~93%).
>
> But for cases where less than 30% (20%) of network supports your preferred
> policy, you probably need to do something cleverer.
>
> One approach is to set a service bit and preferentially peer with other
> nodes that advertise that service bit; knots does the first half of this
> for fullrbf, and both halves have been proposed for core in #25600.
> Preferential peering was previously done for the segwit deployment,
> though in that case it was necessary not just for tx propogation but
> also for ensuring block propogation, making it effectively a consensus
> critical issue.
>
> Another approach is having a separate relay network -- eg, lightning nodes
> already have a gossip network, and might want to help their own ecosystem
> by ensuring unilateral channel closes and justice transactions are quickly
> relayed. Using their own gossip network to relay the transaction around,
> and each lightning node adding it to their local bitcoind's mempool and
> allowing it to propogate (or not) from there as normal, would also be a
> way of allowing transactions to propogate well. It does mean that miners
> would either need to also participate in lightning gossip directly, or
> that miners would need to connect to *many* peers to be confident of
> seeing those transactions (eg, if only 2% of the network would see a
> tx, you'd need to make 228 connections to have a 99% chance of seeing
> the tx). You can't currently do something like this, because all the
> relay policies are also applied when adding txs to the mempool via RPC,
> and there's no convenient way to remove txs from the mempool.
>
> A case where something like that might occur is in preventing L2
> transactions from pinning attacks -- so you might have a high-fee,
> low-feerate transaction that's been widely propogated, sitting in the
> bottom of people's mempools, and you want to replace it with a smaller,
> higher-feerate transaction, but don't want to pay a higher absolute fee,
> and are thus blocked by BIP 125 rule 3. Perhaps 98% of the network is
> unwilling to deviate from BIP 125 rule 3 for you; because that would
> make it easy for random griefers to spam their mempool with large txs
> then delete them while only paying a small fee; but your L2 peers may be
> able to decode your replacement transaction and be sure that you aren't
> going to spam them, and thus will happily relay it.
>
> >From a technical point-of-view, that's largely fine; the downside is it
> increases the centralisation pressure on mining: whether that's by having
> to connect to substantially more nodes, or having to parse through more
> spam, you can't just run your mining operation off a standard install
> of bitcoin core anymore, but need to actively opt-in to find all the
> weird unusual ways people are sending transactions around in order to
> actually collect as much in fees as your competitors are.
>
> That's probably moderately bad for privacy as well -- if lightning or
> coinjoins need special relay rules that most nodes haven't opted into,
> it's potentially easy to use that to find the bitcoin nodes on the
> network that are participating in those protocols, and from there to
> either identify the operator, or run a DoS attack to make it hard for you
> to keep doing what you want. Obviously if you're setting a service bit to
> get better routing, you've given up that privacy already. Likewise if the
> government or random vandals are opposed to bitcoin mining, and miners
> have to have special configuration on their nodes that distinguish them
> from regular users, then perhaps that makes it easier to find or shut
> down their operations.
>
> There are a few efficiencies to be gained from similar mempool policies as
> well: more reliable compact block reconstruction (if you're not missing
> any transactions, you avoid a round-trip) and presumably more efficient
> set reconstruction with erlay. You'll also waste less bandwidth sending
> transactions that the other node is only going to reject. Both those
> depend on how many transactions are going to rely on unusual mempool
> policies in the first place though.
>
> ariard wrote:
>
> I know I've advocated in the past to turn RBF support by default in
> the past. Though after gathering a lot of feedbacks, this approach
> of offering the policy flexiblity to the interested users only and
> favoring a full-rbf gradual deployment sounds better to me.
>
> - https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1157137026
>
> I guess all the above leads me to think that gradual deployments of
> mempool policies are likely the worse approach: even when they're not
> hurting anyone, it makes them hard to use during the gradual phase,
> and getting around that comes with worrying compromises on privacy and
> centralisation; and when they are problematic for some, the indeterminate
> nature of a gradual deployment means it's hard to plan for when that
> risk is going to eventuate.
>
>
> Theoretically, one way to recover the good parts of core deciding on
> what's good for the network might be for people outside of core to
> recommend a mempool configuration; then core can just have an option
> to make that easy, similar to "-std=c++17" for a C++ compiler, and much
> the same as knots' "-corepolicy" option.
>
> Presuming anyone actually wants to take on that job, and listen to the
> concerns of zeroconf businesses, lightning and coinjoin devs, miners, etc;
> and can come up with something that keeps most of them happy, and that
> 70% or 90% of the network ends up just following those recommendations
> because it's easy, it works, and it's recommended by all the apps they
> want to use, then that could work great:
>
> * miners don't need to do anything special, so there's no new
> mining centralisation pressure
> * miners and users don't reveal what they're doing with bitcoin by the way
> they configure their nodes, so there's no privacy problems
> * devs can be fairly confident in how they have to design their apps
> in order to get their transactions to most hashpower
> * devs don't have to add new p2p layers to make it happen
> * at least there's someone to talk to when you're trying to figure out
> how to make some new project possible when it's inhibited by current
> relay policies and you don't have to try to convince everyone to
> upgrade on your own
> * core devs just provide options, and don't have to worry about being
> seen as gatekeepers
>
> The "downside" in that scenario is that users/dev aren't making much
> actual use of all the choices core is offering by making different
> options available; but the upside is that that choice is at least readily
> available should whoever is coming up with these policy become out of
> step with what people actually want.
>
> One thing that might make an approach like that difficult is that core
> has historically been happy to remove options that don't seem useful
> anymore: eg the ability to turn of BIP 125 support (#16171), and priority
> transactions (#9602). Perhaps that's fine if you're trying to actively
> craft a single mempool/relay policy that's good enough for almost everyone
> (after all, it makes the code simpler and more efficient, and reduces
> the number of footguns); all you're doing is leaving a minority of people
> who want weird things to run a fork, and that's going to happen anyway.
>
> But if people are following policy developed outside of core, core
> might well disagree with them and decide "no that's a stupid policy,
> no one should do that" and remove some feature that others thing should
> continue to be normal. Beyond the examples above, there's already talk of
> removing the ability to disable fullrbf support in #26305, for instance.
> If that happens, then the people maintaining the policy will instead
> end up maintaining an entire fork of bitcoin core, and all we've done
> is transition to people running software from a different repo, and a
> different set of maintainers.
>
> If we're really going to a world where core's eager to add new options,
> and reluctant to remove them, at least if anyone at all finds them
> interesting, that's presumably a non-issue, though.
>
> Cheers,
> aj
>
>
> ------------------------------
>
> 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 89, Issue 77
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/1585a093/attachment-0001.html>

2023-06-08 01:14:33 CEST

- reply

📅 Original date posted:2022-10-15
📝 Original message:Peter,
Your argument is totally hypocritical and loses when comparing quantities.
Enforcing RBF is observably more "harmful to Bitcoin" (whatever that
means...) when it tries to "risk-manage propagation" of replacements, as
there more Bitcoiners that want to mutually utilize 0conf than users that
want to replace transactions.
Spending bitcoin is a use case, so replacing txns reduces utility and makes
commitments less certain.
No one here arguing for 0conf is suggesting reorgs, so please do not
sensationalize with claims of reorgs or "harm."
Take note that it is RBF proponents that have changed Bitcoin code and seek
to continue to change Bitcoin, RBF that seeks to reduce commercial utility
-- but 0conf proponents are not asking for changes to Bitcoin, not
suggesting soft or hard forks, etc. We are asking you to stop breaking
things by adding features for minority speculative interests.
-John
On Fri, Oct 14, 2022 at 5:04 PM Peter Todd <pete at petertodd.org> wrote:
> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
> wrote:
> > In support of Dario's concern, I feel like there is a degree of
> gaslighting
> > happening with the advancement of RBF somehow being okay, while merchants
> > wanting to manage their own 0conf risk better being not okay.
>
> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
> Connecting to large numbers of nodes to try to risk-manage propagation
> _is_ an
> attack, albeit a mild one. Everyone doing that is very harmful; only a few
> merchants being able to do it is very unfair/centralized.
>
> ...and of course, in the past this has lead to merchants trying to make
> deals
> with miners directly, even going as far as to suggest reorging out
> double-spends. I don't need to explain why that is obviously extremely
> harmful.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221015/e01898e5/attachment.html>

2023-06-08 01:14:32 CEST

- reply

📅 Original date posted:2022-10-15
📝 Original message:Erik, I am fully aware of Lightning and have a been a proponent and builder
of it since it was launched, including getting Bitfinex to support LN,
building a RN LDK implementation in our upcoming app, etc, but frankly LN
has nowhere near the adoption of onchain payments for commerce, and LN
complexity, reliability, maintenance and overhead are real obstacles for
merchants.
One of your links is to Muun, who started this thread!
There is no practicality in a merchant saying they accept bitcoin, but not
onchain, or in having many checkout and customer service versions for many
bitcoin payment methods.
Merchants accepting base layer bitcoin is one if the most important types
of adoption there is.
-John
On Fri, Oct 14, 2022 at 6:29 PM Erik Aronesty <erik at q32.com> wrote:
> Also, lightning works fine and is readily available in convenient mobile
> apps used by millions of people, or in . So the need for a 0conf has been
> mitigated by other solutions for fast payments with no need for a trust
> relationship. And for people that don't like mobile risks, core lightning
> and other solutions are now easily installed and configured for use in fast
> payments.
>
> some references:
>
> https://muun.com/ (easy!)
> https://github.com/ElementsProject/lightning (reference, works well with
> core)
> https://lightning.network/ (more info)
>
>
> On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
>> wrote:
>> > In support of Dario's concern, I feel like there is a degree of
>> gaslighting
>> > happening with the advancement of RBF somehow being okay, while
>> merchants
>> > wanting to manage their own 0conf risk better being not okay.
>>
>> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
>> Connecting to large numbers of nodes to try to risk-manage propagation
>> _is_ an
>> attack, albeit a mild one. Everyone doing that is very harmful; only a few
>> merchants being able to do it is very unfair/centralized.
>>
>> ...and of course, in the past this has lead to merchants trying to make
>> deals
>> with miners directly, even going as far as to suggest reorging out
>> double-spends. I don't need to explain why that is obviously extremely
>> harmful.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221015/ff6d390f/attachment-0001.html>

2023-06-08 01:14:31 CEST

- reply

📅 Original date posted:2022-10-14
📝 Original message:In support of Dario's concern, I feel like there is a degree of gaslighting
happening with the advancement of RBF somehow being okay, while merchants
wanting to manage their own 0conf risk better being not okay.
The argument against 0conf acceptance seems to be "miners can facilitate
doublespends anyway, and are incentivized to do so if the fees are higher"
as this is just how Bitcoin works.
But RBF proponents seem to be taking what is actually a much rarer, and
less useful, use case of replacing txns that lowball feerates, or actually
undoing/doublespending previously signed payments... and threaten the use
case of onchain bitcoin being useful at the point-of-sale for merchants and
consumers.
I can tell you right now where this leads. It leads to miners, merchants
and consumers creating alternative fee mechanisms and trusted/exclusive
mempools where first-seen txns are respected.
The truth is that doublespending is not a certain process, and in many
commercial situations, too risky to attempt without real-world consequences.
0conf payment acceptance comes with highly *manageable* risks, which means
that if best practices and methods are used by merchants, and *gasp*
advanced by engineers with better tools and specs, that we can have fast
and valuable commercial payments with merchants that meet user
expectations. In fact, we may even be able to do so with less complexity
than Lightning and with similar results and overhead...
That said, we are (myself and a group of builders and merchants) moving
forward with demonstrating, protecting, and advancing this use case,
to contrast the trend of making the mempool less predictable and easier to
replace.
RBF causes more problems than it resolves, and if your argument is that
0conf was never safe, then mine is that RBF was never needed. We should not
pretend that the mempool is enforceable for either cause, and should
respect that incentives will always prevail eventually.
To me, use cases for spending Bitcoin are more important to protect than
features for pretending you can enforce mempool behaviors or pretending you
can reliably provide replacement features.
If anyone is interested in research, specs, and tools and assisting our
group, you can contact me directly, or join the public chat at
https://t.me/bitcoinandlightningspecs
Thanks,
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221014/d5ebbd52/attachment.html>

2023-06-08 01:11:06 CEST

- reply

📅 Original date posted:2022-07-08
📝 Original message:vjudeu at gazeta.pl, what you describe is not possible without a hard fork,
just like Eric said. There is no atomic way to move Bitcoin off of Bitcoin.
You can use Bitcoin txns, or you can use trust/custody, or you can make a
shitcoin. There is no way to actually divide or transfer sats to another
network.
This talk of inflation is absurd and forced and ignores all understanding
of Bitcoin and economic primitives. You would all do better to listen to
Eric and appreciate him taking the time to elaborate.
In the end, I will reiterate. Proof of work and the difficulty adjustment
scheme already solve all of these issues. When blockspace demand increases,
fees increase, more miners mine, security goes up. Thus any theoretical
supply increase would have the opposite effect.
All of these arguments for inflation amount to "That restaurant is too
popular, nobody goes there anymore." If people are using Bitcoin, miners
will mine. If all Bitcoin users are hodling only, then demand is gone, and
miners will leave. It is elegant.
Stop trying to fix Bitcoin, it isn't broken.
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
On Fri, Jul 8, 2022 at 5:59 AM <vjudeu at gazeta.pl> wrote:
> > Simply fork off an inflation coin and test your theory. I mean, that’s
> the only way it can happen anyway.
>
> That would be an altcoin. But it can be done in a simpler way: we have 21
> million coins. It doesn't matter if it is 21 million, if it is 100 million,
> or if it is in some normalized range from 0 to 1, where you can always
> know, what fraction of the total supply you have. So, if the total supply
> is constant, then it is all about proportions. And that means, you can
> create some system on top of Bitcoin, that would move coins from users to
> miners. It is all about that: if all coins are mined, then they can move
> only if users will move them. So if you want to change that, it is all
> about encouraging them to put their coins in some evil Lightning channel,
> when they will lose their coins over time. That's how inflation works.
>
> So, imagine some evil channel, where you can put for example 0.01 BTC, and
> have a time-based fee, so you will pay 1000 satoshis per day. Guess what:
> 1000 days, and your coins are gone! That means, if anyone want to test
> inflation, it is possible right here and right now. Good luck to convince
> people to use your inflationary system in a non-obfuscated way, because
> that's how it truly looks like: if you double coin supply, you can reach
> the same by halving all amounts.
>
>
> On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Value is subjective, though a constraint of 1tx per 10 minutes seems
> unlikey to create a fee of 5000x that of 5000tx. This is of course why I
> stated my assumption. Yet this simple example should make clear that at
> some point a reduction in confirmation rate reduces reward. Otherwise a
> rate of zero implies infinite reward.
>
>
> You cannot support the blanket statement (and absent any assumption) that
> lower confirmation rates produce “much higher fees” or “better security”.
>
>
> What you call a “bidding war” is merely market pricing, as it occurs with
> any good. People *always* will pay as much as they will pay. This is
> tautological. What you cannot say is how much more someone will pay at any
> given time for any given good, until they have done it. And I’m pretty sure
> Bitcoin hasn’t done it.
>
>
> You cannot prove what the price of anything will be, nor can any “papers”.
> The absurdity of S2F should have clearly demonstrated that by now. Value is
> an individual human preference.
>
>
> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
> these people are not getting confirmed (economic rationality always
> assumed).
>
>
> The assumption of 1 sat txs filling blocks is based on a
> disproportionately high subsidy. A subsidy of 50btc would imply somewhere
> in the neighborhood of $200 per tx in fees today, and as $680. As that
> falls, fees will continue to keep miners at the same profit level. If
> demand does not rise to compensate (as it always has) then hash rate will
> fall.
>
>
> Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin
> is a market money. Like gold it is produced at market cost. Yet it will
> prevent Bitcoin from achieving any meaningful level of censorship
> resistance. This of course should make people look closely at such
> arguments.
>
>
> Of course, once you have a censor, block space gets really small for those
> who want to resist the censor. Then of course only fees can offset the
> censorship. Without fee-based tx confirmation (for anonymity), and/or with
> a disproportionate subsidy going to the censor, a censor can operate
> profitably and indefinitely (under the assumption of constant demand).
> There is no reason to assume demand for censored txs wouldn’t even
> increase, given the white market blessing which so many seem to want.
>
>
> But there is of course no real issue here. Simply fork off an inflation
> coin and test your theory. I mean, that’s the only way it can happen anyway.
>
>
> e
>
>
> On Jul 7, 2022, at 14:11, Erik Aronesty <erik at q32.com> wrote:
>
>
>
> The relationship between block size and fees is not remotely linear. In
> a restricted environment, the fee rewards are much higher.
>
>
> **the ones moving more sats will win the top spots and will pay as much as
> is reasonable**
>
>
> Smaller blocks produce better security for the network both in validation,
> and in fees.
>
>
> Without a bidding war for space, everyone can post 1 SAT/byte
>
>
> With a bidding war for space, larger transactions will pay much higher
> rates. There have been a number of papers written on this but you can
> concoct a trivial example to prove it.
>
>
>
>
> On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric at voskuil.org> wrote:
>
>
>
> It’s not clear how reducing block size changes the fee aspect of the block
> reward. Assuming half the space implies twice the fee per avg tx the reward
> remains constant.
>
>
> Any additional cost of processing more or less bytes would not matter,
> because of course this is just a cost that gets nulled out by difficulty —
> average profit (net income) is the cost of capital.
>
>
> The reason for smaller vs. larger blocks is to ensure that individuals can
> afford to validate. That’s a threshold criteria.
>
>
> Given unlimited size blocks, miners would still have to fix a point in
> time to mine, gathering as much fee as they can optimize in some time
> period presumably less than 10 minutes. The produces a limit to transaction
> volume, yet neither reward nor profit would be affected given the above
> assumptions. The difference would be in a tradeoff of per tx fee against
> the threshold.
>
>
> Given Moore’s Law, that threshold is constantly decreasing, which will
> make it cheaper over time for more individuals to validate. But the
> difference for miners for smaller blocks is largely inconsequential
> relative to their other costs.
>
>
> Increasing demand is the only thing that increases double spend security
> (and censorship resistance assuming fee-based reward). With rising demand
> there is rising overall hash rate, despite block reward and profit
> remaining constant. This makes the cost of attempting to orphan a block
> higher, therefore lowering the depth/time requirement implied to secure a
> given tx amount.
>
>
> These are the two factors, demand and time. Less demand implies more time
> to secure a given amount against double spend, and also implies a lower
> cost to subsidize a censorship regime. But the latter requires a
> differential in reward between the censor and non-censoring miners. While
> this could be paid in side fees, that is a significant anonymity issue.
>
>
> e
>
>
> On Jul 7, 2022, at 10:37, Erik Aronesty <erik at q32.com> wrote:
>
>
>
> > > We should not imbue real technology with magical qualities.
>
>
> > Precisely. It is economic forces (people), not technology, that provide
> security.
>
>
>
> Yes, and these forces don't prevent double-spend / 51% attacks if the
> amounts involved are greater than the incentives.
>
>
> In addition to "utility", lowering the block size could help prevent this
> issue as well... increasing fee pressure and double-spend security while
> reducing the burden on node operators.
>
>
> Changes to inflation are, very likely, off the table.
>
>
>
>
>
>
> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev
> wrote:
> >> Billy,
> >>
> >> Proof of work and the difficulty adjustment function solve literally
> >> everything you are talking about already.
> >
> > Unfortunately you are quite wrong: the difficulty adjustment function
> merely
> > adjusts for changes in the amount of observable, non-51%-attacking,
> hashing
> > power. In the event of a chain split, the difficulty adjustment function
> does
> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
> > against a censor, the difficulty adjustment does nothing.
>
> Consider falling hash rate due to a perpetual 51% attack. Difficulty
> falls, possibly to min difficulty if all non-censors stop mining and with
> all censors collaborating (one miner). Yet as difficulty falls, so does the
> cost of countering the censor. At min difficulty everyone can CPU mine
> again.
>
> Given the presumption that fees rise on unconfirmed transactions, there is
> inherent economic incentive to countering at any level of difficulty.
> Consequently the censor is compelled to subsidize the loss resulting from
> forgoing higher fee transactions that are incentivizing its competition.
>
> With falling difficulty this incentive is compounded.
>
> Comparisons of security in different scenarios presume a consistent level
> of demand. If that demand is insufficient to offset the censor’s subsidy,
> there is no security in any scenario.
>
> Given that the block subsidy (inflation) is paid equally to censoring and
> non-censoring miners, it offers no security against censorship whatsoever.
> Trading fee-based block reward for inflation-based is simply trading
> censorship resistance for the presumption of double-spend security. But of
> course, a censor can double spend profitably in any scenario where the
> double spend value (to the censor) exceeds that of blocks orphaned (as the
> censor earns 100% of all block rewards).
>
> Banks and state monies offer reasonable double spend security. Not sure
> that’s a trade worth making.
>
> It’s not clear to me that Satoshi understood this relation. I’ve seen no
> indication of it. However the decision to phase out subsidy, once a
> sufficient number of units (to assure divisibility) had been issued, is
> what transitions Bitcoin from a censorable to a censorship resistant money.
> If one does not believe there is sufficient demand for such a money, there
> is no way to reconcile that belief with a model of censorship resistance.
>
> > We should not imbue real technology with magical qualities.
>
> Precisely. It is economic forces (people), not technology, that provide
> security.
>
> e
>
> >> Bitcoin does not need active economic governanance by devs or meddlers.
> >
> > Yes, active governance would definitely be an exploitable mechanism. On
> the
> > other hand, the status quo of the block reward eventually going away
> entirely
> > is obviously a risky state change too.
> >
> >>>> There is also zero agreement on how much security would constitute
> such
> >>> an optimum.
> >>>
> >>> This is really step 1. We need to generate consensus on this long
> before
> >>> the block subsidy becomes too small. Probably in the next 10-15 years.
> I
> >>> wrote a paper
> >
> > The fact of the matter is that the present amount of security is about
> 1.7% of
> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7%
> is also
> > already an amount low enough that it's much smaller than economic
> volatility.
> >
> > Obviously 0% is too small.
> >
> > There's zero reason to stress about finding an "optimal" amount. An
> amount low
> > enough to be easily affordable, but non-zero, is fine. 1% would be fine;
> 0.5%
> > would probably be fine; 0.1% would probably be fine.
> >
> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31%
> tax on
> > savings; 0.1% works out to be 7.2%
> >
> > These are all amounts that are likely to be dwarfed by economic shifts.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > _______________________________________________
> > 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/20220708/aa305616/attachment-0001.html>

2023-06-08 01:10:02 CEST

- reply

📅 Original date posted:2022-06-04
📝 Original message: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.
>
>
> ------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220604/997f931f/attachment.html>