Bitcoin Forum

Discussion has been moved to here:
https://bitcointalk.org/index.php?topic=371601

I am posting merely to provide some perspective as someone who has recently implemented 90% of what is required to win this bounty.

1) This is easily a month of work, especially since you include a basic GUI as the bounty stands you are offering below minimal wage.


As far as the concept goes, the proof-of-work will verify the state of your account tree, but you will face the following challenges:

1) for large numbers of accounts, your tree will become untenable
2) synchronization with a moving account tree target will be challenging to say the least...
3) 2 min block time and 10 MB block sizes is not tenable for a decentralized solution.

I started designing BitShares after this design because I thought it was tenable, but once you get into specifics and start running the numbers it does not work.  I spent weeks working on both the account tree, and designs to sync it.   Now I generally consider myself to be a competent software engineer, so anyone tackling this will have a major challenge ahead of them. 

So while I won't claim it is impossible, I will claim it is not practical without far more innovation.

Like I said, I am aware of that and I would put more into this if I could, but I'm not a very rich guy and as it stands I've already put quite a bit of my savings into this. It was intended to be an open source project, and it will be an open source project after we get a working client. It's not like the only reward for getting this scheme built properly will be the money, we will get a new crypto-currency with many novel features and that will benefit us all. EDIT: you are right about the GUI though, I will make that optional.

I think point one will really only become an issue much further into the future. Based on the amount of bitcoin addresses that have been seen by the network up until now, if we were to save all those addresses into an account tree it would be quite small, only a few hundred MB maximum. Of course, the account tree is the bulkiest part of the scheme, and there's really no getting around that... but it's a distinct advantage to the historic ledger format offered by the bitcoin blockchain because we only need to know about funded addresses and we don't need to know all of the transactions associated with any given address in order to calculate the balance of that address. So the account tree is a far superior ledger format which offers a much greater level of compression over the long term and is much easier to trim than the bitcoin blockchain... the bitcoin blockchain is going to become untenable many times quicker than the account tree will.

As for point two, I don't really think it would be that hard if the process described on the network synchronization (http://bitfreak.info/mbc-wiki/index.php?title=Network_synchronization) page is followed. The blocks are not solved fast enough to pose a real problem for nodes trying to synchronize imo... did you actually get far enough to test out this aspect of the scheme? And as for point 3 you do have a valid point, but not all blocks would get filled and I was just allowing some wiggle room for future technological enhancements, but that's why I would prefer a dynamic max block size mechanism and I would highly encourage anyone attempting this problem to fulfill that extra bounty, as well as the rest of them. It really wouldn't be complete without those extra components but it would have less chance of even getting started if I made it all part of one bounty.

I think what you are suggesting just leads to a race, where the double-spender issues a large number of txns so that the legitimate txn is excluded from all 10 blocks with high probability.
I don't see any advantage over bitcoin's status-quo.


What "queue?" Isn't the queue completely up to the miner, who would likely prioritize 0-conf txns according to fees?

Here is my alternative spec that is robust to these issues:
http://www.netcoin.io/wiki/Secure_and_Instantaneous_Zero-Conf_Transactions_for_Point-of-Sale_Purchase

Now that I think about it, that is actually a very real problem which I don't think anyone has noticed before. But I believe there is a solution for that: a special type of "priority transaction" which takes priority over the other transactions. Obviously the miners could tweak their clients to reject the priority transactions if the fees of the malicious transactions are higher, but one way that could be countered is to impose a double-spend punishment (http://bitfreak.info/mbc-wiki/index.php?title=Punishing_double-spending) which allows miners to punish someone if they issue a priority transaction and then also issue any other transactions which would infringe upon the withdrawal limit.

I didn't write that part so I'm not exactly sure what it's supposed to mean, but you're right I don't think queue isn't the best term to use there. I think the simplest and best way for the merchant to ensure the transaction gets processed is to rebroadcast the transaction as soon as they receive it so that if the buyer attempts to issue any other transactions which exceed the withdrawal limit the miners can use the priority transaction to impose a double-spending punishment.

Yes, if you actually clicked on the link you'd notice that this is more or less what I proposed. And I did mention this when your linked idea was first proposed (don't remember by whom, but probably by you). I just got ignored at the time.

Why not copy the suggested design in the link I posted?

I kind of sick of seeing people trying to propose 'new', 'original' ideas rather than consider existing ideas that accomplish the same goal.
 
9 times out of 10 the 'original' idea ends up being inferior to the existing idea.

I did click the link and read it but I found it all very confusing with terms like "seed contracts". But I will say it sounds very similar to the solution I proposed in my last post. But for the record I didn't come up with the idea for secure 0-confirmations and it wasn't even a part of the white paper. No one said the 0-conf idea was original but the main mini-blockchain concept certainly is original.

Well since you think both solutions are essentially the same I don't see the point. The solution I described in my last post is described within the context of the mini-blockchain design, making it easy for me to understand and visualize, where as the solution proposed in your link includes jargon which I don't understand, probably because it's written from within the context of the Netcoin design, which is extremely different to the mini-blockchain design.

Fair enough. Maybe I'm just in a bad mood.

My apologies to anyone trying to access the project wiki within the last week or so, I was having problems with my web host and it took a while to sort it out. The wiki is now back online if you need it.

I have also increased the total bounty from 17.5 BTC to 28.5 BTC, which I think is now a reasonable reward for this project. But I still encourage people to donate to the bounty because I'm not putting anymore into it myself.

Do you mean Java the language or any language (e.g. Scala) that interopts with Java and runs on the JVM? See the following link for prior discussion:

https://bitcointalk.org/index.php?topic=215936.msg2389448#msg2389448

The advantage of rewriting in a HLL, is the more compact code will be more easily to understand, maintain, modify, extend, etc...

For example, Scala is typically 2 - 3x more compact code than Java. Also Scala has a plugin employing inline annotations for validating that functions are pure and referentially transparent, which is important if you hate spaghetti code. (Java may have a plugin for doing this, e.g. Joe-E?, yet I am not sure how seamlessly integrated it is).

I mean the Java language. I chose those two languages as options because there are already good bitcoin implementations written in both those languages and because I have a working knowledge of both those languages. So I would prefer not to allow any other languages but it's not an absolute requirement if you really want to work in another language.

The bounty offered may not be enough to motivate someone to focus all their time on it. For that level of focus, perhaps this will need to be done in the context of someone creating an altcoin that incorporates it along with other important features (e.g. an improvement on Litecoin's Scrypt to prevent GPUs, so we can get true decentralization of mining that your excellent design enables). Yet you disallow premine, which someone may also want to do to recover their investment in creating an altcoin. Something to consider, because if someone could get your bounty while also getting a premine on their altcoin, it wouldn't stop you from extracting the relevant source code into another altcoin without the premine.

Thanks for the reply.

Let's hope we can get this implemented soon. You will really need a dedicated developer(s) to carry it through to fruition in the market.

An ethical developer who premines would probably share some of the premine with those who helped develop this specification.

P.S. the wiki was much easier for me to understand than the whitepaper.

I am seriously contemplating implementing this, and running with it as my main focus. And based on a post I made today, I am no longer thinking of putting greater spending transaction anonymity into the coin than Bitcoin has now (before CoinJoin implementation), thus I would not feel threatened (to be harassed by the NSA and IRS, etc) if I developed this and my identity is known to all.

https://bitcointalk.org/index.php?topic=279249.msg3343568#msg3343568

Well I only wanted to avoid a pre-mine because having a fair start gives the currency a much better image. But you do have a point, 28 BTC is still a low reward for everything I am asking and a pre-mine reward could help close that gap. But it's hard to give an exact number for the pre-mine reward because it depends on the rate at which new coins are created and the limit to how many can be created. Plus the coins are going to start off worth very little, meaning it will take a lot of coins to "recover the investment" unless you wait for the coins to become worth more, and I don't want a large portion of the total coin supply to be monopolized in the pre-mine. It would have to be an extremely small percentage of the maximum coin supply. What would you consider to be a fair reward?

If for example I create a coin not named peercash (although that is a reasonably good name and the market should decide), then anyone else can extract the relevant portions to create a coin without a premine named peercash.

I think the most important focus is to get something implemented, then we will work it out later. I trust you to be fair.

I think anyone capable of implementing should just do it and not worry too much about it. The market will feedback if someone is doing something unacceptable, by creating and preferring to mine and use a copy of the coin without the premine.

If the market feels they value that developer(s) and wants to keep them motivated, the market will support the premine by preferring that coin.

And yes the developer needs to be long-term invested in the coin, and continue to maintain it, otherwise who will?

If someone takes the lead with full-time effort, then others who can contribute part-time effort will likely cooperate with the lead who demonstrates competence, dedication, and fairness.

Any premine should be a diminishing, insignificant portion of the money supply.

Poll I did on desirable features for an altcoin:

https://bitcointalk.org/index.php?topic=279340.0

I will go post in the altcoin thread you started a link to that poll, so we can open to discussion how to design the other features.

I think you are going to find the bounty is not nearly enough but CIYAM Open (http://ciyam.org/open) would be happy to create a project for you to help manage the tasks (fee free for the life of the project) so that they can be easily followed (e.g. http://ciyam.org/open/?cmd=view&data=20121221072815393000&ident=M100V137&chksum=45c95736 to follow the progress of the CIYAM project itself).

The problem is if we start creating so many variant implementations so soon it will create more uncertainty and make it harder to trust any single one of them, plus it will give us more to manage and dilute our focus away from one single implementation. And it's also important to keep in mind that the first implementation of anything is always the most successful. Bitcoin isn't necessarily the best cryptocurrency out there, it's just the original one designed by Satoshi and therefore bitcoins will probably always hold value. The same sort of thing will probably apply to this project, the first implementation of these principles into a usable client will be naturally stronger than any which follow it, assuming that it isn't very poorly designed. So I would prefer to stick with only one single implementation for as long as possible (leaving it up to others to build variants in their own time) because then we can put more focus and attention into that single coin and it will be seen as the official trusted implementation of the mini-blockchain concept.

I agree. So can we nail down which extra features we agree on and their design. This will also remove some focus of culpability from myself for implementing the ones which authorities might not like so much, e.g. anonymity. I will go post in your altcoin threat for this, since that is the place to discuss that.

Can you all respond there please?

https://bitcointalk.org/index.php?topic=195275.msg3346945#msg3346945

All that extra features that I want to see are listed as bounties in this thread. I didn't include anything about anonymity because it's a tricky thing to do right and I think it's better to anonymize yourself via other means rather than rely on the coin its self being totally anonymous. Like you said in the other thread, is it really possible to have privacy at all without the anonymity of IP addresses? Designs like the zerocoin proposal are very interesting but there is already so much new stuff packed into this bounty and I don't think it would really help to add even more to it.

I agree do not add features to this bounty. I am suggesting we must address the features that users want if we intended on releasing an altcoin and not just meet the proof-of-concept stage of your bounty. Personally I want to code a production ready altcoin and address anonymity, otherwise I probably won't be as motivated to code it.

If someone is serious, they want to release something that wins in the market. So they want to do a market survey, then address the results of the market survey, as I am doing.

A little bit about me. I wrote in C and 68000 assembly (with one other programmer who came in later and was primary focused on FONTZ!, yet I did much of it) the first popular commercial fully featured WYSIWYG word processor for consumer PCs back in 1986, named WordUp (google "Word Up Neocept"). Had about 30% market share globally on the Atari ST. I wrote one of the first accelerated printer drivers using RLE encoding for these new GUI operating systems at the time, etc..

I was one of the 3 or 4 original developers (along with the 2 principals) who programmed Fractal Design Painter, which is now Corel Painter, a million user product. Was the first natural media painting application. This was C on the Mac and Windows.

I solely wrote in C++ CoolPage(.com and the downloadable application, along with DownloadFAST.com) which around 2001 had million users and 335,000 websites verified with Alta Vista.

I've contracted on and wrote numerous other applications, e.g. EOS 3D Photomodeler (first realistic 3D models done from photos), Art-O-matic (first amateur real-time cartoon line rendering of 3D models), etc..

I started getting into P2P around the time of Bittorrent:

http://web.archive.org/web/20130401040049/http://forum.bittorrent.org/viewtopic.php?id=28


I currently believe two facts (subject to being refuted) and that is why I think we need to discuss it now (in the other thread).

1. Mixing coins doesn't help so let's just forget Zerocoin and CoinJoin like mixing proposals.

2. Anonymize yourself without it being enforced on all peers in the network, means you might be blacklisted (tainted) by other peers in the future. Also peers which don't anonymize will have a timing and DoS advantage, so therefor you won't be able to anonymize yourself.

In short, it must be included in the coin.

Yes making a mix-net that isn't subject to timing and DoS attacks requires design effort. You've done a great job on the design of the mini block chain. Do you feel you, aaaxn, bytemaster, myself, et al can't do a good design specification for the mix-net?

P.S. I often edit my complex posts up to 30 minutes after initially posting them.

You are correct, but the problem is all we have are elaborate schemes like zerocoin. It's a very complicated thing to do and we don't have a clear proposal for how it can be merged with this mini-blockchain concept. That is why I think it's ok if we skip over the anonymity part, because if some one needs extra anonymity they can always use other software to mask their IP or what ever. I took a look at that survey thread you did a few hours ago and it looks like the demand for a scaled blockchain has now outmatched the demand for increased anonymity.

Ok, well then that really leaves us with nothing much at all. Which is yet another good reason to skip over the anonymity part.

Perhaps we could, but my question is this: is it really worth the time and effort when we already have most of what we need to build a next generation crypto-currency and anonymity can be achieved on user level basis?

I think you are missing my point. Let me try to explain.

Zerocoin and CoinJoin are decentralized ways of mixing who owns the coins. The objective was that you could mix up your identity with a bunch of other people, so no one knows who owns which coins. The problem I pointed out yesterday, is that this depends on those others not screwing up their anonymity, because if they inadvertently reveal their identity on the mixed coins, then they also reveal your identity, because only you remain unidentified, so clearly the remaining coin from the mix is you.

Thus they are unreliable and unhelpful. So just forget them entirely. Zerocoin is more complex than CoinJoin, but that is irrelevant to my point, which is that all coin mixers (including centralized ones such a tumblr websites) are unhelpful.

Because not only does the trust of plausible deniability fall apart for the reason I gave above, yet also coins coming out the mixer are tainted with the possibility of being mixed with illegal activity, thus eventually society will reject all coin mixers.

Also the decentralized ones are subject to DoS, and the centralized ones can steal all your money.

So after all that, they just are not helpful.

But coin mixers are not the only aspect of anonymity. We need the mix-nets that anonymize our IP address. But the problem is that if the mix-net is optional for the coin, then everyone who uses it is tainted, as well as being at disadvantage when trying to win the PoW (since speed to broadcast is a factor) as well more DoS issues if running a mix-net.

So it either has to be standard in the coin, or we will never have anonymity.

I am not willing to abandon anonymity FOREVER. Are you?

We only get one chance to release an altcoin. The window of opportunity is rapidly closing.

Please consider if you want to demotivate me and others who might want to produce a serious altcoin that can address the major issues. I am serious.

We already have example mix-nets that work, e.g. Tor and I2P. Yet they are not designed to resist timing attacks. Thus we could tweak their design and then make it standard. We don't have to entirely reinvent the wheel from scratch.


No they can not. I think you are missing the point I am making that if it is not integrated, then those who use it will be tainted by those who don't.

Do you understand the issue of taint?

The point is some of society will readily bend over for the government and ask where would you like to insert it. They will then taint those who want to protect their privacy. Meaning that those who try to protect their privacy will be grouped by association with those who are attempting illegal activities.

Anonymity has to be standard in the coin, else you never will have it (in the long-run as the socialism ramps up its regulation of decentralized coins).

We still have sourcing our coins in small chunks, then we don't need to split value as often. That is comparably as effective (but not as convenient) as mixing without the lack of reliability.

And this need plays with my point about debasement.

Design of software is holistic, as you discovered from designing the mini-blockchain.


See my prior post. I am thinking the mix-net can't be an orthogonal feature. I want others to discuss this with me, so we can hash out what is the objective fact.

I would be happy if I am wrong on this point.

There are two anonymity slots which divide up the desire for anonymity somewhat, so it is not clear if we add them, in which case it is still a higher demand.

In any case, it appears to be a very highly demanded feature in the top 3.

If it could be orthogonal and addressed later, I would prefer that. I have explained why I don't think so, and I await others to feedback their logic.

I overstated a bit to say coin mixers are entirely unhelpful. They just have too many issues and the taint issue is "don't go there" in my mind, especially considering we can get comparable privacy and anonymity by (inconveniently) sourcing our coins in small chunks so we don't need to split the value.

But I still don't think "sourcing the coins in small chunks" really solves anything in the grand scheme of things. You're talking about people mining coins themselves and then using those coins right? Wouldn't it still be possible to be tainted by those who don't bother taking steps to use freshly sourced coins? I really don't understand how your suggestion is economically plausible when mining is inherently supposed to be a hard and difficult thing.

How so? Do you still think this after my reply below?


Mining isn't required in all cases.

What the coin mixers are primarily intended to solve is where your identity on spends can be correlated, i.e. you buy an abortion and then you send a donation to your Catholic church.

To stop the sends from being associated (i.e. "linked"), we need to spend one coin on abortion and a different coin to your Catholic church. Instead of paying for both from the same coin, or even from the change from the prior transaction, as both of these are linked in the public block chain.

So when we receive coins for any reason, we want to receive them in separate small coin values, so we can spend them by joining inputs instead of needing to split change on large value such that we can't delink spends on items we want to be orthogonal.

Mining could possibly provide a convenient way to get coins anonymously in small chunks (since we are fixing the client resource issue and we could fix the PoW algorithm to eliminate GPUs and ASICs so you fire up your PC to earn some coins).


I am thinking no. The identity of who is paying you a small chunk doesn't necessarily identify you (unless you revealed it to them in some other way), unless they pay you multiple small chunks from the same coin which you can also detect in the block chain of course.


It is supposed to return on your investment in hardware. If you have coins to anonymize, you buy some hardware and generate new virgin coins.

But that is just so utterly complicated and not user friendly...

Agree. In all my years of programming easy-to-use software, I would never want that, if there was a reasonable way around it.

Unfortunately, I don't see another plausible solution.

I think we could largely automate this somehow. Deterministic wallets may help.

I also thought of forcing the maximum account balance to be say 0.1 coin, but that seems harsh, inflexible, and brittle.

If we don't make it easy and users end up later having their payment history put up on news site and web sites, then Bitcoin and our coin will probably never be accepted by the mainstream.

And this is yet another reason I think the NWO fiat digital currency will win in the end.

So yeah, we better strive hard to make it work.

For the meantime, centralized (web site) coin mixers are being used by those who care to.

I think we can make a smart wallet which optimizes keeping identities distinct on spends, and shows which coins have been spent to which entities, so the remaining balances can be spent on something that doesn't conflict. Yet this still requires the user to do some deep thinking.

One positive thing to keep in mind is that (unless you are really paranoid) you only really need to delink spends that have your identity. So not giving your identity to whom you are spending to is another solution.

So I think that significantly lowers the burden.

And perhaps that is the magic logic I needed to justify that all connections will be forced over a mix-net. I feel we need to be able to justify this design decision to the authorities.

If you click the links at the top of each of the following quotes to read the discussion, it is clear to me that Bitcoin is honeypot for the usual powers-that-be, and it is breaking anonymity and funneling the naive goldbugs into a mix with the criminals and in perfect way to help destroy them during this coming global smash 2016 - 2024 or so.

Also there is complete silence is "that thread" linked below. Thus even though there was a super majority that agreed with 5% perpetual debasement, the silence leads me to believe they don't really disagree with goldbugs.

Thus it means if I tried to create what is better and eliminates that honeypot, I would not only have the authorities on my back (IRS harrassment, etc), I would also not have the support and understanding of the community, because the community is hoodwinked and naive any way.

Everytime I think about doing this project, I feel it can only destroy me.

Someone would have to be crazy to write s/w that prematurely* destroyed the Bitcoin honeypot, they will surely have an unpleasant life thereafter.

* The lack of debasement after 2024 or 2033, indicates it is designed to be destroyed (or morphed into a centrally controlled digital currency), but not until after hoodwinking all those freedom lovers and goldbugs into mixing their wealth with illegal activity, not declaring capital gains, using an asset as a currency without declaring each transaction as a capital gain, etc..

Sad to say, I can't even get the designer to understand currency, so how would we mount a community-wide support to counter-act the evil that would come to anyone who successfully challenged Bitcoin?

---

---

On the anonymity issue, it is sobering the resources the NSA applies to Tor users:

https://www.schneier.com/essay-455.html

Implementors might also take ideas from libcoin (https://github.com/libcoin/libcoin).

Sorry for my delayed response, I haven't been able to spend much time online the last few days.

Come on now, if it wasn't for "Satoshi" we wouldn't even be living in a world with decentralized crypto-currency. Quite frankly your above accusations are unfounded, irrational, and not true. If you use Bitcoin properly it's possible to achieve a much higher level of anonymity than any classic banking system could provide.

Do you believe that you're the only person to ever argue for perpetual debasement? There are several altcoins to my knowledge with perpetual debasement built into them, and as far as I know none of them are very popular. So does that not prove which is more demanded?

Exactly, there is no reasonable way to do it. If it's not an acceptable solution and you don't have a better solution then it cannot be done. I don't want this thread turning into a discussion about how to solve the anonymity problem, if you want to create a project which is focused on solving the anonymity problem then start a new thread for brainstorming.

Is this idea still alive. Has the discussion moved to another thread. I happen to think Mini-Blockchain is a good idea, but don't have the technical skills to program it myself.

Is anything happening on this?