Building the Next Generation of Crypto-Currency (developers required)

[bitfreak!]

Btw, it adds some other important features, as aaaxn said:
I think the most important one is that secure 0-confirmations would be possible.

Where did aaaxn say that, because I'm not sure that is true. It seems to me that one must still wait for a few confirmations for the same reason one must wait for multiple confirmations in bitcoin: orphaned blocks (and more unlikely, a 51% attack). But obviously quicker confirmation speeds will make it faster than bitcoin.

[1713539724]

1713539724

[1713539724]

1713539724

[1713539724]

1713539724

[1713539724]

1713539724

[1713539724]

1713539724

[1713539724]

1713539724

[aaaxn]

Btw, it adds some other important features, as aaaxn said:
I think the most important one is that secure 0-confirmations would be possible.

Where did aaaxn say that, because I'm not sure that is true. It seems to me that one must still wait for a few confirmations for the same reason one must wait for multiple confirmations in bitcoin: orphaned blocks (and more unlikely, a 51% attack). But obviously quicker confirmation speeds will make it faster than bitcoin.

I made attempt to making secure 0-confirmation for some subset of all transactions: transaction for accounts with spending limit. It is not universal but maybe worth including. See here:
https://bitcointalk.org/index.php?topic=195275.msg2083400#msg2083400

[bitfreak!]

I made attempt to making secure 0-confirmation for some subset of all transactions: transaction for accounts with spending limit. It is not universal but maybe worth including. See here:
https://bitcointalk.org/index.php?topic=195275.msg2083400#msg2083400

Ok yes I do remember that post now but I kind of skimmed over it the first time I read it because it seemed like a fairly complex idea. Reading it again more carefully it does make sense to me and I think it could work, but it is a moderately complex idea and it will require a new field in each account tree to keep track of the account withdrawal limit if I'm not mistaken. It's definitely something to keep in mind, but probably better to include it in a later version of the implementation rather than put it in too early. It would be good to have something like that included before the first official client is publicly released though.

[bytemaster]

So how much compression does this actually give you?

The most compression I can think of is:

20 bytes   trx hash
1 byte      output idx
int64        balance
string       scriptOut

~50 bytes * total unspent outputs.

If you got really fancy, then you can reduce it to perhaps 30 bytes by compressing the scryptOut field.

All of this could be implemented with the existing blockchain.

[bitfreak!]

All of this could be implemented with the existing blockchain.

Something like it can be done with the existing blockchain, such as the ultimate blockchain compression concept, but it will be a very difficult thing to do and will still never be anywhere near as efficient as this scheme unless you can find some way to perfectly compact all the transactions into a rolling blockchain similar to the mini-blockchain. The transaction data is the bulk of the data in the blockchain and the beauty of this concept is that no one has to store the full blockchain, they only need the mini-blockchain and the account tree. The account tree will eventually end up being the most bulky part of the scheme but it will still be very tiny for a very long time because it will only need to track non-empty addresses. Look at the current stats on Bitcoin for how many addresses the network has seen and then do the math. We're talking an ultra-compact alt-coin here.

[aaaxn]

So how much compression does this actually give you?

The most compression I can think of is:

20 bytes   trx hash
1 byte      output idx
int64        balance
string       scriptOut

~50 bytes * total unspent outputs.

If you got really fancy, then you can reduce it to perhaps 30 bytes by compressing the scryptOut field.

All of this could be implemented with the existing blockchain.

With account ledger you can get rid of unspent outputs. There is no such thing. You just operate on account balances. I believe that tx between already known addresses can be as small as 24 bytes + signature.

[bitfreak!]

With account ledger you can get rid of unspent outputs. There is no such thing. You just operate on account balances.

Exactly, I'm not sure bytemaster has really read the paper properly, or he isn't fully grasping it based on what he has said in this thread so far. I'm glad you seem to understand my design better than I do though. lol.

[aaaxn]

With account ledger you can get rid of unspent outputs. There is no such thing. You just operate on account balances.

Exactly, I'm not sure bytemaster has really read the paper properly, or he isn't fully grasping it based on what he has said in this thread so far. I'm glad you seem to understand my design better than I do though. lol.

Well it's because I consider it MY design, that you independently came up with. lol

[bitfreak!]

With account ledger you can get rid of unspent outputs. There is no such thing. You just operate on account balances.

Exactly, I'm not sure bytemaster has really read the paper properly, or he isn't fully grasping it based on what he has said in this thread so far. I'm glad you seem to understand my design better than I do though. lol.

Well it's because I consider it MY design, that you independently came up with. lol

lol well in reality it was more of a group effort. I had help from a lot of people, including you, to develop the idea into what it is now. But you definitely helped out the most and I will admit you deserve a lot of credit too.

[aaaxn]

With account ledger you can get rid of unspent outputs. There is no such thing. You just operate on account balances.

Exactly, I'm not sure bytemaster has really read the paper properly, or he isn't fully grasping it based on what he has said in this thread so far. I'm glad you seem to understand my design better than I do though. lol.

Well it's because I consider it MY design, that you independently came up with. lol

lol well in reality it was more of a group effort. I had help from a lot of people, including you, to develop the idea into what it is now. But you definitely helped out the most and I will admit you deserve a lot of credit too.

Of course, it was just little joke Anyway I did some work on technical details, but where can I put it? Forum is not good place for such things. Maybe you could start a wiki or do you have another idea?

[bitfreak!]

Maybe you could start a wiki or do you have another idea?

I guess I could host a wiki in a sub directory my bitfreak.info domain. I haven't actually installed a wiki before but I'm guessing it should be fairly easy to do. I was actually about to get some sleep but I'll see if I can get it installed quickly and then give you an admin account or something so you can get it set up and add your stuff to it. Give me 10 or 20 mins and I'll get back to you.

[aaaxn]

Maybe you could start a wiki or do you have another idea?

I guess I could host a wiki in a sub directory my bitfreak.info domain. I haven't actually installed a wiki before but I'm guessing it should be fairly easy to do. I was actually about to get some sleep but I'll see if I can get it installed quickly and then give you an admin account or something so you can get it set up and add your stuff to it. Give me 10 or 20 mins and I'll get back to you.

No need to hurry. I won't have time to use it until Wednesday anyway.

[stellarman]

I read the white paper again this afternoon, and a couple of ideas came to mind. I admit that I am not yet completely up to speed on all of the terminology and concepts, so the following may be impractical or even stupid questions.

As you mentioned, in Bitcoin, proof of work is the primary thing that provides security against 51% attacks. I can see that, in this mini-blockchain system, it is still necessary to have proof of work to secure the network. But I wonder whether having the proof chain in the picture might make it possible to reduce the amount of work that needs to be proved for every block in order to keep the network secure. My idea (intention) would be to keep the work/difficulty down to a level that would allow CPU mining instead of GPU. The purpose behind the intention would be to reduce the amount of wasted energy/resources that currently goes into mining (even sCrypt-based) coins with high-end GPUs. The other purpose behind the intention would be to make it realistically possible for more people to participate in mining the proposed currency, thus making it much more decentralized. Alternatively, if the amount of work that must be proved mustn't change, perhaps we could work out some modification to the sCrypt that would make it even more ASIC-resistant, and perhaps even more GPU-unfriendly -- again for the same energy/resource conserving reasons.

On the subject of coin supply, it occurs to me that, if the proposed coin were to be wildly successful and be around for many years, even a quadrillion units might not be sufficient to account for small transactions, if the value of a single coin were to reach (the future equivalent of, for example) thousands or tens of thousands of dollars. To account for this possibility (without requiring a future hard fork or a new coin) what if the coin were developed with a bit/flag to indicate the location of the decimal point? For example, if at some future time, the value of one coin became so great that it was inconvenient to price small items in milli- or micro-coins, the currency could easily do a "split", similar to a stock split. After the split, every holder of every coin would find themselves with (say) a thousand times as many coins, each of which was worth one thousandth of the former amount. No one would gain or loose any value, the prices of things would just come down, as expressed in MBC (mini-blockchain) coins. Such a split would need to be well orchestrated, so that merchants and consumers alike were prepared for the change. But, having such a mechanism already built in might save a lot of headaches in the future. There are certainly some details of this that would need to be worked out, but I thought I would throw out the idea.

If the above is completely crazy, I'm sure someone will be willing and able to point out the flaws.

Most of the rest of the whitepaper makes excellent sense to me. I'm definitely in agreement with the overall plan.

I hope we can find some good coders to help produce a trial version.

[bitfreak!]

But I wonder whether having the proof chain in the picture might make it possible to reduce the amount of work that needs to be proved for every block in order to keep the network secure. My idea (intention) would be to keep the work/difficulty down to a level that would allow CPU mining instead of GPU.

It's impossible to keep the difficulty down at a CPU-friendly level because the difficulty must shift according to the total amount of hashing power miners are throwing at the network. Without changing the difficulty in that way we cannot control the rate at which new coins are created. Obviously though we do plan to include some sort of scrypt-based mining system to make it more ASIC resistant.

To account for this possibility (without requiring a future hard fork or a new coin) what if the coin were developed with a bit/flag to indicate the location of the decimal point?

I don't think that is necessarily a good idea, the decimal point never needs to change within the protocol, it can simply be represented differently when displayed, for example you can denote BTC in mBTC etc. The reason you have so many decimal places in the first place is to account for large shifts in value, there's no need to further complicate it by shifting the decimal place within the protocol as you seem to be suggesting. One quadrillion units is certainly enough to provide sufficient granularity (but I don't see any real reason we couldn't make it much higher).

[lexxus]

Count me in as a C/Java dev.
Unfortunately I'm not experienced with current bitcoin protocol implementation, so I definitely won't be able to tech lead the development, but I'm glad to support it to the extent possible.

[stellarman]

But I wonder whether having the proof chain in the picture might make it possible to reduce the amount of work that needs to be proved for every block in order to keep the network secure. My idea (intention) would be to keep the work/difficulty down to a level that would allow CPU mining instead of GPU.

It's impossible to keep the difficulty down at a CPU-friendly level because the difficulty must shift according to the total amount of hashing power miners are throwing at the network. Without changing the difficulty in that way we cannot control the rate at which new coins are created. Obviously though we do plan to include some sort of scrypt-based mining system to make it more ASIC resistant.

Yes, I do understand the need for having a difficulty and the ability to change the difficulty. If the presence of the proof chain doesn't present a possible path to generally lower difficulties, then perhaps a change to the sCrypt that would use registers or features present in a CPU but not (currently) present in a GPU or ASIC -- or something. I don't know what the answer is, but would suggest and request that we all keep our eyes open for methods that would 1) allow for less wasted energy/resources in the mining process, and 2) keep mining more distributed. Just imagine, the MBC coin client is light enough for any and every user to easily be a full node, and the mining process is gear to make it profitable for any user to commit a processor or two to mining. I would love to see millions of small users generating a few kH/s each, instead of a few hundred (or a few dozen) huge players generating 10s of MH/s or GH/s. (As John Lennon said, "You may say I'm a dreamer..., but I'm not the only one...".)

To account for this possibility (without requiring a future hard fork or a new coin) what if the coin were developed with a bit/flag to indicate the location of the decimal point?

I don't think that is necessarily a good idea, the decimal point never needs to change within the protocol, it can simply be represented differently when displayed, for example you can denote BTC in mBTC etc. The reason you have so many decimal places in the first place is to account for large shifts in value, there's no need to further complicate it by shifting the decimal place within the protocol as you seem to be suggesting. One quadrillion units is certainly enough to provide sufficient granularity (but I don't see any real reason we couldn't make it much higher).

I see your point. So, I guess I would vote for more units from the beginning. I think lots of granularity will be useful and beneficial in the long run.

[nomailing]

But I wonder whether having the proof chain in the picture might make it possible to reduce the amount of work that needs to be proved for every block in order to keep the network secure. My idea (intention) would be to keep the work/difficulty down to a level that would allow CPU mining instead of GPU.

It's impossible to keep the difficulty down at a CPU-friendly level because the difficulty must shift according to the total amount of hashing power miners are throwing at the network. Without changing the difficulty in that way we cannot control the rate at which new coins are created. Obviously though we do plan to include some sort of scrypt-based mining system to make it more ASIC resistant.

Yes, I do understand the need for having a difficulty and the ability to change the difficulty. If the presence of the proof chain doesn't present a possible path to generally lower difficulties, then perhaps a change to the sCrypt that would use registers or features present in a CPU but not (currently) present in a GPU or ASIC -- or something. I don't know what the answer is, but would suggest and request that we all keep our eyes open for methods that would 1) allow for less wasted energy/resources in the mining process, and 2) keep mining more distributed. Just imagine, the MBC coin client is light enough for any and every user to easily be a full node, and the mining process is gear to make it profitable for any user to commit a processor or two to mining. I would love to see millions of small users generating a few kH/s each, instead of a few hundred (or a few dozen) huge players generating 10s of MH/s or GH/s. (As John Lennon said, "You may say I'm a dreamer..., but I'm not the only one...".)

Why do you think that GPU/CPU would be more energy efficient compared to ASIC's?
ASIC's are much more energy efficient. You just pay more for the custom designing/manufacturing of ASIC's, but in the end with ASIC's you have much less power consumption.

*EDIT*: So in principle you can say less power consumption would automatically mean more centralization. The only way to have both (decentralisation and power efficiency) at the same time is if you use a hybrid of proof-of-work and proof-of-stake

[bitfreak!]

Count me in as a C/Java dev.
Unfortunately I'm not experienced with current bitcoin protocol implementation, so I definitely won't be able to tech lead the development, but I'm glad to support it to the extent possible.

Excellent, even if you cannot help with core development we need as many heads as we can get on this and I appreciate the help. So far we have aaaxn and you, hopefully we'll get a few more experienced developers soon and then we can start to put something together. We also need to decide which coin we are going to start off with, I'm thinking a straight up Bitcoin fork (although Litecoin or something may be better if we plan to have scrypt-based mining).

[nomailing]

Am I correct, that mechanisms like colored coins, would not work with this kind of chain?

[bitfreak!]

Am I correct, that mechanisms like colored coins, would not work with this kind of chain?

I'm not really sure how colored coins work but my guess would be that the account tree ledger system in this scheme may not provide the facilities for colored coins.