<achow101>
there seems to be some discussion about i2p issues(? not really following it), are we intending to deal with that for 22.0?
jarthur has quit [Ping timeout: 250 seconds]
_cold is now known as cold
<fanquake>
I'm also not really following it. Will have to look at any PRs / issues today. However I'm also not super concerned if i2p support isn't perfect at release.
<fanquake>
There's been a long time to get any problems solved, and the last thing we want to be doing is making more last minute changes to networking code.
ExEric3 has quit [Ping timeout: 250 seconds]
AaronvanW has joined #bitcoin-core-dev
earnestly has quit [Ping timeout: 240 seconds]
jarthur has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 240 seconds]
bitdex has joined #bitcoin-core-dev
Yihen has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
<kalle>
Is it possible to set up #bitcoin-dev channel somehow? Would like to discuss BIP process and that channel would've probably been ideal, as it's not a core thing and #bitcoin is not focused on development.
bitdex has quit [Ping timeout: 244 seconds]
<sipa>
the channel aparently exists, but is invite only
<sipa>
i don't know how runs it
jarthur has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
<kalle>
Ahh, that's why I couldn't join it
<midnight>
This place has a namespace which project contacts can enforce.. so if you want it, it can be grabbed.
<midnight>
I think the idea was that #bitcoin-dev was killed thanks to rando jgarzik, so I guess they assumed it was toxic-- so they just put +f #bitcoin on it.
<midnight>
(i.e. there's nothing going on in there)
<midnight>
In the prior network I believe -bips- discussion had its own channels.
<midnight>
Obv. whatever you want to happen will just happen. Rub the lamp, genie pops out, presto.
<Yihen>
is there someone focuse on miniscript?
<Yihen>
is it a new script for bitcoin?
<Yihen>
does it need to compile to bitcoin OP_CODE script?
<Yihen>
yeah， I have read it yeasterday. but I don't know how to use it? I see you have developed a compiier for miniscript written by c++. In my opinion, it is compile ploicy to miniscript. @sipa
<Yihen>
can i test it with daemon? if yes, can you give me some guide? thanks a lot.
<Yihen>
daemon ---> bitcoin daemon
<sipa>
there are several implementations in various stages of development, but it's best to treat it as a research project currently
<sipa>
it is not implemented in bitcoin core
ExEric3 has joined #bitcoin-core-dev
vasild has quit [Ping timeout: 244 seconds]
<Yihen>
The script system is the engine of Bitcoin transactions, and I am very interested in miniscript.
jarthur has quit [Quit: jarthur]
cmirror has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
cmirror has joined #bitcoin-core-dev
VzxPLnHqr has quit [Remote host closed the connection]
VzxPLnHqr has joined #bitcoin-core-dev
VzxPLnHqr has quit [Remote host closed the connection]
VzxPLnHqr_ has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 250 seconds]
belcher has quit [Ping timeout: 250 seconds]
vasild has joined #bitcoin-core-dev
belcher has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
vasild has quit [*.net *.split]
bitdex has quit [*.net *.split]
ghost43_ has quit [*.net *.split]
SpellChecker has quit [*.net *.split]
hex17or has quit [*.net *.split]
yanmaani has quit [*.net *.split]
vnogueira has quit [*.net *.split]
aechu has quit [*.net *.split]
vnogueira has joined #bitcoin-core-dev
ghost43 has joined #bitcoin-core-dev
SpellChecker has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
hex17or has joined #bitcoin-core-dev
aechu has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
yanmaani has joined #bitcoin-core-dev
VzxPLnHqr_ has quit [Ping timeout: 252 seconds]
SpellChecker has quit [Quit: bye]
SpellChecker has joined #bitcoin-core-dev
DeanGuss has quit [Ping timeout: 268 seconds]
<kalle>
midnight: I don't think there was a bips channel, and I feel like a non-core-focused dev channel would be nice to have, at least. Whoever the genie is, I propose we try restoring #bitcoin-dev. :)
<fanquake>
my understanding was that 22648 was only mergable if the other PR was also merged
<laanwj>
oh no
<fanquake>
confusing I know, as it should have just been based on top of it if that was the case
wired has joined #bitcoin-core-dev
<fanquake>
Also why I wasn't overly concerned if either didn't make it into rc3, either as part of the current backport PR (which is getting large), or at all.
<laanwj>
don't know if it was a good idea to couple it to that, the rest of the documentation changes looked sane
<wired>
t is safe to say that the "Block Chain" is the "longest Proof-of-Work chain"?
<laanwj>
i won't say anything about onlynet, i really don't know about onlynet
<wired>
or my article just call it "TimeChain"?
<laanwj>
wired: #bitcoin please
<wired>
banned from there for asking this
<wired>
so I asking here
<wired>
you develop the software don't you?
<laanwj>
then definitely don't repeat it here
<fanquake>
wired: well the same will happen here. Your questions are off topic
<wired>
can you talk to me about the "block chain" or "TimeChain"
<wired>
?
<laanwj>
this is the development channel not bitcoin 101 channels
<laanwj>
no
<wired>
ohh yo you developing for who really? for the community or for Blockstream? no offense
<wired>
I asking about "block chain" "timechain" and the "longest Proof-of-Work chain" and this is how you react, interesting
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] klementtan opened pull request #22804: validation: GuessVerificationProgress returns 0 when no blocks downloaded (master...verification_progress_fix) https://github.com/bitcoin/bitcoin/pull/22804
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<wired>
so you're a Bitcoin developer?
wired was banned on #bitcoin-core-dev by laanwj [*!*@gateway/vpn/protonvpn/wired]
wired was kicked from #bitcoin-core-dev by laanwj [wired]
<laanwj>
I think I'm starting to get #22647 and #22651, so it ends up with an onion proxy (despite not being specifiec explicitly) because of -listenonion, then because of that connecting to onions despite -onlynet, which should rule out connecting to networks not specified?
<gribble>
https://github.com/bitcoin/bitcoin/issues/22647 | If both options "onion" and "proxy" are unset, no outbound Onion connections should be made · Issue #22647 · bitcoin/bitcoin · GitHub
<laanwj>
in any case, yes, no need to make any rushed change here for rc3
<fanquake>
laanwj: I'll take a look tomorrow for you
AaronvanW has joined #bitcoin-core-dev
<laanwj>
fanquake: thank you!
aitorjs has joined #bitcoin-core-dev
<laanwj>
I think we should properly think through what we want onlynet to do and implement (and test) that
<fanquake>
I think there is a lot of scope to reduce the options there, and potentially the features we support. It seems to be very getting very convoluted / non-intuitive.
<laanwj>
and what makes sense to users-not do for sake of expediency what is easiest to implement
<laanwj>
right, deprecating some things completely might be an option too
<laanwj>
there's user privacy at stake here it shouldn't be some dangerous maze of options
<fanquake>
I'd be interested to know if / why some users might be using such networking setups. This also seems like something better solved (or at least moving that way) outside bitcoind, vs additional feature creep and back-compat / option complexity.
<fanquake>
Having support for all of this built is ok, as long as we're not just giving foot-guns, or some sort of false sense of security to users who badly configure things.
aitorjs has quit [Ping timeout: 240 seconds]
<hebasto>
all of prs labeled "Needs backport (22.x)" have been processed
klementtan has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jonatack has quit [Ping timeout: 246 seconds]
prayank has joined #bitcoin-core-dev
<laanwj>
hebasto: great1
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<bitcoin-git>
bitcoin/22.x 99cd080 W. J. van der Laan: Merge bitcoin/bitcoin#22667: [22.x] qt: Pre-rc3 translations update
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<jonatack>
fanquake: i hear from many users, can direct them to you if you're interested, let me know how best you'd like them to reach you
JackH has quit [Ping timeout: 248 seconds]
<laanwj>
hebasto: thanks for confirming
<fanquake>
jonatack: why would they need to reach out to me directly? If there are problems, users should either be opening an issue on GH, and commenting on an existing one. Keeping discussing in DMs, or one-on-one interactions is not useful for ascertaining the scope of an issue, or creating any sort of public documentation.
<fanquake>
My understand is that there are only a handful of i2p users in any case. There can’t be too many, as it’s still an experimental, unreleased feature
<laanwj>
jonatack: it would have been nice to have that PR in rc3, but it's too bad it's coupled to the onlynet change, I'm not sure about backporting it partially
<jonatack>
fanquake: i'm doing what i can to help them. that's the only reason for the docs. there are maybe ~30 users who have set up I2P with bitcoin, but i've heard from many of them.
<laanwj>
for now, it makes most sense to check the documentation on master with regard to i2p i guess
<jonatack>
yes, my suggestion at this point was the commit about i2p routers. that's the most frequent question. along with onlynet.
<laanwj>
but there's no harm in cherry-picking that PR either
<jonatack>
(they are separate commits)
<laanwj>
s/PR/commit
<jonatack>
oh ok
<laanwj>
I don't think I agree with the onlynet fix
<fanquake>
jonatack: I still don’t understand how having them reach out to me directly would be any use
<sipa>
fanquake: i suspect jonatack means this as a means to show you people care aboit this
<laanwj>
let's see if manual page generation behaves any more sane now
<jonatack>
fanquake: that was in reply to "I'd be interested to know if / why some users might be using such networking setups" so you can discuss with them, if you like
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<fanquake>
jonatack: sure. If users want to discuss that, I’m happy for them to get in touch with me.
<jonatack>
basically, people are looking for privacy and there's some confusion out there around the benefits and drawbacks of onlynet=onion. i'm seeing people starting with i2p with onlynet=i2p by default too.
<laanwj>
ok in manual pages it now shows v22.0.0rc3 instead of v22.0rc2, hyphens still get nixed
bitdex_ has quit [Quit: = ""]
<prayank>
If we had wiki enabled in this repository, it could be used for privacy related docs. There is scope for lot of improvement but you need lot of patience to get any privacy related PR get merged (sometimes years).
<laanwj>
the main problem (as I see it) is that how these options interact is incredibly complex, as well as under-tested in the functional tests, which makes reviewing changes to them scary
<laanwj>
someone may be relying on some specific edge-case which then changes
<jonatack>
(onlynet=onion seems overused from what i can tell. maybe in a few months onlynet=onion + onlynet=i2p could become interesting)
<jonatack>
laanwj: agree
<laanwj>
onlynet=onion is nice if you want to avoid using exit relays on tor
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[gui] hebasto merged pull request #403: refactor: Make paths to update Encryption and HD wallet statuses simpler (master...210811-hd) https://github.com/bitcoin-core/gui/pull/403
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<laanwj>
that said, it's probably not the best place for privacy advice for end users
<laanwj>
although it can be convenient to edit documents (like release notes) there temporarily
<prayank>
jonatack: Thanks for the link. I was about to ask if we could add docs section here for tor and i2p. Will also need write access for people who want to contribute. But laanwj doesn't think it's the best place to do it. Problem is right now people get privacy advice on Twitter, Reddit, Telegram, Stackexchange etc. Users with different levels of technical expertise.
<michaelfolkson>
I think StackExchange is a good place for general privacy guidance. The Core docs document the Core software and how to use it, anything where there are differing perspectives and trade-offs to be discussed should probably be elsewhere
zenloading has joined #bitcoin-core-dev
<jonatack>
that's true, the wiki is being used for repo project management. an article on your personal blog or website or (good point) on BitcoinStackExchange seems good, or https://en.bitcoin.it (still maintained?)
<laanwj>
general privacy advice about using bitcoin spans much further than just using an overlay network, the most privacy-relevant in that regard is what you use to broadcast transactions
<michaelfolkson>
jonatack: Oh yeah :facepalm: I completely forgot about belcher's awesome privacy wiki. https://en.bitcoin.it/wiki/Privacy
<laanwj>
I think if you never broadcast your own transactions from your own node, how you connect is hardly privacy-sensitive at all, and overlay networks become more of a way of ensuring different connectivity to mitigate eclipse attacks
<michaelfolkson>
jonatack: It might need updating for a few things since 2019 but this is most exhaustive resource on privacy I think
<jonatack>
michaelfolkson: right! and last edited on 21 July 2021
<laanwj>
(of course there are different perspectives, some people mean 'privacy' as in 'hiding that you're running a bitcoin node in the first place' which is... very difficult if impossible with overlay networks)
<laanwj>
sure, your IP won't trivially show up in node lists, the sheer amount of data as well as timing patterns can give enough suspicion
<laanwj>
but it might be *enough* privacy for some cases, always hard to judge
<prayank>
Problem with Stackexchange and other places is you can write with more freedom and sometimes wrong things may not get noticed which in few years become a practice. Example: second paragraph in this comment by Greg Maxwell https://github.com/bitcoin/bitcoin/issues/17491#issuecomment-705485718
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] theStack opened pull request #22805: refactor: use CWallet const shared pointers in dump{privkey,wallet} (master...202108-refactor-const_correctness_for_further_dump_methods) https://github.com/bitcoin/bitcoin/pull/22805
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
klementtan has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<michaelfolkson>
prayank: No panacea (every source has upsides and downsides) but maintaining a version of that very long (but good) privacy wiki in the Core docs is not a road we want to go down.
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<muhblockchain>
git (not github) sounds for me like the perfect place to organize any documents (for devs as well as users)
<michaelfolkson>
prayank: Also I think belcher takes ownership of this privacy wiki as he wrote most of it in a way that he doesn't on some other non-privacy topics. Not many people know more about privacy than Chris
goatpig has quit [Quit: Konversation terminated!]
klementtan has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
<prayank>
michaelfolkson: Agree that privacy wiki has lot of interesting things. I respect Chris Belcher for his contributions in improving Bitcoin Privacy. The docs I was talky about were only for Bitcoin Core. Mainly Tor, i2p, wallet etc. This privacy wiki also needs some updates: Dandelion should be removed, i2p needs to be added, lot of things related to Tor (you can write few pages on just `onlynet`). Anyways it's just a suggestion.
goatpig has joined #bitcoin-core-dev
<laanwj>
from a more holistic point of view about "bitcoin privacy" i don't think something like onlynet contributes much
<laanwj>
my initial point was to make the option behave sensibly, instead of writing diatribes about all its exceptions and strange cases
AaronvanW has quit [Ping timeout: 250 seconds]
<prayank>
There are lot of users who care about privacy and interested to know about trade-offs involved in using Tor with i2p and other combinations which needs `onlynet`
<laanwj>
the way to make sure all outgoing connections go through a proxy has always been -proxy, this intentionally covers all networks
<prayank>
And I can't assure if everything mentioned is correct
<laanwj>
the other thing to worry about is incoming connections, you either want to stop listening or P2P make sure you only listen on localhost (for a Tor hidden service)
<laanwj>
that's it-
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jonatack>
good points
<laanwj>
that alone should be enough to run networking entirely through the proxy, if not, it's a serious bug
<laanwj>
prayank: thanks for writing something up
smartin has quit [Quit: smartin]
<prayank>
TBH I am not using i2p right now for mainnet. But experimenting a lot on testnet. There was a vulnerability in Tails long back and using two different complex things can always result in weird things which remain unnoticed for a long time. But it's good users have two options now: Tor and i2p
jespada_ has quit [Read error: Connection reset by peer]
jespada has joined #bitcoin-core-dev
<michaelfolkson>
I2P is more robust and reliable (apparently) than Tor
NorrinRadd has joined #bitcoin-core-dev
JackH has joined #bitcoin-core-dev
lkqwejhhgasdjhgn has quit [Quit: Konversation terminated!]
gene has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-core-dev
Guest97 has joined #bitcoin-core-dev
Guest97 has quit [Client Quit]
<michaelfolkson>
MarcoFalke: Re "I think long term there is no prospect that BIP 125 will be adhered to exactly" on #22665 why do you say that? Because you think BIP 125 is inferior to current Core code, because it would be too difficult to change in Core, because other implementations haven't implemented it etc?
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
lightlike has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22809: test: Check that non-signaling BIP125 tx can be replaced via parent (master...2108-testTxReplace) https://github.com/bitcoin/bitcoin/pull/22809
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<jonatack>
yes, it was WIP but the remaining hurdles seem to have been solved
<ariard__>
michaelfolkson: re bip125, well i'm still aiming to propose full-rbf for 0.24, though there is no guarantee it will land, still have to reach out to more historical opponents to have them express an opinion
Talkless has quit [Quit: Konversation terminated!]
JohnnyD has quit [Quit: Client closed]
<ariard__>
michaelfolkson: note, there is also a discussion between matt and i on why it might be preferable to depracte replace-by-fee towards replace-by-feerate here :https://lightningdevkit.slack.com/archives/CTBLT3CAU/p1625786787422100
<michaelfolkson>
ariard__: Cool, thanks. I'm guessing as you've described it as a CVE for Lightning you have a strong preference for it to be changed in the meantime
<michaelfolkson>
ariard__: (to follow the BIP logic)
<michaelfolkson>
I'm just trying to understand whether we should really care about this or not
<michaelfolkson>
Others have said (and I agree) that it isn't a CVE for Core
<michaelfolkson>
Going forward I think we need to take the BIPs more seriously. Different world when the BIP was originally written
<harding>
michaelfolkson: I don't think anyone took BIP125 less than seriously when it was written.
gene has quit [Quit: gene]
<harding>
I don't even know what "take the BIPs more seriously" means.
Kiminuo has joined #bitcoin-core-dev
<michaelfolkson>
harding: Right but Lightning didn't even exist. There wasn't these layer effect where something that seems minor on a lower level can be important for an upper level
prayank has joined #bitcoin-core-dev
jesseposner has quit [Ping timeout: 240 seconds]
<michaelfolkson>
I guess if there are no policy BIPs ever again then it is less relevant. But I kinda think there should be. But the attitude of "the BIP gets overruled by whatever ended up in Core" shouldn't cut it in today's environment
<michaelfolkson>
That seems the least and perhaps the most Core can do to help Lightning with this fuzzy policy guarantees problem
<harding>
michaelfolkson: to nitpick a little, LN was first described several months before BIP125 was written, and there were two different types of payment channels available for use at that time (BlueMatt wrote the implementation of one; I was on the team that wrote a different implementation which had just gone into light production use). Certainly second layer protocols are much more important today than they were back then, but it's not like
<harding>
people weren't thinking about them back then.
jesseposner has joined #bitcoin-core-dev
<michaelfolkson>
Fair enough
<prayank>
Implementation of a BIP with some differences should be fine. Problem was not documenting these differences which was fixed in https://github.com/bitcoin/bitcoin/pull/21946
<BlueMatt>
If you're trying to imply, michaelfolkson, that somehow bitcoin core review process is "fine" with a bip text saying something different than the implementation, I dont think thats ever been the case. mistakes happen, things are missed in review, but, indeed, its always been a thing that if the bip text disagrees with the implementation one or both need to be fixed.
<harding>
michaelfolkson: of course what's in an implementation should overrule what's in a BIP. BIPs are not laws, they're documentation.
<harding>
michaelfolkson: implementations can do whatever they want.
<BlueMatt>
which one depends on the situation, but I dont think anything here has changed in the past years, nor should it?
<michaelfolkson>
BlueMatt: I'm not trying to imply that. But now we're in a situation where there is a difference between the BIP and the code what should be done?
<BlueMatt>
we should look at the implementation, look at the BIP, decide which one makes more sense, and update the other one.
<michaelfolkson>
I totally agree ^. But that surely involves Lightning implementations as it is more important for Lightning as it is Core
<sipa>
FWIW, i disagree with changing the BIP - the number refers to the idea as it's written down, and changing it would only add confusion ("do you mean the old BIP125 approach or the new one?"); if we feel that this deserves a BIP in the first place, i think it'd need to be a new one
<harding>
(I don't really care, but I'm slightly against changing old BIPs, though I wouldn't mind adding a note to the bottom about the issue.)
<BlueMatt>
sure? And there's been some emails back and forth, though its not been a high priority for anyone, I believe.
<BlueMatt>
sipa: sure, i suppose thats a process question
jarthur has joined #bitcoin-core-dev
<sipa>
i don't have an opinion on whether the implementation should be changed, or the documentation (whether that's a BIP, or just a writeup of the policy)
<sipa>
just pointing out that the choice isn't changing the code or changing the BIP - there are other ways of changing the documentation that are less confusing
<michaelfolkson>
If Lightning implementations don't care that much then just leave it to what the Core mempool devs want to do which seems to be just stripping out references to the BIP
<michaelfolkson>
If Lightning implementations do really care then that should be factored in
<BlueMatt>
i believe lightning stuff *strongly* prefers as loose a mempool policy as possible :p
<sipa>
whatever happens, the implemented policy should be well-documented
<michaelfolkson>
That's why I asked ariard about how strong his preference was for updating policy to match the BIP
<harding>
Differing mempool policies was actually anticipated, BIP125 says: "A Bitcoin Wiki page has been created to help wallet authors track deployed mempool policies relating to transaction replacement." which links to https://en.bitcoin.it/wiki/Transaction_replacement
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
AaronvanW has quit [Ping timeout: 240 seconds]
bomb-on has quit [Quit: aллилѹіа!]
earnestly has quit [Read error: Connection reset by peer]
gleb7 has quit [Quit: Ping timeout (120 seconds)]
gleb7 has joined #bitcoin-core-dev
vysn has quit [Remote host closed the connection]
Guest82 has joined #bitcoin-core-dev
Guest82 has quit [Client Quit]
lightlike has quit [Ping timeout: 250 seconds]
<ariard__>
michaelfolkson: i think it's preferable to well-document in the core code the divergences to the spec, instead of rewritting a new bip matching the code
<ariard__>
and maybe add a small bottom note for the ln devs who aren't fluent in cpp
<ariard__>
w.r.t to bip vs code, i think it's ultimately a case-by-case situation, weighting the implications
gleb7 has quit [Quit: Ping timeout (120 seconds)]
gleb7 has joined #bitcoin-core-dev
jesseposner has quit [Ping timeout: 240 seconds]
biteskola has joined #bitcoin-core-dev
biteskola has quit [Remote host closed the connection]
aitorjs has joined #bitcoin-core-dev
aitorjs has quit [Client Quit]
jesseposner has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
jesseposner_ has joined #bitcoin-core-dev
jesseposner has quit [Ping timeout: 248 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto opened pull request #22811: build: Fix depends build system when working with subtargets (master...210826-subtarget) https://github.com/bitcoin/bitcoin/pull/22811
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
gambpang has quit [Remote host closed the connection]