Number of accounts is not an issue.

100K tx/day (more than Bitcoin BTW, but perhaps you intended to allow for growth and/or daily variation) is approximately one transaction per second, which is not an issue at all in terms of bandwidth or CPU processing. The block size would grow to accommodate the transactions, and the one thing we've seen from the recent attacks is that the block size growth works. There is a soft cap on the block size that was added to the implementation (not the protocol) but that can be raised easily, and the current cap would likely accommodate about 70K average sized tx per day (more than Bitcoin most days).

It becomes a bit of an issue in terms of storage for the blockchain, at about 12 GB per month, but not prohibitive (multi-TB drives are readily available and cheap). Memory would quickly become a problem so the database is a requirement here.

As a stopgap, larger servers could still handle a RAM blockchain for a year or longer, but this isn't useful without some sort of lightweight clients (that don't exist). Exchange wallets would still be usable, as long as exchanges have a large server to run the Monero node and wallet. But this becomes quite centralized, so finishing the database support is much better.

You won't be running a full node on a cheap laptop, although Moore's law (and friends) means cheap laptops might catch up. (You couldn't run today's version of a Bitcoin full node on a cheap laptop from 5 years ago; it is possible to run on one now, though somewhat painful.)

tldr. Database becomes more urgent. Some growing pains would probably show up. But yes it would work.

The spending of the multisig output is the point at which the funds become spent by the group and respendable by the new owner. It makes no sense to release the multisig early because then whatever benefit is being provided by the multisig (2FA, dispute resolution, etc.) has been lost.

Normally with ring signatures the fact that a transaction output is used by another tranasction does not mean that the output has been spent, only that it has been possibly-spent. The new transaction may actually be spending a different output but using that one as a mixin. But without the ability to spend a multisig with ring signatures, you lose this measure of privacy.

Partially, and in fact I suggested this exact work-around. But the fact of the funds having been spent is still visible, and the additional steps will slow down transactions and increase transaction costs. The latter is not really a big deal for marketplace use but it is bad for a 2FA wallet.


Apparently it is possible but the details need to be worked out. I don't have an answer on how to fix it, and it isn't something I've worked on at all. I'm just going by what was said on the Bytecoin technical thread (and possible the CN forum if I didn't imagine that part).

It is simply the same thing as regular ring sigs, except applied to multisig transactions. Without ring sigs, the source of funds can be traced backward in the blockchain and the use of funds (both the fact of them having been spent and where they go) can be traced forward. So for example if you are using a web-based wallet or some other wallet with (zero mix) multisig-based 2FA, all of your payments would be traceable.

Sorry, nonsense.

Typical mix factors on ring sigs used in Monero are 3-5. Which means this technique reduces size of the ring signature portion of a transaction (not the rest of it) by something between a factor of 1.7 to 2.2.

What this will do is make it feasible for larger ring signatures to be used (say 10-25) in the same amount of space, improving untraceability. Monero will very likely implement this at some point (we've already had our cryptographers looking at it), which means it makes Monero better.

So the improvement is certainly nice, but its not a live or die difference at all.

And no it doesn't at all address the long term issues with blockchain size. If anything BBR's solution to that is better, and I say that a member of the XMR team, not the BBR team.

I agree. The current blockchain memory usage is about 2.5 GB (the actual blockchain is about 1 GB but it seems to bloat up by about 2.5x when loaded into memory, the reasons for which were explained by crypto_zoidberg on the BBR thread, since BBR is about the same as XMR in this respect). The natural growth rate seems to be something less than 10 MB per day. At that rate we have at least 160 days until blockchain size increase by 1.6 GB and therefore memory usage increases by about 4 GB (putting an 8 GB system in the same spot as 4 GB system today).

A tighter deadline is a memory increase by 1.5 GB which which will likely make things uncomfortable (but possibly still usable) on 4 GB systems even with virtual memory. That corresponds to a blockchain size increase of 400 MB, which is something more than 40 days (since the 10 GB estimate above was conservative).

Hopefully we will have a database functional by then.


True, it wasn't our bad idea to load everything into RAM. We are fixing it though.

It seems Cryptsy has something in their terms that explicitly gives them ownership of spin-offs, if I'm interpreting correctly (I assume that's what they mean by "conversions, snapshots"):

Anyone who speaks of unqualified "truth" outside of mathematical abstractions is a zealot in my opinion, but maybe I misunderstood what you said.

That to me says that these so called Monero "fans" are open minded and thoughtful, not zealots.

Most important case is dispute-resolution for marketplaces. If you have a transaction that occurs where there is no dispute the buyer and seller can agree to release the proceeds to the seller. If they disagree a mediator can decide (2-of-3).

Another is a web wallet where both you and a central server have one key required to spend. Your coins are safe from both the server being hacked and your own computer being hacked. A third key can also be kept offline (held by you), which gives you access to your coins if the server disappears, but wouldn't be needed for routine transactions. Similar things can be done with two factor authentication. Again this would be 2-of-3.

I agree with "not a rush" but important for trying to build a larger economy. Right now none of these coins is use for anything but speculation.

In the bytecoin implementation my understanding is that multisigs are always mix=0  (i.e. not deniable and traceable). I didn't entirely follow this explanation (terrible English) but it was somewhat discussed here: https://bitcointalk.org/index.php?topic=718834.msg8132998#msg8132998 . I think there might have been a post on the CN forum as well, not sure.

It's important, but the version with no ring sigs is a disappointment. Some cryptography improvements are needed to do it right.

So you were doing a lot of different things on your 8 GB computer, and your computer can't handle it all, meanwhile someone else is using Monero and some small applications a 4 GB computer, yet you choose to identify Monero as the culprit? The bias here is pretty obvious.

I'm sure jojatekok will have a better answer but my guess is yes. There is work in development to make the daemon into a proper daemon (operates in the background not in a window) I would guess he is using the in the test version. 

The ongoing work is in github under development.

Maybe the difference is ssd vs hd? Just a guess.

Why are you making a big deal about this circlejerk thing?

We are implementing database support to move the blockchain out of RAM okay?


Most of the "pruning" (incorrect use of the word but whatever) improvements in Boolberry have not even kicked in yet. CZ said after a year or so is a reasonable target.

Aside from usage and age (Monero is a month older) the differences that are currently active are:

1. 2 minute blocks (BBR) vs 1 minute blocks (XMR). That results in a difference of 720 blocks per day, most of them empty. Empty blocks are about 250 bytes. So 720 of these per day is 180 kbytes per day.

3. Removing dust from mining outputs. There are only 1440 mining outputs per day. At a very, very generous 200 byte usage impact each that would be another 360 kb per day.

All of this adds up 16 megabytes per month, which is hardly anything. It is all usage.

edit: apparently BBR activated RS trimming today. So my comments above are not technically correct. The are still correct as to magnitudes 

The primary benefit would likely be improved security by using higher mix factors, not block chain size, since it doesn't help at all with long term pruning issues, and cheaper large mixes might lead to greater blockchain use.

http://en.wikipedia.org/wiki/Jevons_paradox

It does you no good to run a Monero pool if the blockchain becomes too large and the coin becomes impractical to use at all.

If (some of) your payout transactions are <20k then you will likely benefit from per-kb fees.

Also I know some of the pools have switched to 3 hour payments. You might consider something like that.

Ultimately the market will have to find the right equilibrium between speed of pool payments and cost.

BTW, you aren't doing your users any service by making very small payouts to them. It makes their transactions much larger when they try to spend.

Be aware you will need the txid to look it up. You can't look up transactions by address.