ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
vasild has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
szkl has quit [Quit: Connection closed for inactivity]
AaronvanW has quit [Ping timeout: 252 seconds]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
Norrin has joined #bitcoin-core-dev
vasild_ has joined #bitcoin-core-dev
MrFrancis has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
vasild has quit [Ping timeout: 255 seconds]
andrew_mo_ has joined #bitcoin-core-dev
halosghost has quit [Quit: WeeChat 3.8]
andrew_mo_ has quit [Ping timeout: 248 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
brunoerg has quit [Ping timeout: 252 seconds]
jarthur has quit [Quit: jarthur]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 248 seconds]
AaronvanW has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
jarthur has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
<ariard>
jamesob: there is a (3) if there is a time-sensitive spend contest for all the parent, an attacker can replace one-by-one the parents with a higher-fee/higher-feerate package to evict the common child
andrew_mo_ has quit [Ping timeout: 260 seconds]
<ariard>
therefore delaying the confirmation of your remaining honest parents, of which the delay is function of your rebroadcast/re-bump frequency
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
Cory has quit [Ping timeout: 255 seconds]
Cory has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
MrFrancis has quit [Ping timeout: 248 seconds]
brunoerg has quit [Ping timeout: 252 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
jonatack has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
Guest920 has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
Guest920 has quit [Quit: Client closed]
andrew_mo_ has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 248 seconds]
jarthur has quit [Ping timeout: 255 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 248 seconds]
brunoerg has quit [Ping timeout: 256 seconds]
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
andrew_mo_ has quit [Ping timeout: 252 seconds]
bitdex has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Norrin has quit [Ping timeout: 255 seconds]
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
_andrewtoth_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
vasild_ has quit [Ping timeout: 255 seconds]
andrewtoth_ has quit [Ping timeout: 255 seconds]
szarka has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
andrew_mo_ has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
Norrin has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Norrin has quit [Remote host closed the connection]
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
qxs has quit [Remote host closed the connection]
cryptapus has quit [Quit: Konversation terminated!]
cryptapus has joined #bitcoin-core-dev
qxs has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
MrFrancis has quit [Ping timeout: 248 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
andrew_mo_ has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
andrewtoth_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
_andrewtoth_ has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
BitcoinCharlie has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
andrew_mo_ has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 246 seconds]
andrew_mo_ has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
BitcoinCharlie has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
sudoforge has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
jon_atack has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Quit: Leaving...]
brunoerg has quit [Ping timeout: 248 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
halosghost has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<bitcoin-git>
[gui] john-moffett opened pull request #705: doc: Fix comment about how wallet txs are sorted (master...2023_01_FixIncorrectCommentTTM) https://github.com/bitcoin-core/gui/pull/705
andrew_mo_ has joined #bitcoin-core-dev
Pasha has joined #bitcoin-core-dev
Cory has quit [Ping timeout: 256 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
<cbdc-core-dev>
Central bank digital currencies (CBDCs) are digital versions of fiat currencies that are issued and regulated by a country's central bank.
<cbdc-core-dev>
They have potential to improve freedom and privacy as mentioned by bitcoin developers. Can we create a github repo like some gov agency to keep it open source and still kill bitcoin?
<cbdc-core-dev>
Maybe cfields and kanzue might know more about it
<cbdc-core-dev>
I can open an issue if we support CBDC in bitcoin core as bitcoin is just gold and we can have some currency to transact.
<cbdc-core-dev>
* kanzure
<kanzure>
huh?
<cbdc-core-dev>
lol
<kanzure>
you're welcome to start a different project, but i don't see how your messages are related to bitcoin core software development
<cbdc-core-dev>
kanzure: you like cbdc?
<cbdc-core-dev>
why are you sending me DM for another shitcoin like webcash.org ?
<cbdc-core-dev>
do you even moderate bitcoin-dev mailing list?
<achow101>
#topic hd key rotation vs new wallet (achow101)
<core-meetingbot>
topic: hd key rotation vs new wallet (achow101)
<achow101>
in #26728, S3RK brought up the question that there isn't a well defined use case for having key rotation, as all of the cases that we've brought up are sufficiently handled by making a new wallet
<gribble>
https://github.com/bitcoin/bitcoin/issues/26728 | wallet: Have the wallet store the key for automatically generated descriptors by achow101 · Pull Request #26728 · bitcoin/bitcoin · GitHub
Guest43 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<achow101>
if that's the case, then we could simply the implementation to not allow key rotation and just instruct people to use new wallets
<achow101>
I've had conversations with sipa and luke-jr about this in the past, but I think everything that was discussed could also just work with using a new wallet?
<S3RK>
yes, I think it's preferrable to have a simpler implementation if all the use cases are covered by creating a new wallet
<S3RK>
One thing I wonder is key rotation during encryption
<sipa>
a new wallet means losing tx history?
MrFrancis has quit [Ping timeout: 252 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
<achow101>
iirc the main point was that a user would want to rotate keys when if they think their keys were compromised, but then it follows that making a new wallet is better than rotating as there is less likelihood of reusing potentially compromised keys afterwards
<achow101>
sipa: with multiwallet, does that really matter? The old wallet can still be loaded and history viewed.
<sipa>
it also requires moving all the funds over
<S3RK>
I guess I'd like to understand first when people feel like they need to rotate HD key
<provoostenator>
hi
<sipa>
i think periodically rotating keys makes sense as a security safeguard, even without any known compromised keys
<sipa>
but if you it involves losing history and moving all funds over, that's a lot less appealing
<S3RK>
it might be a stupid question, but safeguard against leaked keys? IIUC you're saying there is some risk of the keys being compromised so I'd like to rotate them, but the risk is not high enough to warrant extra caution to avoid mixing utxos unintentionally
<achow101>
but what kind of safeguard does that provide? istm you would do it because maybe something was compromised, but if that's the case, wouldn't you want to move all of the funds to the new key(s)
<sipa>
hmm, that's a fair point
<S3RK>
yes
<provoostenator>
The wallet could encourage such moving in other ways of course.
<S3RK>
we have sendall now to facilitate migration
<provoostenator>
But a fresh wallet makes that more intuitive.
<Murch1>
Hi
<sipa>
another downside is that if somehow someone still sends coins to the old wallet after rotation, you may not notice if it's a separate wallet, and you don't keep all the old ones loaded and watched
<S3RK>
:waves:
<provoostenator>
And the old wallet might fall behind the prune window too if it's not loaded, making it very painful to access unexpected payments to it.
<provoostenator>
(though that's fixable)
<achow101>
with multiwallet and the settings.json stuff, it's not that hard to keep multiple wallets loaded automatically
brunoerg has joined #bitcoin-core-dev
<Murch1>
Would it be possible to monitor multiple wallets, but to only have one active in the sense that you are using its UTXO Pool to send and its addresses to receive?
<sipa>
a wallet can contain multiple SPKMs
<sipa>
so you can do all that already, within a single wallet
<achow101>
Murch1: yes, multiwallet
<S3RK>
the problem I see with one wallet is that you don't have any separation between "old" spkms and "new" ones
<sipa>
well multiwallet is something else still, as API wise those are completely separated
<S3RK>
if you rotate more than one time it can easily become a mess
<sipa>
S3RK: active and inactive ones?
<achow101>
with rotating by using a new wallet, it would become obvious when something was sent to the old one
<S3RK>
you can still spend from inactive spkms
<achow101>
as the tx shows in the old wallet's history and not the new one's
<sipa>
right
<achow101>
even with inactive spkms, we don't distinguish in the tx history unless you go look at the address and then getaddressinfo it and compare the descriptors
<sipa>
and in case you rotate because of compromise, you probably actually do want to see payments to the old one as separate
<sipa>
"crap, i need to move more funds over now"
<S3RK>
sorry :D
<sipa>
having some mode to mark a wallet as compromised, so that all funds sent to it are automatically transferred elsewhere may be useful too...
<S3RK>
but are there cases when people want to rotate without keys being compromised?
brunoerg has quit [Ping timeout: 256 seconds]
<Murch1>
Sure, e.g. if you‘re still on a legacy wallet and want to move to a descriptor wallet maybe?
<achow101>
Murch1: strictly speaking, it doesn't have to. but it's a lot easier to implement migration in that way
<sipa>
S3RK: Well, historically, pre-HD wallets had a "feature" that they get "unstolen" over time, as change outputs and new receives would over time end up in new keys that an old stolen backup did not contain.
<achow101>
we rotate on encrypting, but considering the above conversation, that maybe doesn't make sense anymore?
<sipa>
This discussion I think started from the question whether wallet migration is ever not strictly an upgrade, and one example is that if the migration only supports going to HD wallet, this "unstealing" effect that the user (very questionably, hypothetically) could be relying on, disappears.
<achow101>
sipa: arguably it disappeared a long time ago when the default keypool was bumped up to 1000
<sipa>
It's very questionable as it only works on pretty high-turnover wallets anyway, with unclear timelines, and only when an attacker gets access to private keys and then bides their time without actually stealing.
<S3RK>
that sounds like an argument for non-HD wallets, which is separate from the question of whether HD key rotation within same wallet is a valid use case
<sipa>
S3RK: I don't think so. Because the extent to which these non-HD wallet had that feature was really accidental, and unreliable.
<sipa>
If we actually want it as a feature, key rotation is the proper solution.
<S3RK>
hm... key rotation when exactly?
<sipa>
periodically
<S3RK>
sounds like non-HD to me :D
<achow101>
that doesn't sound like a feature that even makes sense to rely on, even with periodic key rotation
<sipa>
Hmm, no, not all. The point is that it'd need to be time or volume based or so, not transaction count based.
<achow101>
you'd still have to have a high turnover wallet
<achow101>
and coin selection that selects older coins
<Murch1>
And then you need to make a new backup setup at the same time
brunoerg has joined #bitcoin-core-dev
<sipa>
Anyway, I also see the point of view that key rotation in this sense isn't actually a desirable feature, even when done properly, and the only reasonable way to get "unstealing" protection is actually migrating to a new wallet entirely from time to time.
<achow101>
also, we can add it in later if there is a genuine use case for it
<achow101>
for #26728, I'll remove the key rotation handling stuff. we can always reintroduce it
<Murch1>
achow101: We have `maxHeight` now ;)
<gribble>
https://github.com/bitcoin/bitcoin/issues/26728 | wallet: Have the wallet store the key for automatically generated descriptors by achow101 · Pull Request #26728 · bitcoin/bitcoin · GitHub
<Murch1>
Or minConf which is very similar
<S3RK>
Murch1: I don't follow, how this is relevant?
<sipa>
I don't think it's crazy to have a way to explicity rotate a wallet, which would involve re-generating all descriptor keys, possibly move all coins over, possibly make sends to the old ones automatically trigger a transfer, and then force a new backup.
<sipa>
But that's a big feature.
<furszy>
but that would periodically reveal all your balance in a large tx
<furszy>
i mean, all your history to everyone
<sipa>
Well, there are many ways the transferring could be done, but indeed - doing it in a privacy-preserving way would complicate it even further.
brunoerg has quit [Ping timeout: 260 seconds]
<furszy>
yeah sure, make smaller changeless sends over time.
<achow101>
just make a bunch of 1 in 1 out txs moving each utxo individually :)
<sipa>
and send them all at the same time? ;)
<provoostenator>
With random delays and fees.
<provoostenator>
And via the new coinjoin implementation :-)
<achow101>
#topic approaches for #22693 (S3RK)
<core-meetingbot>
topic: approaches for #22693 (S3RK)
<S3RK>
yep, so I'm not a huge fan of the current approach and I see another one suggested by furszy and yet another one by achow101
<achow101>
that last commit is extremely bleh
<S3RK>
we already have avoid reuse feature with bool stored in mem within address book
<S3RK>
we can reuse/extend that
<Murch1>
<S3RK> "Murch: I don't follow, how..." <- If you want to prioritize spending the coins in your old wallet, you set the `minConfs` to the time before your new wallet was created
<S3RK>
Murch1: got it
<S3RK>
or we can track use script as achow101 suggested
<furszy>
have to admit that I don't remember what I commented there. Guess that I said to reuse the value that we are already storing in the addressbook
<achow101>
S3RK: I generally don't like shoving these things into the address book since that ends up being displayed to the user
<S3RK>
right, that's the part I don't like about current implementation. but allow me a stupid question first to help guide my thinking
brunoerg has joined #bitcoin-core-dev
<S3RK>
what do we want to actually achieve with this PR?
<S3RK>
maybe that's wrong timing because we need to ask Luke
AaronvanW has joined #bitcoin-core-dev
<S3RK>
to my best understanding we want a warning when the address we _send to_ has been used already. Is that correct?
BitcoinCharlie has quit [Ping timeout: 248 seconds]
<achow101>
I think it's useful in some cases
<achow101>
e.g. it can remind the sender to double check that the address is up to date
<S3RK>
hm.. ok. So the address in question has nothing to do with the wallet, in that case it's indeed seems weird to store the info in the address book
<achow101>
there are some services which give out new addresses and stop watching txs to old ones (or are unable to credit the payers to old addresses), so it could remind the sender that they should check the address is correct
<S3RK>
got it, thanks
<furszy>
well, the addressbook contains "send" addresses.
<S3RK>
but IIUC the warning should happen regardless of whether we spent to this address before or somebody else
<S3RK>
or not?
<achow101>
furszy: those are the explicit destinations. this would include the other addresses in our own incoming too, i.e. the previous sender's change
<achow101>
S3RK: probably, but that's a lot of storage
<achow101>
i think ideally it would check against every output in the blockchain, but that's a lot of data
<S3RK>
yes, does any of the node indexes cover that?
<achow101>
no
<furszy>
so, seeking to make chain addresses index?
brunoerg has quit [Ping timeout: 246 seconds]
<furszy>
if that is the goal, it doesn't sounds to be something that should be placed in the wallet
<S3RK>
yep, that's my thinking at the moment
<S3RK>
unless we want to restrict the search space to only wallet txs, but then I'm not if that satisfies the requirements
<achow101>
I think that's something to ask luke in the pr
brunoerg has joined #bitcoin-core-dev
<furszy>
yeah, I thought that was restricted to already used destinations only
<gribble>
https://github.com/bitcoin/bitcoin/issues/25634 | wallet, tests: Expand and test when the blank wallet flag should be un/set by achow101 · Pull Request #25634 · bitcoin/bitcoin · GitHub
<achow101>
S3RK: use #proposedwalletmeetingtopic so the topic list gets updated
<S3RK>
#proposedwalletmeetingtopic blank wallet flag, how to differentiate blank and newly created wallets
brunoerg has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
halosghost has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 248 seconds]
halosghost has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
SpellChecker_ has quit [Quit: bye]
andrew_mo_ has joined #bitcoin-core-dev
SpellChecker has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
markus3489986934 has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]