bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #24472: fuzz: execute each file in dir without fuzz engine (master...202203-phuzztesting) https://github.com/bitcoin/bitcoin/pull/24472
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
shesek has joined #bitcoin-core-dev
jouke has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_K_ has quit [Ping timeout: 240 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto opened pull request #24597: doc, guix: Include `arm64-apple-darwin` into codesigned archs (master...220317-docs) https://github.com/bitcoin/bitcoin/pull/24597
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Alexthek1d has joined #bitcoin-core-dev
<Alexthek1d>
Hello,
<Alexthek1d>
if you download the full node with bitcoin-core and i choose an external hard drive as target for the node:
<Alexthek1d>
Does bitcoin-core copy the data temporarily to the drive of the OS first (so "caching") or in memory/RAM and then to the external hdd?
<Alexthek1d>
(I ask because i do not want too many write operations on my OS drive)
<sipa>
It will only use the drive/directory you select.
<Alexthek1d>
sipa, thank you :)
ifeanyi has quit [Ping timeout: 256 seconds]
NorrinRadd has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
shesek has quit [Remote host closed the connection]
shesek has joined #bitcoin-core-dev
NorrinRadd has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jouke has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 250 seconds]
Alexthek1d1977 has joined #bitcoin-core-dev
Alexthek1d has quit [Ping timeout: 252 seconds]
mudsip has joined #bitcoin-core-dev
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
mudsip has quit []
brunoerg has quit [Ping timeout: 252 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #24600: doc: mention that BDB is for the legacy wallet in build-freebsd.md (master...freebsd_legacy_descriptor_switch) https://github.com/bitcoin/bitcoin/pull/24600
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
ghost43_ has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
bomb-on has joined #bitcoin-core-dev
<MarcoFalke>
tea time, I guess
<fanquake>
knock off time
brunoerg has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
<achow101>
bah, can't comment either :(
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
<earnest>
achow101: Will descriptor wallets ever work with sethdseed and the ability to dump the (WIF) seed?
<achow101>
Earnest: no
<earnest>
That is a feature I wanted to use but it seems to be going away now, I'll have to reconsider this
<sipa>
You can dump the descriptor(s), though.
<earnest>
Yeah, I noted that and the recent change to dump the tprv as well
<achow101>
#23417 may allow for exporting the master private key however
<gribble>
https://github.com/bitcoin/bitcoin/issues/23417 | wallet, spkm: Move key management from DescriptorScriptPubKeyMan to wallet level KeyManager by achow101 · Pull Request #23417 · bitcoin/bitcoin · GitHub
<earnest>
But that's not nearly as useful as seeds, including any inactiveseeds
<achow101>
but with descriptor wallets, we want to be explicit about what is being imported and watched for, rather than inferring
<earnest>
I quite like the idea of having my public/private keys being derived from a password/phrase, considerations for security withstanding
<earnest>
So that I don't have to entirely rely on the robustness of computers
<earnest>
(Much like curiosity, they rebooted it 7 times a day, just in case its state became corrupted)
<achow101>
key's are not useful if you don't know what scripts, and seeds are not useful without derivation paths
<sipa>
you can print a descriptor to paper or so as well
<earnest>
achow101: This is a fair point, yeah
<achow101>
descriptors does not preclude containing bip39 mnemonics or other methods of deriving keys as KEY expressions
<earnest>
Oh yeah, the new wallets are much nicer in that respect
<earnest>
achow101: Yes, that's what I'm getting at
<earnest>
(Doesn't have to be necessarily seed words though)
lucasdcf has quit [Ping timeout: 252 seconds]
<earnest>
If you don't mind, thanks for answering so far, but listdescriptors on a new wallet will output 4 of them, and seems they're all the same but with different derivation paths and checksums. As the tpub/tprv is the same for all of them, how would you import that tprv in such a way to recover them all instead of just one?
<earnest>
Hm, actually I can probably answer that myself
<sipa>
you don't import tprvs; you import the whole descriptor
<earnest>
Yeah, I just remembered that heh
<earnest>
achow101: 23417 seems nice yeah
jouke has quit [Ping timeout: 256 seconds]
szkl has quit [Quit: Connection closed for inactivity]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 240 seconds]
NOD32Admin has quit [Quit: NOD32Admin]
NOD32Admin has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
NOD32Admin has quit [Quit: NOD32Admin]
NOD32Admin has joined #bitcoin-core-dev
lucasdcf has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
vysn has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
Alexthek1d1977 has quit [Quit: Leaving]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
NorrinRadd has joined #bitcoin-core-dev
NorrinRadd has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Flow has quit [Ping timeout: 252 seconds]
Flow has joined #bitcoin-core-dev
NOD32Admin has quit [Read error: Connection reset by peer]
brunoerg has quit [Remote host closed the connection]
NOD32Admin has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
jouke has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
shesek has quit [Remote host closed the connection]
<laanwj>
i guess that was it for high prio, let's move to next topic
<laanwj>
#topic Important changes in 23.0 to cover in the new RC Testing Guide (stickies-v)
<core-meetingbot`>
topic: Important changes in 23.0 to cover in the new RC Testing Guide (stickies-v)
<stickies-v>
Context: I've started working on updating the 23.0 RC Testing Guide, and I'd like to get some early feedback on which changes are considered important and useful to test since we don't have too much until release date.
ghost43 has joined #bitcoin-core-dev
<stickies-v>
From the release notes (https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Notes-draft), I've selected the 5 changes I think most worthwhile to test, and 1 extra if I have time to get to it. I'd very much appreciate feedback on if you think anything else should really be included, and if maybe something can be omitted.
<stickies-v>
The changes I've selected are (in random order, summarized from release notes):
<luke-jr>
stickies-v: release dates are not firm; it's ready when it's ready
<stickies-v>
1. The strong preference for only connecting to peers that listen the standard port 8333 has been removed. (#23542)
brunoerg has quit [Remote host closed the connection]
<stickies-v>
2. Descriptor wallets are now the default wallet type. Newly created wallets will use descriptors unless descriptors=false is set during createwallet.
<stickies-v>
3. The validateaddress RPC now returns an error_locations array for invalid addresses, with the indices of invalid character locations in the address (if known). (#16807)
<stickies-v>
4. The getblock RPC command and /rest/block/ REST endpoint now support verbosity level 3 containing transaction inputs' prevout information.
<stickies-v>
5. Information on soft fork status has been moved from getblockchaininfo to the new getdeploymentinfo RPC which allows querying soft fork status at any block, rather than just at the chain tip. (#23508)
<laanwj>
because nothing will really give you non-8333 ports frequently yet (e.g. the DNS seeds strongly prefer 8333)
<luke-jr>
laanwj: well, testers can at least verify they have 8 peers that look randomish?
jouke has quit [Ping timeout: 256 seconds]
<michaelfolkson>
And 2 isn't new for this release. Not sure if that should be a focus?
<laanwj>
sure, you can test that you still get usable peers
<hebasto>
owners of Apple M1 could test native arm64 binaries
<laanwj>
hebasto: yes, that's a good one
<luke-jr>
and they don't get deleted :P
<hebasto>
indeed
<stickies-v>
hebasto: thanks I'll include that
<laanwj>
stickies-v: thanks for working on this btw
<jonatack>
stickies: would be nice to test bitcoind over CJDNS, including IBD with -onlynet=cjdns and dns seeds
Flow has joined #bitcoin-core-dev
<stickies-v>
jonatack: cool, will add that too
<jonatack>
stickies-v: great
<stickies-v>
I was thinking the non-default port could be tested on regtest, since it does seem like quite an important change for the network going forward?
brunoerg has joined #bitcoin-core-dev
<stickies-v>
achow101: what do you think about michaelfolkson's comment regarding descriptor wallet becoming default not being important to include in the testing as it's not a new change?
<jonatack>
stickies-v: you might be able to easily recycle the I2P testing in the last release testing, and link to doc/cjdns.md in #24555
<laanwj>
i don't think port preference ever plays a role on regtest, as all connections are manual
<luke-jr>
were there any major changes to descriptor wallets between 21/22.x and 23.x?
<luke-jr>
besides adding Taproot
<jonatack>
(e.g. convert the I2P testing section for v22 to CJDNS)
<stickies-v>
hmm okay didn't know that, will reconsider 1. then and leave it out if I don't find any good way to test efficiently
<achow101>
stickies-v: I don't feel strongly either way. frankly, it's such a small change that there isn't much that could go wrong
<laanwj>
but if you consider it like that, all functional tests test non-default ports, as they pseudo-randomly assign ports
<MarcoFalke>
I think the most important testing is of the parts that everyone assumes *not* to be changed.
<luke-jr>
true
brunoerg has quit [Ping timeout: 240 seconds]
<MarcoFalke>
Surely, it is important that new features are tested, but even more importantly everything else shouldn't break
<jonatack>
3, 4, and 5 may be well-tested already (if I'm not mistaken), not sure if there is much value in people checking those
<laanwj>
also testing it with third-party programs is always interesting (i guess e.g. joinmarket, c-lightning are covered)
<lightlike>
I think it should work to addpeeradress a couple of fantasy addresses with default/non default ports and take statistics what it tries to connect to.
<luke-jr>
new features are probably more tested already too
<MarcoFalke>
Jup, any business or third party software should have a test suite to check that their use of Bitcoin Core doesn't break with an upgrade
<stickies-v>
MarcoFalke: that's a good point but I'm not sure if that's something we can make actionable in this testing guide?
brunoerg has joined #bitcoin-core-dev
<stickies-v>
I think it's more of an intro get people familiar with testing and with what's changing
<laanwj>
right, the testing guide is more about giving peopel specific focus what they could test, if it's just "what you are doing already" it's short
<stickies-v>
alright thank you for the ideas everyone, I'll look into all of these suggestions and revert next week with a draft of the guide
<michaelfolkson>
Ok makes sense. Leave it up to your judgment then stickies-v :)
<jonatack>
right, the reason i mention the cjdns testing is also that there are more moving parts, platforms, cases and possible issues that may not have been seen yet
<laanwj>
thanks!
<laanwj>
let's move to next topic
<laanwj>
#topic Adjusted time offset warning (MarcoFalke)
<core-meetingbot`>
topic: Adjusted time offset warning (MarcoFalke)
<MarcoFalke>
So while the adjusted time was improved over the last couple of years, it still has some shortcomings
An0rak has joined #bitcoin-core-dev
<laanwj>
i've always felt really uncomfortable with the time adjustment code
<laanwj>
can't we just like phase it out
<MarcoFalke>
Just to mention a few: (1) non-monotonic (2) adjusted by peers ...
<MarcoFalke>
So I was thinking to simply remove it and replace it with a stronger warning mechanism
<laanwj>
adjusted by peers based on unauthenticated cleartext data, based on strange criteria which we're too scared to touch
<laanwj>
ack
<luke-jr>
sounds like a good idea IMO
brunoerg has quit [Ping timeout: 240 seconds]
<MarcoFalke>
The question is how to warn?
<laanwj>
isn't there a warnings field on some RPC call
<lightlike>
what would that "stronger warning mechanism" look like?
<luke-jr>
laanwj: GUI can probably use improvement
<MarcoFalke>
We can't warn at startup, as only the local system time is available
<luke-jr>
maybe the sync overlay could be a good place for it
<MarcoFalke>
I think the GUI is already good. There will be a orange warning, very hard to miss
<laanwj>
yes that seems fine to use
<MarcoFalke>
(For reference there is a long thread at #4521 with cross-links)
<laanwj>
warnings can be added at any time (it is, or was, used for some other network conditions too)
<MarcoFalke>
So one option I was thinking about was to just shut down the node. Does that seem too agressive?
<laanwj>
way too aggressive
<laanwj>
just log a message and make it available on a RPC call
<laanwj>
like we've always done for warnings
<MarcoFalke>
It seems unlikely the user will ping the RPC regularly to get the warning
<laanwj>
making it possible for peers to shut down your node by flooding you with massaged time values is even worse than we have now
<laanwj>
for fact, they do
<luke-jr>
maybe safe mode wasn't a terrible idea
<laanwj>
or at least used to when warnings were more common i don't know nowadays
<MarcoFalke>
ok, good point
jessebarton has quit [Quit: Client closed]
<luke-jr>
laanwj: otoh, if all your peers are, maybe you want new peers..
<MarcoFalke>
luke-jr: I don't think there is a need to shut down the wallet? I think this mostly affects the mining code
<luke-jr>
MarcoFalke: I would expect miners to be monitoring the node state closely
<laanwj>
i think it would be valid to strip out the time adjustment system completely, just leave it up to the user's responsibility to have their time correct, like other software does
<MarcoFalke>
So my other idea was to throw an exception in getblocktemplate. Does that seem too agressive?
<laanwj>
having a warning is nice but i don't see it as cirical
<laanwj>
not sure why this would need a more aggressive mechanism than other warnings
<luke-jr>
MarcoFalke: also, miners are likely to internally only have peers with their own nodes
<luke-jr>
so throwing in GBT won't be helpful IMO
<jeremyrubin>
could also have something like walletnotify where we call a script to get the time
<jeremyrubin>
that would make it possible for pluggin in an arbiitrary time source if users don't want their system time
<laanwj>
come on, it's 2022, computers tend to have correct system time these days
<luke-jr>
jeremyrubin: idk why we would support not using system time
<laanwj>
if you want to mess aroudn with the time for whatever reason there's faketime and even time namespaces in newer linux kernels
<MarcoFalke>
ok, I mean I am fine just removing it. I just wanted to see if there is something we could do better
<luke-jr>
laanwj: exactly
<luke-jr>
we have mockable time too
<jeremyrubin>
i just mean that if you want behavior for "my peers think the time is different" you could let that be configured as a script callback
<MarcoFalke>
luke-jr: Not for main-net
<laanwj>
MarcoFalke: so i would say the proposal to change it to a warning is fine, for now, it can always be fully removed later if we want, but i don't think it needs a more aggressive mechanism
<luke-jr>
MarcoFalke: could be trivially enabled if desired
<MarcoFalke>
laanwj: I think a warning already exists
<MarcoFalke>
I can add a new dedicated RPC for it, too
<laanwj>
not sure a dedicated RPC would be better
<jeremyrubin>
(you can also crontab and parse the log for the warning, which is fine)
<laanwj>
things like warnings are better grouped, so people don't have to listen for everything separately
<MarcoFalke>
I guess a dedicated RPC would make jeremyrubin also happy
<laanwj>
don't we have the time delta in RPC already somewhere
<MarcoFalke>
getpeerinfo, maybe?
<MarcoFalke>
At least the GUI shows it in the peers tab
* jeremyrubin
ponders the nature of happiness
<jeremyrubin>
i will say that a good portion of nodes might be running on centralized time servers
<laanwj>
i think it's ok to make the information available, dont' think a new RPC is worth it
<jeremyrubin>
so this might be giving someone somewhere the "brick all the nodes" key
<jonatack>
getpeerinfo has a timeoffset field in seconds
<jeremyrubin>
but i don't think it's the biggest deal
<laanwj>
it's not like the time adjustment scheme really protected against that
<luke-jr>
jeremyrubin: … someone who can centrally control your server's time, can probably just shut off the power too
<laanwj>
if you can sabotage a centralized timeserver sure you could mess up things for a bit until people figure it out
<jeremyrubin>
luke-jr: i would expect apple can change my laptops time, but i don't think they can shut my power off
<laanwj>
they could probably delete all software from your system at least
<luke-jr>
that seems naive, but I understand - thought you meant VPS with a shared kernel
<MarcoFalke>
adjusted time really only protects against a 30 or 60 minute offset (DST/time zone) for at most half a year
<laanwj>
in any case, if you're serious about mitigating attacks on timeservers i'd guess that has a much bigger scope than bitcoin
<laanwj>
like, run your own atomic clock and adjust your system time to it
<MarcoFalke>
adjust your system time to Bitcoin (timechain) MTP
<laanwj>
btw, ntp also allows for only very small on the fly changes
<MarcoFalke>
(obviously don't do that)
<laanwj>
it's not like your ntp server can suddenly warp you back hours or days
brunoerg has joined #bitcoin-core-dev
<luke-jr>
MarcoFalke: might not be terrible tbh
<luke-jr>
if you have a working monotonic clock
<laanwj>
at boot up it will probably accept any time, especially on embedded systems without a RTC, but that's also easiest to detect
<MarcoFalke>
luke-jr: You might miss blocks if MTP is lagging too much
<laanwj>
it's also hardly a 'brick all the nodes' key if you have to wait for all servers running nodes to reboot first :)
<earnest>
monotonic vs bootime might be worth considering as monotonic clocks tend to stop when systems sleep afaiui
<luke-jr>
MarcoFalke: well, you'd have to do MTP + 30 minutes at least. a bit of buffer would help handle stuff like this.
<luke-jr>
laanwj: modern systems constantly sync their clocks over NTP, not just at boot
<laanwj>
Earnest: monotonic clocks are only used for measuring time intervals, so that's fine, usually
<luke-jr>
though maybe only within some limited drift
<laanwj>
luke-jr: yes, but only minimal adjustments
<laanwj>
at least that's how linux ntpd works, i have no idea about other OSes
<luke-jr>
lots of people use systemd OS now :p
brunoerg has joined #bitcoin-core-dev
<luke-jr>
(it ate ntpd)
<jonatack>
getnetworkinfo has a timeoffset field that is our GetTimeOffset() result, IIUC, as opposed to the offset for each peer in getpeerinfo
<earnest>
As systemd-timesyncd which is sntpd implementation
<laanwj>
i mean, with all the complications and exceptions it's not realistic as an attack on bitcoin, that's all i was trying to say
<laanwj>
jonatack: nice, so that too already exists
<luke-jr>
maybe getblocktemplate should throw if there's a known better-except-for-time-just-barely block?
<luke-jr>
seems more likely to cause than solve problems tho
<MarcoFalke>
luke-jr: How often did that happen in the last 10 years?
Guest28 has joined #bitcoin-core-dev
<luke-jr>
MarcoFalke: no clue
<jonatack>
(and only outbound peers offsets contribute to our timedata samples to make it harder for peers to tamper with our adjusted time... src/net_processing.cpp::2761)
brunoerg has quit [Ping timeout: 256 seconds]
<luke-jr>
kinda doubt miners would risk getting so close to the time cutoff
<Guest28>
stickies-v: 1 can be tested for non default ports, you just need to look for nodes that are using such ports. There are different ways to do it.
<laanwj>
right i would be surprised if miners weren't already really careful about having correct time on their machines, to rule that out as a reason to miss a block reward
Guest28 has quit [Client Quit]
brunoerg has joined #bitcoin-core-dev
<laanwj>
any well-meaning protective mechanism added on top might just get in the way in case of some edge case
<MarcoFalke>
Even if one miner is back by 1h and another one forward by 1h, it shouldn't lead to any issues
<MarcoFalke>
Only if the difference is more than 2h
<dongcarl>
One question: there are a few PRs which others have opened that will help make future work in libbitcoinkernel easier, can I add an "Relevant External PRs" column to keep track of those?
<jonatack>
seems to be some good discussion of -maxtimeadjustment tradeoffs in #7573
<laanwj>
i disabled time adjustment entirely for a while but i don't think i'm still bothering in my current configs
<laanwj>
dongcarl: yes, feel free to organize the project board as is useful for you
An0rak has quit []
<dongcarl>
Also, I'm a bit confused as to what the conclusion of the timedata conversation was above, will we remove it?
<laanwj>
dongcarl: i don't think there was a conclusion
<dongcarl>
Okay got it. Will operate under the assumption that we're not imminently removing it then
<jeremyrubin>
one option we didn't discuss (i think?) is that we can phase it out by continuing to send out our time messages but not reading them... that way we don't let old nodes who rely on these time broadcasts get attacked
<jeremyrubin>
so it can be a thing where we'll happily tell anyone our time, but not care about others time
<laanwj>
i don't think there is any proposal to remove the time from version messages?
Talkless has quit [Quit: Konversation terminated!]
<laanwj>
well i think i heard it mentioned as a fingerprinting vector once, but it's definitely not the same proposal as stopping doing time adjustment
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
bitcoin/master e09cf64 MarcoFalke: Merge bitcoin/bitcoin#24585: doc: mention that BDB is for the legacy walle...
<bitcoin-git>
bitcoin/master bf84677 fanquake: doc: cleanup wallet docs in build-osx.md
<bitcoin-git>
bitcoin/master 57f3f5c fanquake: doc: s/Compiler/Dependency in dependencies.md
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #24585: doc: mention that BDB is for the legacy wallet in build-osx.md (master...build_osx_descriptor_legacy_switch) https://github.com/bitcoin/bitcoin/pull/24585
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<jonatack>
hm, maybe a first step (if people think it's an improvement) would be to change the default -maxtimeadjustment
<laanwj>
it'd be a BIP level change; mind that the version message was always the only time adjustment input, there is no 'time message'
<MarcoFalke>
We can save that for the cleanup-version-msg-bip
<laanwj>
yes
<MarcoFalke>
Pretty sure there is other stuff in the version message that needs to be removed
<laanwj>
correct
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
<lightlike>
just noting that with 23.0, we don't use any timestamps from inbound peers anymore (#23631) - that should help with some concerns at least.
<laanwj>
that said, system time in seconds is a pretty lousy fingerprinting vector, and besides, it's also part of many lower level network packets already, so removing it from the bitcoin protocol doesn't do that much to prevent it being used
<laanwj>
(this is where centralization of time actually helps for privacy i guess :-)
sipsorcery has quit [Read error: Connection reset by peer]
<MarcoFalke>
lightlike: jonatack: right, that makes it harder to attack adjusted time, but it retains the issues of adjusted time that are present even in the absence of attacks
<jonatack>
jeremyrubin: setting the default -maxtimeadjustment to 0 would take care of that, I guess
<jonatack>
and users could opt in to allowing peers to adjust the timedata
<laanwj>
so that would imply anyone would voluntarily want to enable it
<laanwj>
but it definitely would be the most straightforward change, sure
sipsorcery has joined #bitcoin-core-dev
hashfunc569 has joined #bitcoin-core-dev
Guest28 has joined #bitcoin-core-dev
<Guest28>
Hi, I would like to know if there is some upcoming privacy method to Bitcoin Core. Even something basic like PayJoin would be nice. Thx!
<jonatack>
yes, i don't know. people seemed to want it on by default in the discussion in #7573. perhaps things have changed as you mentioned earlier above.
<Guest28>
jonatack I don't find any information related to transaction privacy there
<jonatack>
hm, cjdns isn't in the release notes
<Guest28>
(I mean blockchain privacy, not Tor related features)
<jonatack>
Guest28: there may be some items still missing from the release notes draft, but IIRC not a change like you are looking for in v23
<Guest28>
jonatack ok! Is there any chance the upcoming Mimblewimble solution on extension blocks on Litecoin will come to Bitcoin Core? :)
<Guest28>
All risks are contained to the extension block and increases capacity as MW transactions are very small. People could have their savings in the main block (public) and use the extension block for their expenses.
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
<laanwj>
this channel is for implementation issues, the mailing list or #bitcoin-wizards would be a better place to discuss proposed consensus changes
<Guest28>
laanwj ok, I will ask there, thx! :)
<laanwj>
jonatack: yes, not sure how much changed in opinions there since 2016, i've always been uncomfortable with the node time adjustment system as it is (also clear from my replies there), but not everyone shares that sentiment obviously
An0rak has joined #bitcoin-core-dev
An0rak has left #bitcoin-core-dev [#bitcoin-core-dev]
An0rak has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
ghost43 has quit [Remote host closed the connection]
<Guest58>
b) testimonials prove its not a priority c) encryption is not always privacy
<Guest58>
Its tring to solve different problems and using ipv6.
<Guest58>
*trying
Guest58 has quit [Client Quit]
<laanwj>
no, cjdns is not a privacy network, this is well-known, its usecase is for mesh networks, I2P and Tor are supported privacy overlay networks
<laanwj>
besides, mind that privacy requires a large anonimity set so if that's your goal, using something more obscure than Tor or maybe I2P could end up making you less instead of more private
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
An0rak has quit []
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_K_ has quit [Ping timeout: 252 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
morcos has quit [Remote host closed the connection]
morcos has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
hashfunc569 has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
<jonatack>
Guest58: yes sorry, I noticed that cjdns isn't in the release notes draft but didn't intend to suggest that it was an answer to your question.
Guest7843 has joined #bitcoin-core-dev
<Guest7843>
jonatack: it wasnt me. we can select our own nick in webchat using this url: https://web.libera.chat/#bitcoin-core-dev and GuestN can be anyone. N depends if its available imo. Guest99 at 00:00 UTC wont me same as Guest99 at 00:30 most of the times.
Guest7843 has quit [Client Quit]
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
lucasdcf has quit [Ping timeout: 250 seconds]
Guest63 has joined #bitcoin-core-dev
Guest63 has quit [Client Quit]
brunoerg has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
szkl has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 252 seconds]
bitdex has quit [Ping timeout: 240 seconds]
geyaeb has quit [Remote host closed the connection]