<bytes1440000>
1. Taproot improves privacy if its used more and 2of2 looks same as single sig. This pull request makes it difficult to achieve that level of adoption. Does this pull request really improve privacy?
ZeroMaster has joined #bitcoin-core-dev
<bytes1440000>
2. achow101 mentioned that there is plenty of time until 23.0 to change it, and changing the order of preferences would not be particularly difficult. Is it already done?
<bytes1440000>
3. Is it possible to enable/disable this in settings? Some users may want to completely avoid change in a transaction instead of using similar addresses
<bytes1440000>
4. Jeremy Rubin made a good point in this comment: https://github.com/bitcoin/bitcoin/pull/23789#issuecomment-998303608 And the observability of this pattern (change matching) is also... pretty observable, especially if bitcoin core (and only upgraded wallets) are the ones doing it.”
ZeroMaster has quit [Read error: Connection reset by peer]
<achow101>
bytes1440000: 1. Given that taproot has not been widely adopted yet, there is still a marginal privacy gain from matching change types. 2. the order was not changed. 3. Users can force a particular change type using -changetype.
ZeroMaster has joined #bitcoin-core-dev
<achow101>
there's also ongoing work and discussion on changing the automatic change type to be smarter and consider input types as well
<bytes1440000>
achow101: thanks
bytes1440000 has quit [Quit: Client closed]
Talkless has quit [Quit: Konversation terminated!]
ZeroMaster has quit [Read error: Connection reset by peer]
ZeroMaster has joined #bitcoin-core-dev
ZeroMaster has quit [Read error: Connection reset by peer]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
ZeroMaster has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
<luke-jr>
master GUI appears to segfault if it gets an unsupported wallet format :/
ZeroMaster has quit [Read error: Connection reset by peer]
<fjahr>
bytes1440000: Sorry but this is off topic here, this channel isn't discussing Lightning Network development.
bytes1440000 has joined #bitcoin-core-dev
z9z0b3t1_ has joined #bitcoin-core-dev
<bytes1440000>
fjahr: I understand this channel is used for bitcoin core which is used by majority of bitcoin nodes. Sorry if it was off topic although context was taproot, above messages related to 2of2 multisig and PR #23789
<bytes1440000>
luke-jr: there was a tweet recently about other implementations and I noticed knots usage has spiked 6x in last few months. Were there any special features any added in last knots release or is it some new projects that have only recently begun to use alternative implementations?
<fjahr>
bytes1440000: Sure, I was only talking about the niftynei post. It doesn't seem to hint at issues with Taproot itself but rather its use in LN and potential false promises around that. That's why I think most people here would prefer this conversation happening in a different channel :)
brunoerg has quit [Ping timeout: 248 seconds]
bytes1440000 has joined #bitcoin-core-dev
<bytes1440000>
fjahr:iiuc most of the people use 20f2 or 2of3 mutlsig in bitcoin based on https://mempool.observer/monitor/ and 2of2 is mostly used for lightning
<bytes1440000>
so my point is not off topic for this channel when discussing pull request
<luke-jr>
bytes1440000: most recent thing with Knots was the 21.x LTS branch, which I plan to maintain longer than Core's - so maybe look at what version people are using?
<luke-jr>
that being said, I don't see any notable increase in my more accurate node counting, so maybe existing users just got their nodes publicly reachable
<fjahr>
bytes1440000: Sorry, I still think it's off-topic because I don't see how the comment is related to the PR. They both broadly touch privacy and Taproot but in very different context afaict. Let's just agree to disagree move on :)
<bytes1440000>
luke-jr: hmmm interesting.. coin.dance doesnt have those details about implementations. I can try but you know better how to look at p2p network. I think you already had a website? Your assumption about reachable nodes is possible and maybe something else but still could not see any such thing on other implementations so your efforts are
<luke-jr>
bytes1440000: if you scroll down, it has individual versions
<luke-jr>
but this is kinda off-topic here, maybe better to discuss in #bitcoin
<bytes1440000>
fjahr: taproot, 2of2 multisig and privacy is all about lightning IMO. If we use such rules maybe no mempool policies should be adjusted because of a 2of2 multisig network? Or We have better examples of projects that use NofN multisig after taproot?
TheCharlatan has quit [Read error: Connection reset by peer]
<bytes1440000>
luke-jr: thanks
bytes1440000 has quit [Quit: Client closed]
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
TallTim_ has joined #bitcoin-core-dev
TallTim has quit [Ping timeout: 240 seconds]
bomb-on has quit [Quit: aллилѹіа!]
djb27_ has quit [Ping timeout: 252 seconds]
<fjahr>
bytes1440000: DLCs and Atomic Swaps come to mind instantly for just 2of2. But taproot helps with almost any collaborative multisig protocol. what does the mempool have to do with this now? That topic isn't named in the PR or the link once.
<bytes1440000>
What does that have to do with mempool? Maybe you can read the pull requests that are open in bitcoin core repository related to mempool and discuss lightning
bytes1440000 has quit [Quit: Client closed]
Evel-Knievel has quit [Ping timeout: 240 seconds]
bytes1440000 has joined #bitcoin-core-dev
<bytes1440000>
Shared this with adam back and lot of others feel only consensus critical code can be exploited. I believe some developers in core understand this is not true but I am not sure if they will ever talk about it.
<bytes1440000>
Bitcoin Core or any bitcoin implementation has lot of things that can be exploited with no soft fork. It can be p2p, mempool wallet, rpc etc. anything
<bytes1440000>
This is not FUD but something a user should be aware of.
<luke-jr>
bytes1440000: while exploits might be in non-consensus code, I'm not sure purely privacy issues like you seem to be talking about are an exploit
<luke-jr>
bytes1440000: but more importantly, do you have a proposal to fix it?
brunoerg has quit [Ping timeout: 248 seconds]
<bytes1440000>
luke-jr: This is different from privacy issue. It was in a CTV chat where adam back said, non-consensus PRs are reviewed by a lot people line by line and will never end up being a wrong thing and merged. This is about SECURITY. Proposal to fix it? Its not possible with core used by 99% nodes. Either we use different implementations with a consensus
<bytes1440000>
library or trust maintainers and DNS seeds.
<luke-jr>
bytes1440000: so what's the actual security issue? maybe email security@bitcoincore.org rather than IRC if it's exploitable…