Topic: [BOUNTY] Mini-Blockchain Implementation - page 2. (Read 4520 times)

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

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://bitcointalksearch.org/topic/poll-ranking-new-features-for-decentralized-currencies-279340

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.

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?

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://bitcointalksearch.org/topic/m.3343568

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

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://bitcointalksearch.org/topic/m.2389448

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

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.

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

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.

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.

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

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

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

Discussion has been moved to here:
https://bitcointalksearch.org/topic/closed-20000-mini-blockchain-implementation-371601