-
br-m
-
br-m
<ollerhahayes:matrix.org> is this file safe to download to buy xmr
-
br-m
-
br-m
<ofrnxmr:xmr.mx> @banhammer:matrix.org
-
br-m
<rottenwheel:unredacted.org> Totes safe.
-
br-m
<rottenwheel:unredacted.org> Downloading and running right now.
-
br-m
<siren:kernal.eu> such a shame i can't download it
-
br-m
<siren:kernal.eu> love analyzing random goop found in the wild
-
br-m
<eddie:oblak.be> What is the local development network for monero, stagenet?
-
br-m
<eddie:oblak.be> Oh, it seems to be testnet..
-
br-m
<rbrunner7> @eddie:oblak.be: It depends. stagenet is kept functionally identical to mainnet. testnet is (sometimes) the bleeding edge. testnet will hardfork to FMCP++ and Carrot first, for example.
-
br-m
<eddie:oblak.be> I need something equivalent to bitcoins regtest, seems a private testnet is the way to go (
github.com/moneroexamples/private-testnet) ?
-
br-m
<rbrunner7> Yeah, you can span up a private Monero network anytime, following that tutorial. What code will run on that will of course depend on the version of the daemon you use.
-
br-m
<eddie:oblak.be> yeah, I just run a clone of my node but in --testnet mode then
-
br-m
<rbrunner7> Well, don't want to confuse you, but the real magic of a private network is not activated through that --testnet startup parameter, but through --add-exclusive-node.
-
br-m
<eddie:oblak.be> oh, ok, thanks , I didn't read that far yet
-
br-m
<eddie:oblak.be> oh, but wait, I need to run at 2 or 3 nodes?
-
br-m
<eddie:oblak.be> I thought I could just ignore that part 😛
-
br-m
<rbrunner7> Again, depends on what you want to test. You could start a single daemon with --offline for example, to prevent that it connects to any peers.
-
br-m
<ofrnxmr:xmr.mx> egtest > <@eddie:oblak.be> I need something equivalent to bitcoins regtest, seems a private testnet is the way to go (
github.com/moneroexamples/private-testnet) ?
-
br-m
<ofrnxmr:xmr.mx> regtest
-
br-m
<eddie:oblak.be> so there's also a monero regtest?
-
br-m
<ofrnxmr:xmr.mx> just run --regtest and --offline, or multiple --regtest with --add-exclusive-node
-
br-m
<ofrnxmr:xmr.mx> yes
-
br-m
<ofrnxmr:xmr.mx> you can use --keep-fakechain to not delete the chain at startup (.. or shutdown, i dont remember which)
-
br-m
<eddie:oblak.be> ok, thanks. I was looking here, it doesn't mention it:
docs.getmonero.org/infrastructure/networks
-
br-m
<ofrnxmr:xmr.mx> ./monerod --regtest --keep-fakechain --offline then connect wallet with ./monero-wallet-{rpc|cli} --allow-mismatched-daemon ... <other flags>
-
br-m
<ofrnxmr:xmr.mx> if you need to mine blocks quickll, add --fixed-difficulty=1 to moenrod
-
br-m
<ofrnxmr:xmr.mx> regtest uses the current hardfork right away. the problem with private testnet, is that it does not
-
br-m
<eddie:oblak.be> hmm, I have the node running, created a wallet on the node, it connected to the daemon. But when I run "start_mining" it returns "Error: mining has NOT been started: possibly lost connection to daemon" . Any ideas?
-
br-m
<ofrnxmr> Did you starr the node with --offline
-
br-m
<ofrnxmr> It needs to be offline or needs to have peers, one or the other. Offline is easiest
-
br-m
<eddie:oblak.be> @ofrnxmr: yes
-
br-m
<eddie:oblak.be> ah the wallet type is mainnet
-
br-m
<eddie:oblak.be> while connected to regtest daemon, could that be the issue?
-
br-m
<eddie:oblak.be> I tried starting the wallet-cli with --regtest, but it seems this flag doesn't exit there
-
br-m
<eddie:oblak.be> ok, I think the issue was that I started the node with restricted-rpc
-
br-m
<ofrnxmr> Definitely
-
br-m
<ofrnxmr> the node does the mining. You cant tell it to mine over restricted rpc
-
br-m
<ofrnxmr> @eddie:oblak.be: Yeah, the wallet is mainnet type. You just need --allow-mismatched-daemon
-
br-m
<atori_0xbdc3ab4e:matrix.org> I'm looking into FCMP++ and as far as I understand we will have forward secrecy from a quantum computer, but only for the sending side, is this correct?
-
br-m
<atori_0xbdc3ab4e:matrix.org> If somebody has your address and a quantum computer they can still scan the blockchain and see which transactions were received to it, correct?
-
br-m
<atori_0xbdc3ab4e:matrix.org> And the amounts being send are also still viewable with a quantum computer?
-
DataHoarder
being able to see received inputs allows decrypting amounts
-
DataHoarder
" If somebody has your address" < that's for legacy ones
-
DataHoarder
new carrot native ones also get internal forward secrecy
-
DataHoarder
this includes change outputs
-
DataHoarder
forward secrecy is address-conditional, that's said, as long as that specific address is unknown for that output
-
DataHoarder
(for the receiver)
-
DataHoarder
-
DataHoarder
that said this is an addressing scheme that is compatible with the address formats. Jamtis would exist in the future and that's the reason why view tags are 3 bytes long, plus a few more specific values, to support this possibility in the future
gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832
-
DataHoarder
"Most importantly, the new format allows for post-quantum forward secret transactions that can't be decrypted even if the address is publicly known and the elliptic curve discrete logarithm (ECDLP) is broken."
-
DataHoarder
one of the stated additional goals is to be "Backward compatiblity with Carrot without hard forking changes."
-
DataHoarder
FCMP++ tbh comes with a few things, mainly SAL + full chain membership proof, but Carrot is on the side in a way that can allow Jamtis to exist without an upgrade (besides on the sender/receiver side clients)
-
DataHoarder
it's FCMP++ and Carrot (with tx output format compatible with Jamtis as known so far)
-
br-m
<atori_0xbdc3ab4e:matrix.org> forward secrecy is address-conditional, that's said, as long as that specific address is unknown for that output
-
br-m
<atori_0xbdc3ab4e:matrix.org> >> what do you mean by that?
-
br-m
<atori_0xbdc3ab4e:matrix.org> Another thing,
-
br-m
<atori_0xbdc3ab4e:matrix.org> I recently saw Seth mention on Monero Talk that because the tail emission is fixed and the inflation rate asymptotically approaches 0, eventually it will no longer be enough to secure the network.
-
br-m
<atori_0xbdc3ab4e:matrix.org> Does this make sense?[... more lines follow, see
mrelay.p2pool.observer/e/_5f1h6ELalZFNGdH ]
-
nioc
we have no idea what size tail emission is needed. It was not known when it was selected.
-
nioc
obv zero is too small :P
-
br-m
<atori_0xbdc3ab4e:matrix.org> Well if it's a percentage that changes the calculation entirely no? And if 1% is not enough to secure the network, well fuck