<unnamed>

Public Key

npub1ss2s89s938xfh3zzz0j2mhp25tlrlcrj0duljr0ne0t8v2r4cv0q5e0am4

Profile Code

nprofile1qqsgg9grjczcnnymc3pp8e9dms429l3lupe8k70epheuh4nk9p6ux8spzpmhxue69uhkummnw3ezuamfdejsdkfwqj

Publishing to

nostr.wine

Last Notes

2023-06-08 01:15:53 CEST

- reply

📅 Original date posted:2022-10-27
📝 Original message:I have more to say on this broader topic, but since you've brought up this
particular example I think it's worth commenting:
On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
> a DoS issue when utxos are jointly funded by untrusting partners, and,
> aiui, that's the main motivation for addressing this now.
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
> The scenario he describes is: A, B, C create a tx:
>
> inputs: A1, B1, C1 [opts in to RBF]
> fees: normal
> outputs:
> [lightning channel, DLC, etc, who knows]
>
> they all analyse the tx, and agree it looks great; however just before
> publishing it, A spams the network with an alternative tx, double
> spending her input:
>
> inputs: A1 [does not opt in to RBF]
> fees: low
> outputs: A
>
> If A gets the timing right, that's bad for B and C because they've
> populated their mempool with the 1st transaction, while everyone else
> sees the 2nd one instead; and neither tx will replace the other. B and
> C can't know that they should just cancel their transaction, eg:
>
> inputs: B1, C1 [opts in to RBF]
> fees: 50% above normal
> outputs:
> [smaller channel, refund, whatever]
>
> and might instead waste time trying to fee bump the tx to get it mined,
> or similar.
>
> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> solve that problem if they have only opt-in RBF available?
>
I think this is not a real example of a DoS vector that is available
because we support non-rbf signaling transactions. Even in a world where
all transactions are replaceable, person A could double-spend their input
in a way that is annoying for B and C. For instance, the double-spend
could be low-feerate and large, and effectively pin any attempt to replace
it. Or it could be higher feerate and confirm and B/C have to start all
over. Or, A could stall things in the signing phase and B/C have to figure
out when to give up on the channel with A.
So I find this example to be unconvincing. Are there any other examples
where having a non-replacement policy for some transactions causes problems
for protocols people are trying to build?
Thanks,
Suhas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/511dc909/attachment-0001.html>

2023-06-07 20:26:23 CEST

- reply

📅 Original date posted:2020-08-17
📝 Original message:Hi Eric,
Thanks for your response. If I understand correctly, you're suggesting
that in the future we do the same as what was done in BIP 339, of
accompanying new messages (which are optional) with a protocol version
bump, so that network clients are never reading unknown messages from a
peer (and can be free to disconnect a peer for sending an unknown message)?
I think that works fine, so if indeed there will be software that will
expect things to operate this way then I can withdraw the suggestion I've
made in this thread. However I wanted to clarify that this is what you
suggest, because there is another downside to this approach (beyond the
sequential nature of sequence numbers that you mention) -- if a software
implementation misses a proposed new protocol upgrade, and thus fails to
parse (and ignore) some proposed new message, the result can be a network
split down the road as incompatible clients get slowly upgraded over time.
I think this coordination cost is something to be concerned about -- for
instance, the lack of response to my wtxid-relay proposal made me wonder if
other software would be implementing something to account for the new
message that proposal introduces (for clients with version >= 70016). It's
reasonable for people to be busy and miss things like this, and I think
it's worth considering whether there's a safer way for us to deploy changes.
That said, I don't think this coordination cost is unbearable, so as long
as we have a process for making p2p protocol improvements I'm not too
worried about what mechanism we use. So if this concern over coordination
of changes doesn't sway you, I think we can continue to just bump protocol
version at the same time as deploying new messages, as we have been doing,
and hope that we don't run into problems down the road.
If I have misunderstood how you think we should be making future protocol
changes, please let me know.
Thanks,
Suhas
On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil <eric at voskuil.org> wrote:
> A requirement to ignore unknown (invalid) messages is not only a protocol
> breaking change but poor protocol design. The purpose of version
> negotiation is to determine the set of valid messages. Changes to version
> negotiation itself are very problematic.
>
> The only limitation presented by versioning is that the system is
> sequential. As such, clients that do not wish to implement (or operators
> who do not wish to enable) them are faced with a problem when wanting to
> support later features. This is resolvable by making such features optional
> at the new protocol level. This allows each client to limit its
> communication to the negotiated protocol, and allows ignoring of known but
> unsupported/disabled features.
>
> Sorry I missed your earlier post. Been distracted for a while.
>
> e
>
>
> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Hi,
>
> Back in February I posted a proposal for WTXID-based transaction relay[1]
> (now known as BIP 339), which included a proposal for feature negotiation
> to take place prior to the VERACK message being received by each side. In
> my email to this list, I had asked for feedback as to whether that proposal
> was problematic, and didn't receive any responses.
>
> Since then, the implementation of BIP 339 has been merged into Bitcoin
> Core, though it has not yet been released.
>
> In thinking about the mechanism used there, I thought it would be helpful
> to codify in a BIP the idea that Bitcoin network clients should ignore
> unknown messages received before a VERACK. A draft of my proposal is
> available here[2].
>
> I presume that software upgrading past protocol version 70016 was already
> planning to either implement BIP 339, or ignore the wtxidrelay message
> proposed in BIP 339 (if not, then this would create network split concerns
> in the future -- so I hope that someone would speak up if this were a
> problem). When we propose future protocol upgrades that would benefit from
> feature negotiation at the time of connection, I think it would be nice to
> be able to use the same method as proposed in BIP 339, without even needing
> to bump the protocol version. So having an understanding that this is the
> standard of how other network clients operate would be helpful.
>
> If, on the other hand, this is problematic for some reason, I look forward
> to hearing that as well, so that we can be careful about how we deploy
> future p2p changes to avoid disruption.
>
> Thanks,
> Suhas Daftuar
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html
>
> [2]
> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
> _______________________________________________
> 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/20200817/f449fb1f/attachment.html>

2023-06-07 20:00:38 CEST

- reply

📅 Original date posted:2017-05-22
📝 Original message:I also do not support the BIP 148 UASF, and I'd like to add to the points
that Greg has already raised in this thread.
BIP 148 would introduce a new consensus rule that softforks out non-segwit
signalling blocks in some time period. I reject this consensus rule as
both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to
reach consensus on the state of a shared ledger, and even though I think
the Bitcoin network ought to adopt segwit, I don't think that concern
trumps the goal of not splitting the network.
Many BIP 148 advocates seem to start with the assumption that segwit
already has a lot of support, and suggest that BIP 148 does as well.
However I don't think it's fair or correct to separate the activation
proposal for segwit from the rest of the segwit proposal. The deployment
parameters for segwit are consensus-critical; assuming that some other
deployment has consensus because it would result in the rest of the segwit
proposal activating is an unjustified leap.
Even if there were no feasible alternate segwit deployment method available
to us, I would hesitate to recommend that the network adopt a potentially
consensus-splitting approach, even though I firmly believe that the ideas
behind segwit are fundamentally good ones. But fortunately that is not the
situation we are in; we have substantially less disruptive methods
available to us to activate it, even if the current BIP 9 deployment were
to fail -- such as another BIP 9 deployment in the future, or perhaps a BIP
149 deployment.
If we do pursue a "user-activated" deployment of segwit, I'd recommend that
we do so in a more careful way than BIP 148 or 149 currently suggest, which
as I understand would otherwise make very few changes to the current
implementation. However, due to the BIP 9 activation assumption, the
Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
the idea that miners would both enforce the rules and mine segwit blocks.
However, we can separate these concerns, as we started to do in the Bitcoin
Core 0.14.1 release, where mining segwit blocks is not required in order to
generally mine or signal for segwit in the software. And we can go further
still: without too much work, we could make further improvements to
accommodate miners who, for whatever reason, don't want to upgrade their
systems, such as by improving block relay from pre-segwit peers [1], or
optimizing transaction selection for miners who are willing to enforce the
segwit rules but haven't upgraded their systems to mine segwit blocks [2].
If we would seek to activate a soft-fork with less clear miner signaling
(such as BIP 149), then I think such improvements are warranted to minimize
network disruption. In general, we should not seek to censor hashpower on
the network unless we have a very important reason for doing so. While the
issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
proposal on the spectrum of "censorship attack on Bitcoin" to "benign
protocol upgrade", BIP 148 strikes me as closer to the former than the
latter. There is simply no need here to orphan these non-signalling blocks
that could otherwise be used to secure the network.
To go further: I think BIP 148 is ill-conceived even for achieving its own
presumed goals -- the motivation for adding a consensus rule that applies
to the version bits on blocks is surely for the effect such bits have on
older software, such as Bitcoin Core releases 0.13.1 and later. Yet in
trying to bring those implementations along as segwit-enforcing software,
BIP 148 would risk forking from such clients in the short term! If one
really cared about maintaining consensus with older, segwit-enabled
software, it would make far more sense to seek segwit activation in a way
that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
after this one times out). And if one doesn't care about such consensus,
then it'd be far simpler to just set (e.g.) August 1 as the flag day
activation of segwit, and not play these contortionist games with block
version bits, which carry no useful or intrinsic meaning. Either of these
two approaches should have the advantage of reduced fork risk, compared
with BIP 148.
Of course, everyone is free to run the software of their choosing. I write
this to both generally convey my opposition to a careless proposal, which I
believe represents a way of thinking that is detrimental to Bitcoin's long
run success, and specifically explain why I oppose inclusion of this
proposal in the Bitcoin Core implementation [3]. The Bitcoin Core project
hasn't been, and shouldn't be, careless in deploying consensus changes.
Instead, I think the Bitcoin Core project ought to stand up for the best
practices that our community has learned about how to deploy such changes
(specifically for minimizing chain-split risk when deploying a soft fork!),
and I think we should all avoid adoption or encouragement of practices that
would depart from the high standards we are capable of achieving.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
-March/013811.html
[2] https://github.com/bitcoin/bitcoin/pull/9955
[3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
--Suhas Daftuar
On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I do not support the BIP148 UASF for some of the same reasons that I
> do support segwit: Bitcoin is valuable in part because it has high
> security and stability, segwit was carefully designed to support and
> amplify that engineering integrity that people can count on now and
> into the future.
>
> I do not feel the the approach proposed in BIP148 really measures up
> to the standard set by segwit itself, or the existing best practices
> in protocol development in this community.
>
> The primary flaw in BIP148 is that by forcing the activation of the
> existing (non-UASF segwit) nodes it almost guarantees at a minor level
> of disruption.
>
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
>
> Older nodes will not include segwit spends, and so their blocks will
> not be invalid even if they do not have segwit support. They can
> upgrade to it on their own schedule. The only risk non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it, a risk many miners already
> frequently take with spy-mining.
>
> I do not think it is a horrible proposal: it is better engineered than
> many things that many altcoins do, but just not up to our normal
> standards. I respect the motivations of the authors of BIP 148. If
> your goal is the fastest possible segwit activation then it is very
> useful to exploit the >80% of existing nodes that already support the
> original version of segwit.
>
> But the fastest support should not be our goal, as a community-- there
> is always some reckless altcoin or centralized system that can support
> something faster than we can-- trying to match that would only erode
> our distinguishing value in being well engineered and stable.
>
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test. To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
>
> Of course, I do not oppose the general concept of a UASF but
> _generally_ a soft-fork (of any kind) does not need to risk disruption
> of mining, just as segwit's activation does not. UASF are the
> original kind of soft-fork and were the only kind of fork practiced by
> Satoshi. P2SH was activated based on a date, and all prior ones were
> based on times or heights. We introduced miner based activation as
> part of a process of making Bitcoin more stable in the common case
> where the ecosystem is all in harmony. It's kind of weird to see UASF
> portrayed as something new.
>
> It's important the users not be at the mercy of any one part of the
> ecosystem to the extent that we can avoid it-- be it developers,
> exchanges, chat forums, or mining hardware makers. Ultimately the
> rules of Bitcoin work because they're enforced by the users
> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
> something people can count on: the rules aren't easy to just change.
>
> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.
>
> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.
>
> If these discussions come up, they'll come up in the form of reminding
> people that Bitcoin isn't easily changed at a whim, even when the
> whims are obviously good, and how that protects it from being managed
> like all the competing systems of money that the world used to use
> were managed. :)
>
> So have patience, don't take short cuts. Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
> _______________________________________________
> 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/20170522/8cfe10a6/attachment-0001.html>

2023-06-07 19:54:17 CEST

- reply

📅 Original date posted:2016-11-15
📝 Original message:Just want to clarify two points:
This change has not yet appeared in any released software (but I assume it
will be in the next release, 0.14.0).
I agree that the performance optimization is not the point of this change;
I can modify the BIP draft to de-emphasize that further (perhaps remove
mention of it entirely).
On Mon, Nov 14, 2016 at 1:47 PM, Eric Voskuil <eric at voskuil.org> wrote:
> NACK
>
> Horrible precedent (hardcoding rule changes based on the assumption that
> large forks indicate a catastrophic failure), extremely poor process
> (already shipped, now the discussion), and not even a material performance
> optimization (the checks are avoidable once activated until a sufficiently
> deep reorg deactivates them).
>
> e
>
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Recently Bitcoin Core merged a simplification to the consensus rules
> surrounding deployment of BIPs 34, 66, and 65 (https://github.com/bitcoin/
> bitcoin/pull/8391), and though the change is a minor one, I thought it
> was worth documenting the rationale in a BIP for posterity.
>
> Here's the abstract:
>
> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> signaling in block version numbers. Now that the chain has long since
> passed the blocks at which those consensus rules have triggered, we can (as
> a simplification and optimization) replace the trigger mechanism by caching
> the block heights at which those consensus rules became enforced.
>
> The full draft can be found here:
>
> https://github.com/sdaftuar/bips/blob/buried-deployments/
> bip-buried-deployments.mediawiki
>
> _______________________________________________
> 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/20161115/7b2641ce/attachment.html>

2023-06-07 19:54:16 CEST

- reply

📅 Original date posted:2016-11-14
📝 Original message:Hi,
Recently Bitcoin Core merged a simplification to the consensus rules
surrounding deployment of BIPs 34, 66, and 65 (
https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a
minor one, I thought it was worth documenting the rationale in a BIP for
posterity.
Here's the abstract:
Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
signaling in block version numbers. Now that the chain has long since
passed the blocks at which those consensus rules have triggered, we can (as
a simplification and optimization) replace the trigger mechanism by caching
the block heights at which those consensus rules became enforced.
The full draft can be found here:
https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161114/8b1e5b1f/attachment.html>