-
Alex|LocalMonero
Any native Vietnamese speakers here?
-
Alex|LocalMonero
<Torr> "Switching to Semver is a big..." <- We're already on semver. Semver accounts for the v0.x.x usecase
semver.org/#spec-item-4 `Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.`
-
Alex|LocalMonero
v1 implies that with seraphis the API will stabilize. It most likely won't.
-
-
Alex|LocalMonero
pyromaniaco[m]: Do you have TG?
-
pyromaniaco[m]
sorry for not answering you, I can't see the messages
-
pyromaniaco[m]
Alex|LocalMonero: yep
-
Alex|LocalMonero
pyromaniaco[m]: I can see your messages, PM it to me.
-
pyromaniaco[m]
t.me/pyromaniaco
-
GorillaQuest[m]
Hello
-
DanIsnotthemanBr
Hi Seth
-
Torr
-
Torr
Alex|LocalMonero: Semver only has 3 core fields, i.e., 2 dots.
-
Torr
Alex|LocalMonero: Realse data has to be appended with a dash or plus.
-
Alex|LocalMonero
Oh yeah, I forgot that we use 3 dots.
-
Alex|LocalMonero
My mistake.
-
Torr
This "v0.18.2.0", is not Semver.
-
Alex|LocalMonero
Still, I'd prefer if we stayed on v0 until we at least get rid of the major pain points for mass adoption, like the 10-block-lock.
-
Alex|LocalMonero
Announcing version v1 without the 10-block-lock eliminated would be rather premature, I feel.
-
Torr
Indeed, there are some big things cooking.
-
Torr
Depending on how long they take to come out, it may not be too much of a deal.
-
Torr
There will be big changes in the near future regardless of Seraphis, just for the nature and age of crypto in general.
-
Alex|LocalMonero
On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies
-
Alex|LocalMonero
“For instance, our analysis reveals that in the widely deployed Lightning Network, with 1% strategically chosen colluding nodes, the adversary can uniquely determine the originator for ≈ 50% of the total transactions in the network. In Dandelion, an adversary that controls 15% of the nodes has, on average, uncertainty among only 8 possible originators. Moreover, we observe that due to the way Dandelion and Dandelion++ are
-
Alex|LocalMonero
designed, increasing the network size does not correspond to an increase in the anonymity set of potential originators. Alarmingly, our longitudinal analysis of the Lightning Network reveals rather an inverse trend—with the growth of the network, the overall anonymity decreases.”
-
Alex|LocalMonero
-
Alex|LocalMonero
> <@alex:agoradesk.com> On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies... (full message at <
libera.ems.host/_matrix/media/v3/do…099087798f89d528f7d17dca2b4497fde40>)
-
Torr
2nd layer "privacy" for ya
-
Torr
Heading off now
-
Torr
'til later
-
xmrfn[m]
You may wish to set some specific goals and get a known payout for the work, if you like:
repo.getmonero.org/monero-project/ccs-proposals
-
xmrfn[m]
s/repo/ccs/
-
xmrfn[m]
I'd love to see the wallet pick a random available node from
monero.fail/?onion=true and use it to broadcast
-
xmrfn[m]
(I just wish there were an .onion for monero.fail ; if there is, it isn't noted in the HTTP reponse)
-
politicalweasel[
Alex | LocalMonero | AgoraDesk: Dandelion++ does better: "Dandelion and Dandelion++ provide a low median entropy of 3 and 5 bit, respectively, when 20% of the nodes are adversarial." But yeah it's still not great
-
politicalweasel[
32 originators instead of 8
-
Alex|LocalMonero
politicalweasel[: I would guess that once you've narrowed things down to 32 nodes it's very easy to narrow down further based on other metadata that you might possess.
-
Alex|LocalMonero
Tor/i2p is aggressively censored in some regions, so for those regions a fallback to clearnet with dandelion would be OK.
-
Alex|LocalMonero
* Didn't expect the number to be so bad with dandelion. Perhaps natively integrating Tor/I2P for tx broadcasting is the preferable way to go. It certainly results in much faster tx propagation.
-
politicalweasel[
Do you mean only use dandelion(++) when anon networks aren't available, or preferably use both but drop Tor if necessary?
-
politicalweasel[
because the first wouldn't be possible without attaching extra metadata about where the tx was broadcasted from
-
politicalweasel[
agreed that Tor/I2P should be used by default though regardless of the propagation system
-
xmrfn[m]
> wouldn't be possible without attaching extra metadata about where the tx was broadcasted from
-
xmrfn[m]
I don't think that's the case. Check for Tor/I2p connectivity, if not found use D++. The actual txn broadcast is the same no matter what network envelope it's sent in
-
politicalweasel[
what happens at the next node, though? The first node could check for Tor but then what?
-
xmrfn[m]
Oh, I was thinking client check. I mean, once the node gets it, it needs to know if it's D++ and if so possibly forward. But if a txn comes in over an anonymity network, its source is already obfuscated, right? Just process it
-
xmrfn[m]
* thinking client (wallet) check. I
-
xmrfn[m]
* thinking client (wallet) check. I, * process it (broadcast, "fluff phase" right away)
-
politicalweasel[
yeah that's the metadata I was talking about. For the network to dynamically switch between D++ and "fast" propagation, the txn would need to have a flag attached to tell nodes which protocol to use
-
xmrfn[m]
The only metadata that's leaked is that whoever did the txn, they were on <i2p/tor> and picking this .onion service node to broadcast to
-
xmrfn[m]
I would think any txn that comes over anonymity wants "fast". Its source is already obfuscated.
-
Alex|LocalMonero
politicalweasel[: AFAIK there's no way for a node to tell if it received a tx as a result of a d++ fluff or just a straight up broadcast
-
Alex|LocalMonero
But for sending yeah the node would need to support both modes, as it does now because you can broadcast on tor/i2p without d++
-
xmrfn[m]
Right D++ for clearnet only. If we get a txn over Tor, it's like the "stem" phase is done by the Tor network; we just broadcast. No "mode" necessary.
-
xmrfn[m]
* just broadcast/fast mode. No
-
Alex|LocalMonero
Right
-
xmrfn[m]
The wallet client needs to know an .onion node to connect to, which is why I mentioned monero.fail
-
xmrfn[m]
There are dozens of community-run open .onion nodes it's quite beautiful actually
-
politicalweasel[
xmrfn: That extra metadata should still be avoided. It gives attackers more information to work with. Plus the idea that Tor txns "want" fast propagation might not always be right. If anything Tor/I2P should be standardized and D++ could be modified to more aggressively "fluff" to reduce propagation times
-
politicalweasel[
Alex|LocalMonero: Not right now, sure. But that could be changed easily
-
politicalweasel[
(which is not what I want, to be clear)
-
xmrfn[m]
What metadata? That someone somewhere picked this node? That's like knowing that "someone somewhere" used Silk Road. As long as different clients don't pick specific nodes, there's really nothing leaked
-
xmrfn[m]
(ie, if everytime node "X" broadcasts, it means MyDumbWallet.exe did the txn)
-
politicalweasel[
Knowing the node would be even worse, I was just thinking a flag to tell whether it was broadcasted via Tor or not. Either way that information is still attached to the transaction. If it really were "some transaction somewhere was broadcasted via Tor" then yeah that wouldn't be a big deal
-
politicalweasel[
but that's not the case
-
xmrfn[m]
The information about what network transport was used isn't really attached to the txn. It certainly never makes it into the blockchain.
-
politicalweasel[
Then how do nodes know which mode to use? And yeah it doesn't make it on-chain but this whole conversation is about propagation-time attacks so that's not really the point
-
xmrfn[m]
A malicious node could keep track of what IP addresses if got txns from and report them all to the FBICIAGAFAM. But that's why we use Tor/I2P -- the IP address won't tell them anything useful.
-
xmrfn[m]
Oh... propagation-time attacks. Hm. Well there's always adding a random delay, quite apart from D++. I'm pretty sure we don't do that now.
-
xmrfn[m]
I don't think of D++ as being primarily intended to obfuscate the time a txn was broadcast, but rather the IP address (and therefore potential geographic location). D++ stem phase is just a few network hops, a few seconds of "fuzzing" at most.
-
xmrfn[m]
s/could/_could_/, s/if/it/
-
politicalweasel[
Yes, D++ is intended to obscure where a txn came from. I'm pretty sure preventing basic timing fingerprinting is hopeless unless you're willing to wait days before your txn is confirmed. It's more than just a "few" seconds, IIRC. Transactions sometimes take a little while to appear in a wallet. Ideally we could get reliable network-wide broadcasting within a couple seconds
-
politicalweasel[
0-conf is quite slow right now, relatively speaking
-
Alex|LocalMonero
<politicalweasel[> "0-conf is quite slow right now..." <- Try switching your broadcaster node to tor mode with d++ disabled. Tx propagation will be as fast as the pre-d++ days, it's awesome.
-
xmrfn[m]
> preventing basic timing fingerprinting is hopeless unless you're willing to wait days before your txn is confirmed.
-
xmrfn[m]
I'm not sure. There are ~17k tx/day which comes down to 1 txn per ~5 sec. So adding a random delay up to (say) 20 seconds would potentially add value.
-
DanIsnotthemanBr
-
Ponyeatitall[m]
.xmr
-
Wallet
Ponyeatitall[m]: You must have bot account & be logged in
-
xmrlover[m]
<DanIsnotthemanBr> "
nitter.net/stack_wallet..." <- Wierdly enough i use both elite wallet and stack wallet
-
bridgerton[m]
<᷾s> bridge down?
-
bridgerton[m]
<᷾s> last message was at 6:56 am utc
-
bridgerton[m]
s/was/is/
-
charuto
it's not down
-
anarkiocrypto[m]
Kuno Fundraisers beta is live now:
kuno.bitejo.com Will release the source code (as well as Bitejo's source code) soon. The source code is messy but functional.
-
bridgerton[m]
<salami donators!> Like waas but without hosting it yourself
-
anonimauzanto[m]
Are there any updates on when 0.18.2.1 will be released?
-
Alex|LocalMonero
-
xmrack[m]
Alex | LocalMonero | AgoraDesk: matrix is messed up and can’t decrypt the PM you sent me. Can you try again
-
Alex|LocalMonero
xmrack[m]: done
-
xmrack[m]
Still broken. I had this issue with Ruck a while back, are your clients up to date?
-
Alex|LocalMonero
yup
-
Alex|LocalMonero
Hold on, let me try something.
-
xmrack[m]
Okay
-
ceetee[m]
<anarkiocrypto[m]> "Kuno Fundraisers beta is live..." <- Is bitejo.com also created and run by you?
-
anarkiocrypto[m]
Yes, will release Bitejo's source code after Kuno.
-
modul8[m]
<anarkiocrypto[m]> "Kuno Fundraisers beta is live..." <- Exciting. All the info at the bottom is great for new people.
-
anarkiocrypto[m]
Here is the code:
codeberg.org/Anarkio/kuno I apologize that it's messy, amateur-level and not fully tested. Hopefully some of it may be useful. The source code for Bitejo will hopefully be published tomorrow.
-
bridgerton[m]
<Bon 💗> Thanks thats a w