Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 819. (Read 4670673 times)

Thanks for doing this. I tried installing (as I want to make some "paper" wallets, so to speak) but I get a fair amount of warnings.

Not to be critical, but I just can't imagine non computer people going through all the steps. Haven't been here much for months, any word on the GUI wallet, in the sense of just clicking a .dmg file and having it point and click? I mean I can use Electrum for BTC, My Monero online, but I really think not having an easier to use wallet is just hurting things. Hard for many of you to understand this I think as you are computer experts, but seeing warnings flash by the screen and such, just doesn't seem user friendly.

I don't have to download the blockchain to just create a wallet right? (I just want to make a paper wallet and will import to MyMonero or a more friendly wallet when I want to cash out.)

Thanks in advance,
IAS

It does that by default. In fact it even works behind NAT, if you relay the port (18080). If the NAT supports UPNP the relay could theoretically happen automatically but I've never seen that work (I guess my routers don't support UPNP or it is turned off).

The instructions are not outdated. If you want bitmonerod to accept incoming P2P connections (and hence help the network), you should point it to your internet-facing IP address. It's good practice to explicitely bind it to that IP address only and avoid it binding to all interfaces, as it does by default I believe.

Feel free to ignore this if you just want to run a wallet though, or running a node behind NAT.

Good point.

Being a programmer I have thought about what use cases in the real world Ethereum would be good for...

I haven't really came up with anything yet as I do find the platform far too limiting. I figure I just wasn't smart enough! Apparently the founder of Ethereum is meant to be a genius so there may be real world use cases that I just can't think of?

http://thehackernews.com/2015/08/quantum-computing-encryption.html

Best response ever.

He's but at the moment less than some times in the past.

The thing is we are all part time with various other demands on our time so each team member's activity level varies over time.

Take NoodleDoodle for example. He did the critical early work to optimizing (or de-unoptimizing and de-obfuscating if you want to call it that) the proof-of-work last year and you didn't hear much from him for a while, although he was still somewhat active behind the scenes. Then recently he did a huge amount of work to fix and optimize the database code. It's pretty much the same for every single one of us.

Yosemite (10.10.4).
Another tiny bug is that typing help in bitmonerod sometimes causes it to hang. (Help works fine in simplewallet, though).
Overall very impressed with the improvements.

I am not understanding any of this stuff But great to see he's still active!

So 2am is taco time?

Hm, I seem to remember having some hiccups like that too but I forgot about them because they eventually just disappeared without me doing anything (knowingly) to correct the issue.


What version of OSX?

At 2am today (my time)  -


[01:53:09] https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-5.6
[01:53:36] there's a step where you get r from SHA-512(prefix || M)
[01:54:10] where prefix is SHA-512(secret)[32:64]
[01:57:48] (the first half of the prefix is used to generate the scalar to use as a private key)
[01:58:08] my question is, can't prefix be anything and the won't the signature still be valid if it is?
[01:58:21] and is there any reason that doing this would be dangerous?
[01:59:27] i realize that if you use a bad value it might be like choosing a bad K in general
[01:59:38] but if your value is securely chosen, is it safe?
[02:34:26] and also
[02:34:26] is it possible to construct hd keychains from ed25519 private scalars? i don't really thing it is because there are four required bits that need to be set for an ed25519 scalar to be valid in terms of generating a signature
[02:34:26] i kinda wonder if there's a way around that though
[02:34:29] normally for an hd keychain you += hash(pubkey || index) to both the private scalar and public point
[02:35:38] so to get priv_i and pub_i
[02:36:06] priv_i = (priv + hash) mod N
[02:37:17] pub_i = (pub + scalarbasemult(hash))
[02:38:16] and how come monero doesn't run into this issue when it generates private keys through ecdh? does monero allow these scalars to be legal with the bits set anyway?
[02:38:37] because you'd expect 1 in every 2^4 scalars for any given derived keypair to be invalid
[02:38:42] but i'm probably missing something
[02:59:03] okay i figured out the zeroing out of the 3 lsbs
[02:59:12] that's just *= the cofactor
[02:59:29] but you do need one bit to be set in the private key for it to be useable, right??
[03:00:22] so when you ecdh a corresponding secret to the recipient, how can you tell with 100% certainty that the private key they will derive has a single set bit in the 254th position??

I would appreciate an answer to this as well.

Not sure if this is the right place to report this, but have compiled the new version of bitmonerod on a mac and converted the blockchain using blockchain_converter.

The problem is I have to run bitmonerod twice (exiting the first run with ^C ^C) in order for it to work. The first run after opening a new Terminal window always hangs, displaying two libunbound error messages during startup: http://pastebin.com/WPQqaRG6.

Oddly, the second run sometimes has one libunbound error message and sometimes none, but it works (as long as there are not two).

And then a hundred "monero" is a "bitMonero" ... oh wait.

re: IP address, pretty sure thats your internal IP address, being assigned by your router. If you've got a straight feed to the interwebs, then its probably not useful. I have no idea why those instructions are there, but the useful case I've found for them is if you have a motherboard with two ethernet ports, you can channel your daemon through one of these ports and channel your other stuff (for instance SSH) through the other. No idea if that actually enhances performance in any way, but thats what I imagine its for.

but again, that does seem like an edge case. And I'm no network wizard.

It is still relevant - 1.54 chokes, and we're already well past that in terms of Boost versions, so no need to touch 1.54

I'm fairly certain the bug was with 1.54, which happened to be the one in the standard Ubuntu 14.04 repository.

Ok, I did a bit of searching: from the first page of this thread, we find: https://bitcointalksearch.org/topic/m.6382457 which links here: http://goo.gl/RrCFmA

This was quite some time ago, so I don't know if it's still relevant.

welcome! glad to have you here.
post your address, i send you some. you can just send them back to the adress they came from if you dont want to keep them

if i manage to run it you sure do too!

Thanks. So onward to next potential problem:

sudo apt-get install git gcc-4.9 cmake libunbound2 libevent-2.0-5 libgtest-dev libboost1.55-all-dev libevent-dev

Why boost 1.55 ?

(I am on Ubuntu 14.04 with libboost-all-dev (notice lack of insistence on a particular version) installed.)

I vaguely recall something I was thinking of trying wanted that version, not sure if it was Monero or some other thing. But normally this version of Ubuntu, and all the coins I have built so far (and I have built lots of them) are still back on an earlier version of boost, maybe 1.54 or somesuch.

Whatever it was that I previously ran into that wanted 1.55 I did not bother with, I think maybe I also ran into some warning somewhere not to.

What happens to all my normal builds if I install this new boost? Will they get compiled against it and maybe break?

Its possible one of them even specifically warned me not to go to 1.55, I can't recall quite what it was that led to me not bothering with whatever it was I saw before that was wanting to use boost 1.55.

I can't even recall if there was supposed to be a bug in 1.54 that necessitated using 1.55, or a bug in 1.55 that necessitated not moving forward to that version yet, or both.

Though everythign so far seems to be working normally while I have NOT gone ahead to this newfangled 1.55 thing...

-MarkM-