kuler has quit [Remote host closed the connection]
jungly_ has quit [Ping timeout: 245 seconds]
<jonatack>
congrats!
vysn has quit [Ping timeout: 245 seconds]
belcher_ is now known as belcher
bitdex has quit [Quit: = ""]
kuler has joined #bitcoin-core-dev
kuler has left #bitcoin-core-dev [Leaving]
sipsorcery has joined #bitcoin-core-dev
b10c has joined #bitcoin-core-dev
dermoth has quit [Quit: Leaving]
maria_elis has quit [Quit: WeeChat 2.8]
<prayank>
I was reading the comments in this issue and wanted to know if someone has written any blog post or detailed answer somewhere that explains eviction process followed by Bitcoin Core.
gribble has quit [Remote host closed the connection]
<prayank>
Another question: vasild mentioned in this comment that onlynet=ipv4 with Tor proxy is contradictory. Is it possible that someone wants to have only ipv4 nodes for outgoing but use Tor proxy for making these connections?
<laanwj>
right: using a proxy is independent from which network classes you want to connect to
<laanwj>
this is why the network is called *onion*, it's only about .onions, it's perfectly valid to want to use tor to connect to ipv4 only
<laanwj>
people keep confusing this, in other places as well
<prayank>
laanwj: Thanks. That clears my doubt I had in second question.
gribble has joined #bitcoin-core-dev
goatpig has quit [Quit: Konversation terminated!]
<vasild>
prayank: laanwj: ok, specifying onlynet=ipv4 with "a proxy to connect to *.onion addresses" is contradictory (because *.onion addresses are not ipv4 so we would not be connecting to them). But specifying an outgoing socks5 proxy for reaching ipv4 address is not contradictory, it may as well be some normal (non-tor) socks5 proxy required to be used in some certain network environments.
pinheadmz has joined #bitcoin-core-dev
<vasild>
so "onlynet=ipv4 onion=..." is contradictory, but "onlynet=ipv4 proxy=..." is not. So far, so good. Now... onion= defaults to proxy= :-X
<sipa>
vasild: not *exactly*; with onlynet=ipv4 you can still specify .onions in -connect or addnode i believe
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<prayank>
I think we should remove "only" from `onlynet` to reduce confusion around these options. Maybe `net_out` if underscores are okay.
gene has quit [Quit: drained and gutted]
luke-jr has quit [Ping timeout: 258 seconds]
emzy has joined #bitcoin-core-dev
<laanwj>
yes, the option name is confusing; as for underscores, iirc there are no option names with any kind of separator right now, probably better to keep it that way (underscores work really badly with - options)
<jonatack>
I'm not sure how config options can be changed without breaking user space. Even if only to rename them. Is it really worth it, etc.
<laanwj>
yeah...
luke-jr has joined #bitcoin-core-dev
<jonatack>
Right, I recall we had an irc discussion about config options naming some time ago, and the consensus was to continue with no separators
<prayank>
jonatack: I have seen few other users confused about this option. So I am assuming the option is already not used correctly by many. So it's already broken.
<jonatack>
prayank: the issue is about breaking user space for those who do use them, not for those who don't
vysn has joined #bitcoin-core-dev
<prayank>
If 100 people are using this option. I am assuming 30 are not using it correctly or unaware of issues.
<jonatack>
in any case, i proposed some doc changes in #22648 to clarify the use of -onlynet
<laanwj>
bitcoin-cli prints "timeout on transient error: ..." when the RPC port is not open, this is slightly confusing (though it does appropriately print a message about bitcoind not running afterwards)
lukedashjr has joined #bitcoin-core-dev
lukedashjr has quit [Read error: Connection reset by peer]
lukedashjr has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 245 seconds]
luke-jr has joined #bitcoin-core-dev
lukedashjr has quit [Ping timeout: 240 seconds]
emcy has quit [Quit: Leaving]
bomb-on has joined #bitcoin-core-dev
emcy has joined #bitcoin-core-dev
aechu has quit [Remote host closed the connection]
meshcollider has quit [Remote host closed the connection]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jonatack has quit [Quit: Client closed]
lightlike has joined #bitcoin-core-dev
babasancheti has quit [Quit: Client closed]
sipsorcery has quit [Ping timeout: 245 seconds]
jonatack has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto closed pull request #19882: depends: Export variables from make to environment explicitly (master...200905-build) https://github.com/bitcoin/bitcoin/pull/19882
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
grettke has joined #bitcoin-core-dev
<BlueMatt>
the standardization of any segwit output script is less useful for lightning and upgradability of similar systems than it looks because we don't know today what the dust limit will be on these outputs in the future
<BlueMatt>
would it be reasonable to commit(-ish) to a fixed dust limit based on today's calculation for future segwit output types (and, relatedly, it apepars the dust limits were not changed for taproot, is that on purpose or should we consider it a feature not a bug :)
<BlueMatt>
cc sipa
jonatack has quit [Quit: Client closed]
bomb-on has quit [Quit: aллилѹіа!]
gene has joined #bitcoin-core-dev
Guest6 has joined #bitcoin-core-dev
Guest6 has quit [Client Quit]
<michaelfolkson>
BlueMatt: I'm not sure what a commit(-ish)ment looks like or who could provide it. I'd guess (like a number of things in this space) that it would only change if it became absurd and hence was easier to get consensus on changing it
<sipa>
BlueMatt: i think it's an oversight, i hadn't really thought about this
<BlueMatt>
sipa: I mean obviously I'd kinda prefer we not change it, or change it ever again for segwit outputs, at least from a lightning perspective, but its an interesting question.
<BlueMatt>
sipa: I wonder if maybe it makes sense to bump it in a one-time change and then leave it?
<BlueMatt>
like, set it to something calculated on 5 sat/vbyte or 10 sat/vbyte instead of 3, so that it doesn't float down to 1 if future versions require larger witnesses?
<sipa>
BlueMatt: i mean, it's per node configurable even - i'm not sure the current approach maps well to a well-defined promise
<sipa>
as a config settin
<BlueMatt>
I mean in practice no one overrides that, and also in practice whether we like it or not its an important security metric for lightning nodes.
<BlueMatt>
whether we like it or not, lightning is very sensitive to transaction propagation.
<sipa>
i'm very uncomfortable with anything relying on it being predictable tbh
<BlueMatt>
then suggest an entirely different L2 system :p
<BlueMatt>
and novel one
<BlueMatt>
the standardness rules are now a security assumption for large amounts of money, even though they were never really intended to be that explicit.
<sipa>
that's beyond scary to me
<BlueMatt>
well I dont think think "sorry, you shouldn't use lightning, we cant do anything for it" is an acceptable answer
<sipa>
can't you just have it loudly complain to users when something doesn't seem to confirm, yelling that they should be broadcasting it through smoke signals or so
<sipa>
sorry, very tired, i'm not very useful to discuss things right now
<BlueMatt>
most users dont monitor their node actively
<BlueMatt>
and even if they did, what do you tell them? call your local mining pool? I mean I dunno if any would respond lol
<sipa>
i don't have an answer
<BlueMatt>
well then back to the specific initial question - should we bump/drop the dust threshold for taproot outputs
<BlueMatt>
and if so, can we just bump it once and set it for segwit outputs with a "we hope to keep this in the future metric
<sipa>
i'm ok with that
<BlueMatt>
for future segwit versions, that is
<sipa>
key path spending for p2tr outputs is probably a very reasonable lower bound of spending weight
<BlueMatt>
right, so probably use that weight and a slightly higher dust fee rate and move on?
<BlueMatt>
cause 3 is quite low, though changing for existing segwit stuff is probably unreasonably high change for the ecosystem
<sipa>
just reducing the spending weight calculation for p2tr and other witness versions seems like something that could reasonably be called a bugfix
<sipa>
anything beyond, including some plan on a fixed policy (yuck, hardcoded feerates :s). sounds like it'd need a wider discussion
<BlueMatt>
sure, but I dunno if "reduce dust threshold" is a good thing a-priori. eg 3 sat/vbyte is a quite-low feerate in a modern context, so a-priori it may make sense to increase not decrease. more to the point - if we're talking about dust thresholds for *future* segwit versions, I don't know that we want to go for a lower-bound, more like "reasonable upper-bound"
<harding>
LN doesn't need to use the same dust limit Bitcoin Core does. Y'all can choose to treat as dust outputs that would cost more to spend than they're worth at 20 s/b, and so be insulated against any reasonable change in Bitcoin Core (especially since changes in Bitcoin Core should take a long time to become predominant across relay and mining).
sipsorcery has quit [Ping timeout: 240 seconds]
<BlueMatt>
true, but you *really* dont want a low dust threshold in lightning, there's already more than enough issues with funds loss due to burning-to-dust
<BlueMatt>
errr, high dust threshold
<harding>
Sure, but if feerates increase significantly (and that certainly seems like a plausible scenario), those problems are going to need to be dealt with anyway. I don't think we should be forcing anyone to deal with those problems now, but I also kinda feel like some of the attention on the dust limit problem should be focused on improving LN rather than changing Bitcoin Core.
<BlueMatt>
well its somewhat of a tradeoff in LN - you can just include dust outputs with no desire to ever claim them, or at least only maybe claim them, which is probably better for ln than skipping those outputs
<BlueMatt>
but of course that's massively anti-social cause you just create outputs on chain you'll never claim
<BlueMatt>
which is kinda the reason for the dust limit in core to begin with - to prevent stupid anti-social behavior like that.
<BlueMatt>
so if lightning "has to deal with it" you get anti-social outcomes, probably.
<harding>
I meant "deal with it" in the sense of implementing probabalistic payments or bundling tiny payments into a pre-funded output that gets donated to charity or some other solution.
<BlueMatt>
right, could bundle "below dust" outputs to charity instead of sending to miners.
<BlueMatt>
or just burn them with OP_RETURN
<BlueMatt>
"charity" of reducing total bitcoin supply :)
AaronvanW has joined #bitcoin-core-dev
<BlueMatt>
of course even that doesn't "solve" the issue without some kind of commonly agreed upon lower-bound
<harding>
Yeah. We could also have a very low dust limit for pay to OP_TRUE, since miners will be able to remove those from the UTXO set during future periods of low prevailing feerates.
<BlueMatt>
cause lightning nodes have to enforce the rules on *each other*
bomb-on has joined #bitcoin-core-dev
<BlueMatt>
no, OP_TRUE does not solve the issue
<BlueMatt>
right now lightning with a counterparty who is, or is collaborating with a miner, is really really not ok
<harding>
I don't think it's any worse than paying to fees?
<BlueMatt>
right, its the *same* as paying to fees, but the problem right now is precisely that paying to fees is not ok :p
<harding>
It might be better in the sense that, for very low values, it's not economical for the current miner to claim it, so it's pay to future miner.
<BlueMatt>
sure, its more social, but it doesn't solve the issue lightning has today
gene_ has joined #bitcoin-core-dev
<harding>
Sure, but if that's the problem, someone should be working on probabalistic payments. That certainly wants new opcodes, which is why it's probably better someone start working on it sooner.
gene_ has quit [Client Quit]
gene_ has joined #bitcoin-core-dev
jessebarton has quit [Ping timeout: 248 seconds]
<BlueMatt>
there are other shorter-term changes we can make to address the issues without prob payments, but everything around the dust limit sucks, precisely cause we can't get some reasonable lower-bound that ensures broadcastability
gene has quit [Remote host closed the connection]
<harding>
I mean, you do have a reasonable lower bound---the current bound, which should take at least months to change in all non-emergency scenarios (and which seems unlikely to ever require an emergency change).
<BlueMatt>
sadly we need one for non-v0 segwit outputs as well
<BlueMatt>
which was my original question here - what is a reasonable lowerbound for non-v0 segwit outputs
jonatack has joined #bitcoin-core-dev
<harding>
And it should be easy for any future changes to just gate that with a time delay, e.g. if (time > x) { new_dust_limit } else { old_dust_limit }
<BlueMatt>
sure, but that kind of thing requires at least a loose commitment from bitcoin core to do dust limit changes in a way that is compatible with that :p
<BlueMatt>
which, when the response to questions like this is "lol lightning shouldnt rely on dust limit being X", then I dont feel like we have that
<harding>
Sure, but I think Bitcoin Core's open development process has a pretty strong commitment to listening to LN devs and other ecosystem devs, so I think that's implicitly covered
<harding>
Sorry.
<BlueMatt>
that's what I'd generally expect, but i dunno many/any lightning devs who follow bitcoin core closely enough to ensure that, which is part of the reason for me flagging now that non-v0 segwit output dust limit *also* falls under the "plz notify lightning devs and give us time to adapt before you change this" category
<BlueMatt>
because it isn't trivially obvious for core devs that it would fall into that category, I'd think
<harding>
That's one of the reasons we publish "notable merged PRs" in the Optech newsletter each week. We've covered every standardness change in the past three years, so any LN devs who read the newsletter should be made aware of any changes well before they get released, and can then go and ask for reverts or alterations.
<harding>
I know someone reading about the merge of disabling BIP37 by default ended up in the discussion that got it continued for an extra release, so that kind of communication works at least some times.