<glozow>
If somebody could help get in touch with miners it would be really nice to hear what their plans are and/or what a reasonable timeline could be. It's the biggest missing piece of information for me, but I don't think we can speculate whether/when they'll do something because it's rational or because a Bitcoin Core option makes it easy.
vasild has joined #bitcoin-core-dev
someone235 has joined #bitcoin-core-dev
<real_or_random>
I got a spam email from a project called "Committable"... I assume I'm not the only one because it seems they scraped email addresses from git repos of cryptocurrency projects. I reported them to GitHub support...
<darosior>
glozow: thank you for the summary that's helpful
<glozow>
real_or_random: I got one too
brunoerg has joined #bitcoin-core-dev
<darosior>
real_or_random: got one too. I occasionally got some asking to fill a survey
amovfx_ has joined #bitcoin-core-dev
<real_or_random>
I replied with a GPDR data erasure request but that's probably useless *shrug*. There seems to be some academic researcher behind this, and there's a survey involved but it's obviously not research: "Committable is the next-generation decentralised open-source protocol initiated by University College Oxford Blockchain Research Centre, aiming at establishing an open economy to enable algorithmic software monetisation
<real_or_random>
(e.g., from a commit to the native COMMIT non-fungible token"
<real_or_random>
Anyway, I'm not planning to spend any more time on this. I just wanted to let you know that I already reported it to GitHub (ticket #1846866), in case someone else feels they want to do this.
<darosior>
"Zeroconf really isn't safe; double spends are possible today." -> More than that, double spends are possible today without aggressively connecting all around the network (which is what those businesses supposedly do to "protect" themselves). I suspect it's just that they are not getting attacked (or attempts are really not sophisticated, as with
<darosior>
the Muun recovery tool) and if someone bothered being as aggressive as their are with their "defence" mechanism they'd just be able to double spend them.
<darosior>
"businesses are using precautions such as requiring high feerates and waiting to detect raced conflicting transactions in other (sometimes many) mempools" -> Have they even stated what "protection" they are using? It seems a lot of the arguments are based on the existence of some solutions that would be very effective today and full-RBF would
<darosior>
"Peter Todd reports that he has observed replacements of non-signaling transactions using opentimestamps" -> If this can add weight, i've been reported that at least part of the hashrate has been accepting non-signaling replacements for more than a year (since non-signaling replacements do get mined eventually). And that a very active (>1M
<darosior>
break. I don't think we should take that for granted, who says their solution isn't broken today? To consider these arguments we should probably start by examining the viability of these solutions..
<darosior>
transactions passed through it) and long-running Electrum server has been running with a non-signaling replacement patch for a long time. Users of this server were able to replace non-signaling transactions and get them mined with very low effort (not necessary to spam the network at all, just broadcast through the server and wait for a bit).
AaronvanW has quit [Remote host closed the connection]
gnaf has quit [Quit: Konversation terminated!]
amovfx_ has joined #bitcoin-core-dev
NorrinRadd has quit [Ping timeout: 240 seconds]
amovfx has quit [Ping timeout: 250 seconds]
AaronvanW has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
<glozow>
darosior: do you have links to observations/reports of these non-signaling replacements maybe? it would be useful to add them.
amovfx has joined #bitcoin-core-dev
<glozow>
e.g. who is the electrum server?
ullbeking_ has quit [Quit: Connection closed for inactivity]
amovfx has quit [Ping timeout: 240 seconds]
NorrinRadd has joined #bitcoin-core-dev
<darosior>
I'm not sure they'd be willing that i disclose that
<glozow>
yeah fair enough. I just don't really want to put in the doc "somebody told me that somebody said this" if that makes sense
<darosior>
I understand
gnaf has joined #bitcoin-core-dev
gnaf has quit [Read error: Connection reset by peer]
amovfx has joined #bitcoin-core-dev
gnaf has joined #bitcoin-core-dev
gnaf has quit [Client Quit]
<instagibbs>
darosior, if you could run your own tests without doxxing it, that would be more reportable?
amovfx has quit [Remote host closed the connection]
amovfx has joined #bitcoin-core-dev
amovfx_ has quit [Ping timeout: 240 seconds]
amovfx has quit [Ping timeout: 240 seconds]
<ariard>
glozow: thanks for the full RBF sum up! "The last position seems to be very rare." afaik John Carvalho is the only vocal opponent, I wonder if there are folks/entities from 2015-2017 opposing at that time who are still vocal against it
<ariard>
"Why we should actively move towards Full RBF" it's a low cost trick to partition network mempools, which might lead to leak transaction-relay bandwidth bleeding things
<ariard>
"LN attacks are also uncommon in practice.
<ariard>
"Businesses are also typically protected legally from users double-spending them." Most of services might also require some form of KYC/pseudonymous identities
<ariard>
"Why we should keep the -mempoolfullrbf" One more pro argument, we have some services operators using it like OTS/some Electrum servers backend; even if they're unlikely to achieve the propgation goals with high efficiency, from my perspectivre they should be free to vote with their economic traffic