We're working on making the software more functional for payment processors and web wallets rather than concentrating on a GUI for the wallet that is attached to the daemon. The vast majority of Bitcoin users do not use full nodes anymore. In fact, only about 700 full nodes even exist on the Bitcoin network anymore.

The DB works, you can compile the branch and play with it. I'm pretty sure the one below is the correct branch (I haven't been working personally on it).

https://github.com/tewinget/bitmonero/tree/blockchain

OpenBazaar is a protocol, not a one stop shop for illegal drugs. Thus, governments probably can't stop development on it any moreso than they could on BitTorrent. If anything, a crackdown on the software would lead more people to using it and developing for it, e.g. PopcornTime.

in 4 years there's going to be ethereum 8.0, IBM adept (ethereum fork), many other innovations we can't predict, and 293,294 Bitcoin sidechains with myriad features. perhaps a faster distribution curve will be the one thing that ends up saving xmr, because it in theory, with adoption, will cause a more rapid increase in price than these major competing currencies.

my point is, it'll succeed or it won't in the next 4 years, and it's not going to matter what the emission is at that point.

suddenly slowing emission to 1/2 or 1/4. in 10 years i bet we'll have people sitting around saying bitcoin was a horrendous instamine, etc, etc. which it is as well. monero just has a faster timescale. there was a time when you could get xmr and btc cheaply, relative to what it is now. it's preprogrammed to be that way. ours is pretty fair too. at this point, cryptocurrencies aren't that new, everyone in tech knows about them, and the onus is on them to read the CN whitepaper and understand what's going on.

yup. as opposed to bitcoin, where they are stored in the multisig script (and so you can publicly tell all those who are involved). this will be offchain tech, granted we can get it working in the near future.

ideally we'd need multisig. we're working on a version of it where no one can tell you're using multisig on the blockchain (the tx look the same as any other tx).

ehm. i don't usually respond to troll posts, but it's saturday, so why not?

i still have all my xmr.

i have stated before i'll sell all mine if there's some crazy dramatic change to the emissions curve. that's still the way i feel. i am in support of fixing subsidy at 0.1 XMR when we reach it, to cause small amounts of inflation that help secure the chain, but that's it.

in the future, 2-3 years from now, if people want to come back and tell me that xmr was a premine, that they never had a chance to get in on it when it was cheap, direct them to this post and what the chart looked like at this time. xmr was here to buy, it was cheap, the tech is in the CN paper, we implemented the first database for CN core (not a page file), we published the first paper on a number of privacy issues, and i'm working hard to ensure a roll out of new privacy features in the near future. we've battled off several serious attacks and drama, and we've done it on our own dime. we never had a premine, we never had an instamine, we never had a tax.

i personally never sat around pumping the coin, etc etc etc. the tech behind it is good, so i always had faith. we reimplemented the ring sig algo and studied it intensely and couldn't break it. ecdh is trivially secure. the bitcoin core devs spoke favourably of the ring signature technology in the their sidechains paper.

gui for the node is really an afterthought, which was why we never shoved one out quickly. look at how many bitcoin-qts are left running these days; everyone uses a safer reimplementation of the bitcoin wallet or a webwallet because running a full node using 250 GB of bandwidth a month is silly for the end user. rest assured we're working on better solutions.

there's going to be a lot of stuff happening in the near future. dev is rolling along. if you wanna dump your coins now, go for it.

There is a point when buying mining hardware will become a good investment versus fiat. When Bitcoin and Litecoin mining profit peaked (May 2011, twice in 2013), ASICs and GPUs were selling at 3-5x their original prices despite being used.

Whether it's just better to simply buy Bitcoin is a different debate.

It's been busy.

The new database code [so far] works great.

Some progress has been made on a major overhaul of the privacy technology of coin via proposed changes to the wallet. Hopefully soon there will be more details about that. We wish to make Monero the high efficiency, high privacy chain with no opt-out for being a mixable element for any given output.

Many of us are travelling at the moment and are all over different countries, so bear with us.

Until people make t-shirt sized implementations of it.

It's probably not possible, unless they've made some advancement in cryptography. From the paper I posted earlier:

There's a reason that ZeroCoin hasn't really been implemented in a cryptocurrency before. Although AnonCoin claims to have done so, using 128 KB niZKPs; God only knows what the verification time is like on those.

Nah, the proofs stay the same size. Although, it looks like the parameters they chose may be totally insecure, at least if they're using the default ZRC lib. I think secure proof sizes were larger, around 128 KB with >3k bit keys, their proof sizes imply much smaller bit commitments. If this is the case the security is already broken.

Interesting, so about 26 KB just for a ZeroCoin commitment and niZKP in the scriptsig alone. That's the same as from libzerocoin.

From Green's lab:
http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf

...80 bit security?

http://www.keylength.com/en/compare/

Enter your key size in "asymmetric key size".

There's a basic description of how an RSA accumulator works here:
https://eprint.iacr.org/2009/625.pdf

See 2.2, and ignore the initial stuff relating to the hash tables.

Um, if the method used to spend the old coins is totally insecure, probably not unless they're additionally wrapped in some way eg a normal ECDSA signature that is otherwise unused.

DDoSing a centralized pool is already trivial. But DDoSing all the nodes on the network is much harder, and the longer verification time makes that trivial.

That a transaction in the past was actually valid or not.

There's only a handful of even modestly secure primes p and q from that list, from 1536-bits to 2048-bits, with which to use to get N = pq. Key lengths of 2048 bits are unlikely to be secure within the next 5-15 years. As far as I can tell, whoever factors these first gets to spend all your zerocoins ever. It's also totally and trivially quantum insecure due to Shor's algorithm.

That you admit proof verification is measured in single to double digit seconds means that both DDoS of a node is trivial and block verification time is insane; you just need to spam invalid proofs from a number of unique IPs to computationally knock a node off the network, and generating a block with more than a few transactions will be an impossibility to propagate throughout the network before another competing block is published, resulting in massive amounts of orphans and a totally insecure blockchain. You could store the verifications over time in a cache, but it's incredibly easy for an attacker to simply not publish these and then publish a block with say, 200 valid zerocoin transactions and totally screw up the network.

That you're not even storing the niZKPs on chain is another huge problem affecting network consensus based on history.

Multisig is being addressed too, but we plan to do it so that signature sizes remain the same.

Right, but can you explain how you did the trustless setup to establish the accumulator? And also what trustless entities exactly were included in the setup, as right now it's impossible to verify that anyone except you has generated the accumulator? That's a rather important point as it would allow you to spend anyone's money otherwise, without anyone possibly being able to tell it was you doing so. It seems confusing to me how you possibly got the niZKP down to a reasonable size and verification time, too, for instance they're 128-256 kb in the default implementation, with verification times of 4 or more seconds each.