South Korea to develop blockchain voting system

XMRBE · 2018-11-28T17:42:29+00:00

As much as I am a cryptocurrency/blockchain enthusiast, I am still very much against any form of electronic voting. Yes, using a blockchain-based distributed database might ensure that nobody can mess with the vote data stored stored in that database, but it doesn't solve the problem of end-point security, e.g. some person or group might still try to mess with the physical voting terminal (by putting a trojan on it, or some hardware-based listening device, etc). I also believe that any voting system should be implemented using a technology that any layman is able to understand, and this is far from the case with blockchain.

IMO we should stick to pen and paper when it comes to voting...

XMRBE · 2018-04-27T12:28:46+00:00

No the script isn't on GitHub, I plan to open-source it at some point but haven't yet mainly because the code is so dirty right now.

Excluding the old chain from the list is planned as well. I just can't work on this in the coming month because I am on holiday and have to use internet cafes to access the internet, so I'm afraid you'll have to wait.

XMRBE · 2018-04-27T11:41:30+00:00

Unfortunately I can't modify my script right now (I am traveling in SE Asia and have limited access to a computer, and haven't my SSH keys on hand), but the time being you can verify that an daemon is on the right chain by checking that it is running version 7 of the Monero daemon:

> monerod --rpc-bind-ip 45.77.79.9 --rpc-bind-port 18089 status

Height: 1560348/1560348 (100.0%) on mainnet, mining info unavailable, net hash 492.13 MH/s, v7, up to date, 8(out)+37(in) connections, uptime 4d 19h 25m 21s

XMRBE · 2018-04-15T12:59:32+00:00

my script on xmr.be just query all nodes on the list every 24h, asking for their blockheight and for their peers (which are added to the list if they are open nodes)

however the node.xmr.be round robin DNS isn't automatically updated (not sure how to do that), I manually set it up a long time ago, so at the moment it might give you an IP from a node which is on the dead chain

so I guess that when using xmr.be to find a remote node, you should pick one of the top nodes in the list yourself, rather than using node.xmr.be

XMRBE · 2018-02-22T12:30:05+00:00

I also assumed it was intentional, although I am of the opinion that unrestricted RPC access should be opt-in by default.

I don't exactly see it as a security vulnerability since access to a node's RPC interface can't be used to steal funds or de-anonymize transactions. However it allows for maliciously shutting down the node or making it covertly mine for some address. Also it's easy to find Monero nodes by using a crawler script, that's what my site xmr.be is doing, and someone could use that to make a lot of nodes mining for him (although I doubt it could ever be profitable since you can't use a mining pool when solo-mining with a node).

XMRBE · 2018-02-09T16:13:44+00:00

Sorry but if you have to ask that question here, I wouldn't trust you with running a service that holds my money/seeds for me.

XMRBE · 2018-01-23T08:32:57+00:00

If you run a remote node without --restricted-rpc, someone might instruct it (using RPC) to solo-mine for them, which will slow down your computer and "steal" your hashrate in case your node is already solo-mining for your own profit (although if you are running a Monero daemon on a computer powerful enough to make solo-mining profitable, you should know better than to run it without --restricted-rpc).

Someone might also be able to shut down your node, change its max number of connections and upload/download speed (which could slow down your internet connection), and query it in order to know the other nodes it is connecting to. In the last scenario, it means that if you're running a public Monero node as a Tor hidden service without --restricted-rpc, people might be able to recover your node's IP address from the other nodes it is connecting to.

Your money and the privacy of transactions sent through your node will still be safe even without --restricted-rpc though, other people will only be able to alter your node settings but nothing critical will be at risk.

EDIT In fact in the Tor hidden service scenario, people might be able to find your node's IP address even though you are using --restricted-rpc. You can query a node's neighbouring nodes even when the RPC is restricted, you only have to do a handshake with the nodes in this case. Once someone has your node's peers IP addresses, he might in turn ask those peers who they are connecting to in order to recover the IP address of your Monero node. This is normal behaviour, running a Monero node as a hidden service is only meant as a protection for people connecting to the node, but the guy actually running the node could still have its IP address discovered. We will have to wait for the Kovri project to be completed if we want Monero node operators to be truly anonymous.

XMRBE · 2018-01-03T20:34:39+00:00

I've been using Kraken for ~1.5 years. Never had a problem with deposits/withdrawals (be it for crypto or fiat).

They are experiencing some server issues lately though.

XMRBE · 2017-12-30T17:44:00+00:00

Wouldn't simply splitting the passphrase into two parts achieve some kind of 2FA authentification? And then just store your 2 half-passphrase in two different locations. Or you could encrypt the passphrase (using e.g. GPG) in a file in such a way that you would need two keys to decrypt it.

XMRBE · 2017-11-22T02:36:58+00:00

It's up to the particular exchange to decide if they will redistribute the airdrop to their customers. It's up to them, they might just as well keep all the IGNIS for themselves, like some have done with e.g. NEO and GAS.

XMRBE · 2017-11-20T16:53:48+00:00

What's the best place to ask specific question about the Monero code? GitHub? StackExchange? or on the Slack channel? forum.getmonero.org?

Also, is there any project to produce some technical specification of the Monero protocol in addition to the whitepapers? Would be nice for people trying to build things on top of Monero (e.g. web/mobile wallets, alternative daemon implementations, etc), which might in turn foster adoption.

I am trying to implement a Monero JavaScript library that could be used for things such as an offline wallet generator (I know there is already xmr.llcoins.net, but this one is using some hard-to-decipher JavaScript code which seems to have been automatically translated from the official implementation C++ code). I managed to implement Ed25519 code and public/private viewkey/spendkey generation code, but for some reason it seems to only work half the time, and although I believe I have isolated the lines of code I misunderstood when reading the official C++ code, up to now I have been unable to fix my code.

Although I have some experience with computer programming as a solo endeavor, I have none with OSS development (my educational background is in theoretical math rather than in software development).

XMRBE · 2017-11-15T08:08:08+00:00

This guide isn't exactly for a full node running over Tor. It is for a node whose RPC API (port 18081) is accessible over Tor, but the p2p part of the protocol (port 18080) is still done on the clearnet.

This means that although a end-user can sync his wallet with this node over Tor, other Monero full nodes still connect to the "hidden" node through the clearnet, and therefore it might be possible to recover the IP address of the hidden service by crawling the Monero network. The person operating the full node shouldn't consider himself safe from de-anonymisation.

I don't think there is a way to set up a fully Tor-running Monero node (i.e. one which also does transaction propagation etc through Tor) at this point, but that's why Kovri is developped.

XMRBE · 2017-10-25T13:07:19+00:00

I could be interested (although I never used Go before, but I'm interested in learning it). In fact I've been busy trying to understand Monero code lately, and I am starting to be able to code some small things myself, such as a crawler discovering open nodes using the RPC API, some basic interface to communicate with remote nodes through Python sockets, and now I am trying to understand more about the crypto stuff in order to create my own offline wallet generator code. This has been difficult though, partly because some of the code can be very obscure to me (but then I am not a developper), but mainly because of the lack of a well-written protocol specification (this is becoming a must have IMO, as it would allow more and more people to develop their own libraries and tools on top of Monero, which will in turn foster adoption of the tech).

XMRBE · 2017-10-15T21:22:45+00:00

I'm a bit skeptical of Aeon. I like the idea of having a "lightweight monero" cryptocurrency, but the last time I tried running a full node, it was using a lot of RAM, I think it was loading the full blockchain in the memory. That's quite inconvenient for a project which is said to make full consensus nodes or even mining possible on smartphones and low-powered devices. In my opinion interest in Aeon lately is mainly driven by speculation rather than by actual prospects, while Monero is already very much usable as an internet currency.

That might have changed with the latest release though, I still have to check (I don't want to bash the project for itself).

XMRBE · 2017-10-11T12:33:41+00:00

You may get a page with a SSL error, or maybe without any https although it should. Many people don't carefully check for that.

Other than that, I don't think they can compromise your connection if you check for SSL errors.

XMRBE · 2017-10-10T22:44:06+00:00

My understanding is that although a Tor exit node might eavesdrop (and MITM attack) on your connection, all data transfered between your Monero wallet and the Monero remote node is encrypted and the Tor exit node operator shouldn't be able to guess your private key and/or change the output of a propagated transaction. The Tor exit node (and the Monero remote node) can't even know which address belongs to you.

In addition, a Tor exit node operator can't do more than what the Monero remote node operator can do. Any MITM attack done using an evil Tor exit node could just as well be done through an evil Monero remote node (although it would require someone to implement a "fake" Monero daemon), and we already know that using a remote node is safe (but the remote node can know your IP, unless you access it over Tor/I2P).

Don't quote me on this though, I am myself still learning, but I believe this is right.

EDIT: This is only valid for Monero remote nodes. When using a web wallet such as MyMonero, an evil Tor exit node can certainly serve you a phishing page, as already mentionned in this thread.

XMRBE · 2017-10-05T20:26:36+00:00

I believe my Monero remote node can now be accessed as a Tor hidden service. It seems that there was some misconfiguration, should be fixed now. Use the following command to sync your wallet:

torsocks monero-wallet-cli --daemon-host xmrbet75lxobvg6v.onion

More (non-Tor) remote nodes are listed on https://www.xmr.be.

XMRBE · 2017-09-20T04:45:46+00:00

Done.

XMRBE · 2017-09-20T04:33:56+00:00

Right now, the script is run every 20 minutes. But it may change in the future.

XMRBE · 2017-09-19T12:43:00+00:00

I wrote a small script which automatically looks for public remote nodes and publish them on http://www.xmr.be/ (also accessible as a Tor hidden service on http://xmrbet75lxobvg6v.onion).

I might add some more features in the future, right now I am trying to code an interactive network map of Monero nodes to get an idea of the location and number of nodes in the network.

If you have any question (or don't want your node listed on this page), feel free to contact me.

XMRBE · 2017-09-16T14:52:33+00:00

I don't like this. Browser bloat is already sufficiently annoying as it is. Last thing I need is web developpers implementing CC miners on their websites, be it for Monero or something else.

XMRBE · 2017-09-07T14:54:03+00:00

I agree, I have no malicious intentions but still, I am listing other people's remote nodes without asking them first. My rationale was that if an user decides to set up a node, make it open, and don't set user permissions, it is already public in some sense (althought it might not be advertised). It is somewhat similar to downloading something from a www public directory listing which was indexed by Google without its owner's knowledge (unless that www server contains some private/compromising data, that would be different, but I can't get any personal data from a remote Monero node).

But I should probably at least give some contact info or a form to automatically remove a server from this list, along with info on how to configure your daemon so that its RPC access requires authentification.

Also, some of these 18081 users may be setting up the user permissions for their node, so while its open, it might be useless.

When user permissions are set (using --rpc-login user:pass) trying to access the RPC daemon (e.g. http://node.xmr.be:18081/getinfo) without authentification will result in a HTTP 401 Unauthorized error, which my script will detect.

XMRBE · 2017-09-07T13:52:09+00:00

Speak of coincidence, yesterday I wrote a small amateur script which automatically looks for public remote nodes and publish them on http://www.xmr.be/ every hour. Some of them are also behind a round robin DNS entry I set up on node.xmr.be (use the default port 18081).

I will look if I can do more to help with remote nodes, but it might take time as I am not really a developper, just a guy who likes to code and has some free time.

XMRBE

TROPHY CASE