ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
vasild has quit [Quit: leaving]
bitdex has quit [Quit: = ""]
Hercules1 has joined #bitcoin-core-dev
Hercules1 has quit [Quit: Leaving]
jtraub91 has joined #bitcoin-core-dev
x22x22x has quit [Ping timeout: 252 seconds]
<sdaftuar>
jamesob: i don't know exactly what use case you're thinking of but I would imagine that rule #4 pinning could also come up in that situation
<sdaftuar>
i'm imagining that someone creates a large, very low-fee transaction in the mempool (txA), with a small low-feerate child txB. you create your transaction C and broadcast it, and an adversary could then construct txD that conflicts with B and C, which has txA as a parent.
<sdaftuar>
txD might be very high individual feerate, but relatively low mining score -- and if you try to rebroadcast your own feebump of C which will conflict with txD, you'll have to pay the very high feerate
freesprung has quit [Ping timeout: 256 seconds]
<darosior>
(for rule2 it's not really pinning per se, i don't know how we could name it)
<sdaftuar>
i guess conceptually what i described is no different from rule #3 pinning, in terms of economic effect
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
<instagibbs>
darosior, the use case in mind I don't think requires new unconfirmed outputs, which is why I think its on the order of rule 3 pinning
<darosior>
instagibbs: but if you sign with SINGLE|ACP a third party can always add some whether you need them or not
<instagibbs>
*they* can pin themself via rule 2... sure
<instagibbs>
honest party just won't source unconfirmed inputs, in this scenario at least
<instagibbs>
(does not generalize I know)
<darosior>
instagibbs: i don't understand. If you make a transaction with a >1sat/vb feerate that you sign with SINGLE|ACP i can attach an unconfirmed input to your transaction thereby decreasing its ancestor feerate. You don't pin yourself, i pin you.
<instagibbs>
that's on the same order as rule 3 pin, no?
<instagibbs>
nothing to do with rule 2
<instagibbs>
s/rule 3/economic pin/ maybe
<instagibbs>
I don't think we're disagreeing :)
freesprung has joined #bitcoin-core-dev
<glozow>
generally the problem with anyonecanpay = anyonecanrbf, adding low feerate ancestor. it’s the same economical pin ie you can add 100ksat to the replacement cost. but the difference is the attack scales; you can use the same ancestor for many of these attacks
<sdaftuar>
depending on how large the victim's transaction is compared to what an attacker would need to do, the feerate attack could be made worse than the total-fee attack, but i'm not sure how much it matters.
<sdaftuar>
ie if the victim is broadcasting a 3-input, 3-output transaction (each one SINGLE |ACP), that can be split up into three separate attack packages, which might be worse news for the victim
<sdaftuar>
glozow:good point on the scaling effect!
<instagibbs>
oh, these are bizarre uses lol
<instagibbs>
yeah very interesting point glozow
<instagibbs>
sdaftuar, in general I'm assuming people aren't doing batching, or if they are, they don't care about confirmation speed....
<jamesob>
sdaftuar: yes, the case you highlight (where you have n input-output pairs each signed SINGLE|ACP) I think can be unbundled and griefed individually, and because of the no-new-unconfirmed-inputs RBF rule, have to be bumped individually by the victim, wasting a lot of fees
<jamesob>
but I think fundamentally, all of this boils down to rule #3-style griefing, _not_ strict pinning
<sdaftuar>
jamesob: the no-new-unconfirmed-inputs rule is not very effective, because if you want to introduce a new unconfirmed input for a replacement transaction, you can work around it by just conflicting with a transaction that has the ancestor you want to include
<sdaftuar>
for instance the example i wrote above shows how to do that (txD replaces txB and txC, and from C's perspective is introducing a "new" unconfirmed input)
<instagibbs>
I mean, it also is worked around by being "first"
<sdaftuar>
instagibbs: even if there is no SINGLE|ACP batching going on, I assume a transaction that has a SINGLE|ACP input probably also has other inputs and outputs as well, for instance you'd need to if you were going to feebump?
<instagibbs>
given today's policy(no package CPFP_, likely
<jamesob>
instagibbs: right, but you can't ever really rely on being "first" given mempool mapping/frontrunning
<instagibbs>
it's a incentive compat vs pinning tension I guess
<sdaftuar>
i think as soon as the victim's transaction is bigger than a 2-in, 2-out transaction, then the most effective pin becomes based on feerate rather than fee, i think
<instagibbs>
it's essentially a pinning multiplier on top of rule3 pin, if you're batching these state updates
<instagibbs>
state update == the inputs and updates that cannot be separated due to sighash coverage... need a better term for this
<instagibbs>
ok sdaftuar's point is that if your adversary can BYOF more compactly than you, it increases the pin
<instagibbs>
corollary is that if your attacker doesn't have chunky utxos they can't pin as much
<sdaftuar>
instagibbs: ah but in this particular case, the attacker can construct a "chunky" utxo with the large unconfirmed ancestor
<sdaftuar>
at least potnetially
<instagibbs>
that's fine, I'm assuming we're maxing out package size here
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
<jamesob>
So is the idea of "large ancestor being reused to grief multiple RBFable ACP pairs" just that any RBFable ACP pair can be reformulated and bumped with the large ancestor add as an input by the attacker at will, or is it something more nuanced?
<jamesob>
(where reformulated = packed into a new transaction by griefer)
<glozow>
jamesob: yep. acp + rbf = anyone can bump you down
<instagibbs>
so I think the key is this additional pinning multiplier only exists with ancestral junk (just clear to me now)
<sdaftuar>
jamesob: it may be also worth noting that an adversary can also keep your transaction out of the mempool. costliness is determined by the incentive compatibility problems we have with our current RBF scheme
<sdaftuar>
naively: you send a transaction, i conflict it, and then i conflict that version in a way that drops your input.
<sdaftuar>
if you are paying attention you can rebroadcast, but i think it might not relay due to bandwidth optimizations
<sdaftuar>
(for a while)
<sdaftuar>
or you can broadcast an alternate version of your transaction, and the adversary can play the same game
<sdaftuar>
morally speaking it should be expensive for the attacker to do this, but it may not be:
<sdaftuar>
the attacker can take advantage of the bug where we only compare feerates of replacement transactinos with their direct conflicts, to send replacement transactions that have a lower feerate than the transaction containing the victim's input.
<sdaftuar>
(would take some more thought for me to articulate what the cost might end up looking like, but being forced to be vigilant for what is being relayed and in mempools is already sort of bad)
test__ is now known as _flood
hg has joined #bitcoin-core-dev
<jamesob>
sdaftuar: oh interesting... what are the "bandwidth optimizations" you're talking about there? that sounds like a more severe attack than just fee griefing
<dhruv>
I did push it back up with the same branch name
andrewtoth_ has quit [Remote host closed the connection]
<dhruv>
Is that what you mean by restore?
andrewtoth_ has joined #bitcoin-core-dev
<fanquake>
Ok. I still can't reopen, so you might just have to open a new PR. I think if you've pushed it back up, it has to be the exact same content as prior to close, to be able to re-open.
<_aj_>
yeah, force push back to 8f7714e33804b6cf96fedbe05751d1a700e1e8d1, reopen, then force push again
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
jtraub91_ has joined #bitcoin-core-dev
<sdaftuar>
jamesob: we use a rolling bloom filter to prevent re-relaying a transaction to a peer that we think we've already sent it, or that it's already sent us
<sdaftuar>
jamesob: we clear that filter out every time a new block is found, so that's a lower bound on when you could try to re-relay the same transaction and have it propagate
<sdaftuar>
er upper bound
jtraub91 has quit [Ping timeout: 272 seconds]
jtraub91_ has quit [Ping timeout: 246 seconds]
b_101 has joined #bitcoin-core-dev
b_101_ has joined #bitcoin-core-dev
_andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
b_101 has quit [Ping timeout: 252 seconds]
<ariard>
rebroadcast logic for Lightning time-sensitive transactions are scheduled on block for now, and rebroadcast implies a fee-bumping (either RBF is the transaction is single-party malleable or CPFP is dual-signed)
<ariard>
so the rolling bloom filter is less an issue than the RBF penalty than you might account for every RBF attempt (that we've hardcoded somewhere in the LDK backend)
sudoforge has quit [Quit: 404]
sudoforge has joined #bitcoin-core-dev
<sdaftuar>
ariard: do the transactions that you're referring to use ACP? if so, then it seems trivial to attack by just knocking it out of the mempool
b_101 has joined #bitcoin-core-dev
b_101_ has quit [Ping timeout: 268 seconds]
Talkless has quit [Quit: Konversation terminated!]
<vasild>
I have no idea what is the status of that, but I am here to answer questions, if any (a bit sleepy, though :)
<achow101>
I think bytes1440000 was wondering what the status of that was
<b10c>
hi
<achow101>
I think the current status is that a few contributors are -0 or -1
<achow101>
and the next steps would be to follow up with those contributors to see if any of the discussion has changed their opinion
<aureleoules>
hi
<achow101>
anything else to discuss?
<aureleoules>
yes
<aureleoules>
I've been experimenting with brunoerg on mutation testing and I would love your feedback
<vasild>
achow101: who are those contributors? there are no NACKs on github, the sole -1 is "-1 on maintaining net processing" from dergoegge but "net processing" was omitted from the scope...
<vasild>
no -0 either
<achow101>
vasild: dergoegge fanquake and jeremyrubin I think
<achow101>
unless I missed a followup comment, but no acks from them either
<_aj_>
are there any PRs that are stalling due to lack of people merging, rather than lack of review or waiting-for-author/rebase?
<_aj_>
(if so, maybe move them to the Ready for merge column in the "PR Statuses" project linked above?)
<achow101>
_aj_: I don't think so. I've been looking at the ack counts of all of the open prs, and the highest is 2, so not particularly certain that those are ready for merging
<achow101>
although some may have had acks until they got conflicted and needed rebasing
<jeremyrubin>
i withdraw all my historical acks or nacks on core prs; don't think that they particularly matter and the maintainers should just do what they see fit to advance the project
Talkless has quit [Quit: Konversation terminated!]
Talkless has joined #bitcoin-core-dev
Talkless has quit [Client Quit]
<achow101>
doesn't seem like there's much else to say on this topic
<aureleoules>
_aj_: haha yes I haven't done the pagination yet, netlify doesnt like it
<aureleoules>
lightlike: I first run the unit tests because they are faster and then the functional tests, if none crash it means the mutation has survived and a test should be added
<_aj_>
aureleoules: what does "Fixed" mean?
<brunoerg>
reminding that it's not a generalist C++ tool, but focused on Bitcoin Core, because we have e.g. CAmount a = 1; and most tools can't deal with it
<aureleoules>
_aj_: it means a test was added or ignored (for now) because it is unreachable code or not important to fix
<achow101>
it's definitely useful to have mutation testing. I think gmax was doing mutation testing for Taproot and found a couple of bugs that way. would be nice to have that over more prs
<aureleoules>
the next step for me and bruno is to mutate the diff of pull requests to add as much test coverage and thus maybe find bugs
<vasild>
Is that like replacing std::sort in the source code with std::stable_sort and checking if more code will be covered, compared to std::sort?
<aureleoules>
i'm not sure what you mean by "if more code will be covered"
<aureleoules>
but it tests that the CI should crash with std::stable_sort
<aureleoules>
this may not be a very useful mutator after all
<aureleoules>
std::min -> std::max is more likely to crash
<brunoerg>
if it doesn't crash with stable_sort, it means we should use it instead? is this the purpose?
<vasild>
I mean different code path to be executed
<_aj_>
mutation testing is about introducing bugs into the code (by changing if (x == y) to if (x != y) and similar), and seeing if the existing tests catch the bug and report an error, or if all the tests pass
<vasild>
ah, I see now, thanks _aj_!
<aureleoules>
if it doesn't crash with stable_sort it means that there should be a test somewhere that checks how a vector was sorted (but I believe this is usually not tested)
<_aj_>
int subtract(int a, int b) { return a + b; } // you can have a fuzz tester that has 100% coverage of that code, despite the obvious bug. mutation testing will tell you the tests don't care that you're return "a + b" or "a - b", which will definitely help improve the tests, and may make the bug obvious
<brunoerg>
_aj_: perfect
<MacroFake>
Does it parse the AST or will it also modify string literal contents?
<aureleoules>
I doesn't parse the AST, it parses the source code with simple regexes (for now)
Talkless has quit [Remote host closed the connection]
<aureleoules>
And I added a check to not mutate string litterals
<aureleoules>
the bottle neck is not the compile time it's the CI, so I don't think mutating the AST is the priority
Talkless has joined #bitcoin-core-dev
<aureleoules>
it* doesnt
<MacroFake>
Does it use ccache?
<aureleoules>
yes
<aureleoules>
I can add as many workers to execute the mutations with a simple docker run
<aureleoules>
It contains a pre-compiled bitcoin-core with ccache (thus the image is heavy) but the first compilation is fast
<vasild>
bticoin
<aureleoules>
vasild: yes the repo name has been mutated as well :)
<vasild>
:-D
<brunoerg>
lol
<vasild>
this sounds super cool!
<aureleoules>
thanks!
<aureleoules>
if you have an idea on how to make it better, issues are very welcome!
<achow101>
awesome
<achow101>
any other topics to discuss?
<vasild>
what about deleting random lines of code and seeing what happens?
<aureleoules>
vasild: I have thought of that but that will produce huge amounts of data
<aureleoules>
considering every file is 4000 lines
<instagibbs>
aureleoules, could "score" subroutines based on importance
<vasild>
yeah, and 99% compilation failures, I guess
<brunoerg>
i'm working on a CLI for asmap stuff, it downloads dumps, convert dump files to human-readable ones, compare two files, and other stuff. if anyone has any idea to improve it or features it could have, that's the repo: https://github.com/brunoerg/asmapy
_Sam-- has quit [Remote host closed the connection]
<instagibbs>
i did some manual mutation testing for taproot as well, but i focused on things like sighashes and related, not the entire PR
<aureleoules>
i could add a check to not mutate brackets
<instagibbs>
(found a bug as well)
<aureleoules>
but compile time failures are great because they happen quickly
<vasild>
maybe just for the lines that are added or modified in open PRs, not for the entire code base
<aureleoules>
instagibbs: what do you mean by "could "score" subroutines based on importance"
<aureleoules>
vasild: yes this is planned
<instagibbs>
files are big, but some functions are very small and very important
<instagibbs>
triaging mutation testing coverage by consensus criticality
<brunoerg>
we could point what interval of lines we wanna mutate
Talkless has quit [Quit: Konversation terminated!]
<bitcoin-git>
[bitcoin] hebasto opened pull request #26707: clang-tidy: Fix `performance-move-const-arg` in headers (master...221215-tidy-move) https://github.com/bitcoin/bitcoin/pull/26707
kmartin has quit [Ping timeout: 260 seconds]
<bitcoin-git>
[bitcoin] hebasto opened pull request #26708: clang-tidy: Fix `modernize-use-nullptr` in headers (master...221215-tidy-null) https://github.com/bitcoin/bitcoin/pull/26708
<ariard>
sdaftuar: re-ACP on LN time-sensitive txn, post-anchor yes we have a subset signed under single|acp; however the spent utxo can only be spent by one party until timelock expiration
<ariard>
if you're consuming fee-bumping inputs from a third-party ancestor, you might have pinnings issues
<bitcoin-git>
[gui] hebasto opened pull request #685: clang-tidy: Fix `readability-redundant-string-init` in headers (master...221215-tidy-string) https://github.com/bitcoin-core/gui/pull/685
<sdaftuar>
i don't quite follow everything you said, but i assume its a problem if the time-sensitive transaction doesn't confirm? if so i think any random 3rd party would be able to do that just by knocking it out of the mempool whenever it shows up on the network
brunoerg has quit []
hg has quit [Quit: WeeChat 3.7.1]
<instagibbs>
two sets of signatures in that case i think
<instagibbs>
presigned signatures SINGLE|ACP, then another ALL when attaching fees that only the owner can use
sipsorcery has quit [Read error: Connection reset by peer]
ghost43 has quit [Ping timeout: 255 seconds]
sipsorcery has joined #bitcoin-core-dev
sipsorcery_ has joined #bitcoin-core-dev
sipsorcery_ has quit [Client Quit]
<sdaftuar>
got it -- so i think that's easily attackable, right? knock the transaction out once a higher feerate transaction that includes the same SINGLE|ACP input, and knock that input out altogether with another replacement that conflicts a different input
<sdaftuar>
once with* a higher feerate
<ariard>
ah i think i see what you're describing -- you would have a single|acp HTLC-timeout, this "honest" transaction is 1) replaced by a higher feerate HTLC-timeout' spending a replaceable parent and then 2) the parent is knocked out?
<ariard>
though in this case, the script path is only spendable by Alice until the HTLC absolute timelock expires, at expiration effectively Bob could win the race in this unfair fashion
<ariard>
yes this is a fund loss problem if a LN time-sensitive transaction doesn't confirm...especially if it can be triggered at low-cost by exploiting mempools rules
ghost43 has joined #bitcoin-core-dev
<sdaftuar>
ariard: that's one way to do it, but you don't even need to involve any transaction chains for the simple attack i'm describing. if txA is the honest transaction that has a SINGLE|ACP input, then construct txB that conflicts with A by including that SINGLE|ACP input as well as one other input, and then contruct txC that conflicts with the second input of txB which drops the SINGLE|ACP
<sdaftuar>
input.
<sdaftuar>
if you wanted to take this a step further and save money as an attacker, then yes you could use transaction chains to be able to do these RBFs more cheaply as well, i think
<sdaftuar>
but i'm assuming that even if an attacker is willing to pay the prevailing feerate once per block, that this would be a situation you would want to avoid
andrewtoth_ has joined #bitcoin-core-dev
_andrewtoth_ has quit [Remote host closed the connection]