Topic: Anonymity in the Mini-Blockchain scheme (Read 5480 times)

I don't think it's all that interesting: It requires that you trust the miners implicitly for the history, and if you're willing to do that you can use SPV which is much more efficient. And, I say this as the person who originally proposed state commitments in 2011: https://bitcointalksearch.org/topic/merkle-tree-of-open-transactions-for-lite-mode-21995

If, for whatever reason, one really is interested in an in-between mode: a side effect of elements alpha witness segregation is that you can sync the chain while skipping 2/3 (to 95% with CT) of the data, but still have perfect security for the utxo set.

The txout commitment schemes have a non-trivial cost for full nodes as the txout set becomes large, e.g. requiring on the order of 20 times the amount of I/O--  so a one time miner trusting init takes less bandwidth but then you have much higher IO and CPU ongoing; so it's not actually clear to me that they're a win; even ignoring the security trade-off... which is part of the reason that they haven't moved forward in the Bitcoin space.

Some of the other things in the miniblockchain stuff are just incorrect. Like it claims to not have transaction malleability; but it does due to the inherent DSA malleability. I don't recall other features you might have been looking for.

@Maxwell: I was hoping to see a modified version of mini- blockchain scheme amongst your sidechains candidates or to say elements. Did you consider it at all?
And if you didn't, why? Is it because the mini-blockchain is not a secure ledger cryptographically? Or because it is not feasible to attach such a mini-sidechain to bitcoin?

The timing couldn't have been better.

gmaxwell, the paper is up at the following link https://drive.google.com/file/d/0B21vncLoIlIyUldiZTRxSTYyNGc/view?usp=sharing. Whenever I change the paper I have to change the link so that's why you weren't able to see it. But I always keep the up-to-date link in the first post of the thread.

I have just watched your video introducing the Elements sidechain (https://www.youtube.com/watch?v=9pyVvq-vrrM) and I was very impressed. I didn't expect that new features would be introduced in the first test sidechain, especially all these features. I actually read your draft about Borromean signatures before but thought that you were going use them in the same way as Cryptonite, using ring signatures as an OR proof is an innovative idea. In summation, I'm very envious.  

Since my scheme offers no more privacy than using Confidential transactions + Stealth addresses, I see no reason to try to implement it. The only information that may be useful to you is that I use Boneh-Lynn-Shacham signatures which are shorter and also require less rounds of communication for threshold and blind signing than Schnorr signatures. If you're interested, the following paper https://www.iacr.org/archive/pkc2003/25670031/25670031.pdf describes the use of BLS signatures for  multi, threshold and blind signing.

Hi, All-- 

By an interesting coincident of timing bffranca asked me two days ago to comment on his latest document.   I pointed out some problems with the variable selection in the description of the range-proofs that was making it hard for me to follow what he was describing, and that the particular discussion didn't appear secure (the hashes only occurred once in the verification equation so the proof appeared to be vacuous), this may just be a misunderstanding on my part caused by the equation markup mistake; I'd elaborate further but the document is down. I certainly don't blame Bffanca there-- Adam's post that described these proofs was dense and not easy to decode. My own approach was to first reinvent them from scratch, along the way I came up with a new ring signature generalization and a construction that is highly efficient.

At the same time, I've been working for some time on a similar system for Bitcoin which I've posted about here: https://bitcointalksearch.org/topic/m.11572844 which may be of some interest to some.

I had no idea that Bffanca was continuing this work after the first pass where Adam and I pointed out the need for range proofs until his recent contact.  Had I know about it previously I would have shared my progress earlier!  In any case, all my work is public now, along with a reasonably high performance implementation of the crypto and an integration into a testnet sidechain.

I'm not convinced that I've extract all the efficiency possible from this scheme yet; I was still exploring the use of balanced signed digit encoding (e.g NAF) to try to get the a further decrease... but wanted to get a working system out for people to play with and that meant I couldn't just keep optimizing forever.

Good news: http://www.coindesk.com/blockstream-open-source-code-sidechains/
We would all know much more soon, by their code release.

@bybitcoin: Ok, I cannot say if this scheme can be a sidechain to Bitcoin since the paper does not provide a detailed description of a SPV proof. Without knowing that I would just be speculating. When Blockstream launches their "demo version" of a sidechain, the federated peg, there will be more information. But I wouldn't mind if the scheme became a sidechain instead of a altcoin.

I still haven't read their whitepaper about sidechains. I downloaded it a few weeks ago but just forgot about it. But AFAIK it could be implemented as a sidechain easily.
I will read the paper and give you a more informed answer after.

I am wondering why not consider your scheme as one of the earliest candidates for the sidechains to be embedded with the bitcoin blockchain. Adam Back and Gregory Maxwell both have had a glance at your scheme and they are the very founders of the sidechain proposal. I say this because two of bitcoin foremost problematic issues are scalability and anonymity. Having the total supply of this coin less than the total supply bitcoin has and setting the 1:1 pegging proportion makes this coin economy more precious and dynamic and also guarantees that the bitcoins still in circulation never cut to zero, as they can not all become pegged in the new chain.

Now that I saw what the Nxt's voting system is, I am disappointed. It appears that all votes are recorded in the blockchain in plaintext so that anyone can see who voted on what. https://wiki.nxtcrypto.org/wiki/Voting_System "On the bottom of the pane, the votes cast in the poll are displayed while they are still available. For each voting account the account ID is shown along with the integer range value associated with each option voted for."

Most (if not all) cryptographic voting schemes are private (no one can see my vote) and receipt-free (I can't prove that I voted on a given option), this is done to avoid coercion and vote buying. Nxt's voting system is neither so it can't be used for any serious election. Despite that, there are articles saying it could be used in shareholder's elections, corporate governance (http://cointelegraph.com/news/113414/nxt-teases-voting-system-two-phase-transactions-and-a-foundation) and even government elections (https://www.cryptocoinsnews.com/nxt-decentralized-voting-system-twitter/). This is very misleading and it appears that a lot of people think that Nxt's voting system is secure when it is not.

It goes live at block 445,000, in about 9 hours. (Check the countdown here>  http://jnxt.org/countdown/?block=445000)

You can vote by stake, asset, mscurrency and you have options weight these votes too. It is pretty powerful. Here is a teaser video, starting at the time Alex talks about this > https://www.youtube.com/watch?v=dhJgz6hpHXg&feature=youtu.be&t=68

Comments, once it is live, would be welcomed.

Agreed, you detailed the points precisely.

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%.

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.

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.

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.

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.

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.

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