Anonymity in the Mini-Blockchain scheme

[bffranca]

I haven't thought of that. But it's going to be more expensive than the CRT Elgamal scheme. A CRT Elgamal cyphertext would be 6 EC points. Your idea would be 3 EC points (1 from the commitment + 2 from Elgamal) plus the size of the ZK proof (probably going to be 3 EC points + 3 256-bit integers?). And it still would have the problem of requiring that users connect every 7 days to the network.

Also, the mini-blockchain only stores transactions for a limited time (in cryptonite's case it's 7 days) so if someone receives a transaction and doesn't connect to the network in 7 days, he won't see the transaction and will no longer know its own balance.

[adam3us]

Well presuming we're talking compressed points, thats 256-bits per point or value, then I think doing what I said should be 1x 256-bit point homomorphic value, 2x 256-bit elgamal encryption, a proof of discrete log equivalence signature (2x 256-bit) so 4 values.  4 vs 6, net saving?  Maybe I missed a point not sure without writing out the protcool.  And the CRT scheme while interesting is kind of shiny and new and slowish to decrypt.  It looks ok to me, in terms of crypto-conservatism; but I think this elgamal equivalence proof etc is even more conservative.  (And so is the schoenmaker's range proof IMO).

Adam

I haven't thought of that. But it's going to be more expensive than the CRT Elgamal scheme. A CRT Elgamal cyphertext would be 6 EC points. Your idea would be 3 EC points (1 from the commitment + 2 from Elgamal) plus the size of the ZK proof (probably going to be 3 EC points + 3 256-bit integers?). And it still would have the problem of requiring that users connect every 7 days to the network.

Also, the mini-blockchain only stores transactions for a limited time (in cryptonite's case it's 7 days) so if someone receives a transaction and doesn't connect to the network in 7 days, he won't see the transaction and will no longer know its own balance.

[bffranca]

You would need to prove plaintext and random value equivalence between EC pedersen (additively homomorphic) and regular Elgamal (multiplicatively homomorphic). I don't think you can do it with discrete log equivalence protocol. Especially with only 2 points/values.

[bybitcoin]

What happened to this? Has it been proved to be impossible? 

[bffranca]

No, I apologize for the long absence. I was occupied during January and February. Also, I was not satisfied with the scheme so I spent the last month rewriting it. I will publish it here next week.

[bffranca]

As promised, the new paper. https://drive.google.com/file/d/0B21vncLoIlIydUVGcjdDak1pRGc/view?usp=sharing

[bybitcoin]

As promised, the new paper. https://drive.google.com/file/d/0B21vncLoIlIydUVGcjdDak1pRGc/view?usp=sharing

Very nice.. I hope to have Adam Back and Gregory Maxwell's opinion about this new one as well. Meanwhile I will try to digest the content by myself!

[bffranca]

Thank you. I would also like to have their opinion, especially Adam Back since I borrowed a lot from his homomorphic value scheme (https://bitcointalk.org/index.php?topic=305791.msg3294618#msg3294618). But every opinion is welcomed, I just want the paper to be reviewed.
Bybitcoin, if you have any doubt you can PM me and will respond ASAP. I know the paper ended up being too "dense". Maybe I should write a "lighter" version?

[bybitcoin]

Thank you. I would also like to have their opinion, especially Adam Back since I borrowed a lot from his homomorphic value scheme (https://bitcointalk.org/index.php?topic=305791.msg3294618#msg3294618). But every opinion is welcomed, I just want the paper to be reviewed.
Bybitcoin, if you have any doubt you can PM me and will respond ASAP. I know the paper ended up being too "dense". Maybe I should write a "lighter" version?

I am still getting around it, but sure, I will pm you if I find some part of it questionable. Yet it may take me a lot of time and courage to come up with a critique of your model, since I am not a cryptographer, but rather a number theorist. Therefore I hope Adam come on board sooner than later
About a lighter version, I guess no. You may need a more accessible and lighter presentation of your model for general audience later, when and if your technicalities get approved by the mentioned experts and is ready to be implemented.

[bitfreak!]

As promised, the new paper. https://drive.google.com/file/d/0B21vncLoIlIydUVGcjdDak1pRGc/view?usp=sharing

Very nice work once again. I like the idea of using temporary addresses for every transaction, it seems to be a powerful way of increasing privacy. If I'm understanding your proposal correctly, the temporary addresses created by transactions are essentially what you store in the account tree, or you could also say that the account tree essentially contains all the unspent outputs from transactions (aka the receipts). What you have proposed is more similar to Bitcoin than the MBC scheme because it revolves around unspent outputs and brings back concepts like change and coin minting without inputs.

At some point in the future Bitcoin developers may figure out a way to compress all the unspent outputs into a compact structure which can be shared among peers much like in your scheme. At the end of the day your scheme might not end up being much more scalable than Bitcoin. But since your scheme, like the MBC scheme, doesn't use tx scripting, that allows you to implement all these clever mathematical tricks to produce a high level of anonymity and privacy while still remaining much more scalable than Bitcoin in its current state and all current anon coins.

Obviously it wont be more scalable than the MBC scheme but the original scheme doesn't provide the remarkably high level of anonymity that your scheme does and anonymity always comes at a cost. I also noticed that your new solution to preventing small value outputs (aka dust) is to enforce a minimum value output. Micro-transactions are much more costly in your scheme compared to the MBC scheme so I can see why you would gravitate towards that solution but it still seems like a rather poor solution to me, especially if the minimum value were to remain static over time.

A better solution might be to simply have miners enforce a minimum transaction fee. I've never really been a fan of the Proof-of-Stake mechanism but one reason I think PoS can be truly useful is for allowing stakeholders to vote on the minimum transaction fee and other important values such as the maximum block size. The problem of pruning dust really is one of the hardest things to solve I think. Sacrificing micro-transactions for more scalability is probably the best solution for your scheme but there are definitely better solutions for the MBC scheme.

[bffranca]

You understood it perfectly, the account tree has the unspent outputs of all transactions. The advantage for me of separating the unspent outputs from the transactions is that the transactions are much larger in size (in this scheme) than the unspent outputs, so there is a considerable saving. The minimum output value was borrowed from Bitcoin and it seems to be working well for them. An interesting variation could be forcing the minimum output value to be a multiple of the transaction fee, for example, if you include a transaction fee of X then all outputs must be at least 3X.
I remember that you wanted to have maintenance fees in Cryptonite to control dust but you were having problems with the actual mechanism of deciding the value, but having the stakeholders voting on it seems to be a good solution. Nxt is going to implement (or has already implemented?) voting by stakeholders. It is probably worth seeing how they do it, maybe it is applicable to Cryptonite.

[bitfreak!]

The advantage for me of separating the unspent outputs from the transactions is that the transactions are much larger in size (in this scheme) than the unspent outputs, so there is a considerable saving.

Well there are no unspent outputs in the MBC scheme which is why I think your scheme is closer to Bitcoin. If I were to send 1000 micro-transactions to the same address using Cryptonite the account tree would only grow larger on the first transaction, but if the address was already in the account tree before I sent the first tx then the tree wouldn't grow at all. In your scheme the tree would grow for each of those 1000 transactions because you're recording unspent outputs rather than a balance sheet like Cryptonite. And that is the main reason why Bitcoin will never achieve the level of scalability that Cryptonite has, despite what some other people might claim.

I remember that you wanted to have maintenance fees in Cryptonite to control dust but you were having problems with the actual mechanism of deciding the value, but having the stakeholders voting on it seems to be a good solution.

Yeah I've thought about it but it's obviously not going to be the easiest thing in the world. It's also very hard to decide when and how the maintenance fees should be subtracted from address balances even if you know what the maintenance fee should be. There always seem to be serious difficulties involved regardless of how the problem is approached.

[bffranca]

The advantage for me of separating the unspent outputs from the transactions is that the transactions are much larger in size (in this scheme) than the unspent outputs, so there is a considerable saving.

Well there are no unspent outputs in the MBC scheme which is why I think your scheme is closer to Bitcoin. If I were to send 1000 micro-transactions to the same address using Cryptonite the account tree would only grow larger on the first transaction, but if the address was already in the account tree before I sent the first tx then the tree wouldn't grow at all. In your scheme the tree would grow for each of those 1000 transactions because you're recording unspent outputs rather than a balance sheet like Cryptonite.

Yes, I was talking about the advantage relative to Bitcoin. I know the account tree in my scheme will be at least an order of magnitude bigger than in the MBC, probably more. I tried to maintain the accounts in the scheme, but it was simply not possible to have a high degree of privacy with reusable accounts.

[bybitcoin]

Is there any plan or desire to implement this anytime soon?
Of course after a final review of the scheme by the experts.

[bffranca]

I would like to see this come to life but I can't do it alone because I don't know how to code (except some simple scrypts in Python). Having said that, I am willing to work in any way I can.

[bybitcoin]

One way is to get more publicity after a final review by some experts, to attract talented coders take a part.
Another way is to place a presale of let say 5% to 10% of the total supply and use the collected (btc) fund to shape a group of professional coders for implementing it asap.

[mikenz]

If this concept goes 1/1 into a coin with fair distribution algo, low inflation and no premine or other ripoff crap, its definitely a buy.

[bffranca]

Presales (and premines and instamines) have a negative connotation regardless of what the money is used for. It would be a shame to turn people away from a good cryptocurrency just because there was a presale. IMO, voluntary coders and fair distribution is the way to go.

[bybitcoin]

Presales (and premines and instamines) have a negative connotation regardless of what the money is used for. It would be a shame to turn people away from a good cryptocurrency just because there was a presale. IMO, voluntary coders and fair distribution is the way to go.

I agree, just mentioned both possible ways, to clear it out.
Also imitating btc stats including total supply, distribution curve or even lowering the inflation is most advisable. But the time between blocks should be much shorter, 1 or 2 minutes would be ideal.
The only thing I don't like about cryptonite is its 10 years flat high inflation rate. Unless a coin has an existent market to support and use its supply from the day 1, high flat inflation would scare people off. Moderate speculative atmosphere (I don't mean pump and dump) is healthy for any growing economy.

[bffranca]

There is an advantage in having a smaller total supply, the range proofs get smaller (513 bits for each bit of the total coin supply). Since Bitcoin's supply is ~2^50.9, a total supply between 2^40 and 2^50 is desirable.
The distribution curve is difficult to decide. If it is too short, the supply gets concentrated in a small number of people and the coin gets accused of being a pump and dump. If it is too long and the price does not rise accordingly, no one wants to hold onto the coin because it devalues too fast. Normally if a (fiat) currency exceeds 4% inflation it starts to be a problem. I don't like Bitcoin's distribution curve (see http://www.mattwhitlock.com/Bitcoin%20Inflation%20logarithmic.pdf) because it takes a long time (12 years) to reach a good inflation rate (2%) and then only spends 4 years at that rate. I would prefer to have a initial period of very high inflation to distribute coins (like the first 4 years of Bitcoin) but then have a longer period where the inflation is kept at a constant rate between 2% and 4%.