Bitcoin Forum
March 29, 2024, 03:09:42 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 3 4 5 6 7 8 9 10 11 [All]
  Print  
Author Topic: Building the Next Generation of Crypto-Currency (developers required)  (Read 23490 times)
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
May 25, 2013, 02:22:36 PM
Last edit: December 06, 2013, 05:31:02 AM by bitfreak!
 #1

The Mini-Blockchain Project

What is this project all about?

The goal of this project is to implement a new crypto-currency protocol designed to solve the "blockchain bloat" problem once and for all by replacing the full blockchain with a finite "mini-blockchain". Such a system would offer many benefits including consistently fast synchronization times, much more block space, faster transactions, and lower fees. Certainly not an easy problem to solve, but if it could be solved we are looking at truly new and unique improvements over the Bitcoin protocol.

We now believe that this problem finally has been cracked. The concept and technical details of the proposal can be found in the white paper (a little outdated now) and the project wiki. This new scheme has been analyzed by many intelligent people and we haven't found any major flaws. After a considerable amount of feedback, myself and several others are convinced the scheme is viable and we want to attempt an implementation.

Our objectives and approach

The main objective of this project is to bring together many new ideas and concepts while staying as true to Bitcoin as possible. This project will attempt to minimize and exclude any controversial proposals and ideas but remain open to new and experimental proposals which we believe could enhance the final system. We aim to take the safe and trusted route ever possible and avoid over-complicating the scheme by bringing together too many different ideas.

The main focus of this project is to implement the mini-blockchain protocol and show that it works before we do anything else. If or when that goal is achieved we will start looking at incorporating several other experimental concepts which have the potential to provide an array of new features and benefits. Some examples of such concepts include secure 0-confirmation transactions based on a withdrawal limit system and a dynamic max block size.

Since we are trying to avoid any controversial and unnecessary complications, that means no pre-mine and probably no PoS integration. The PoS system is controversial in a way because it appears to make the rich richer over time and the benefits of such a system really aren't observable for a long time anyway. Not to mention the mini-blockchain proposal is already complicated enough as it is, keeping things simple is the key here.

The next generation of crypto-currency

What is the next generation of crypto-currency and what separates this project from any other alt coin? Most of you will agree that 95% of the alt coins out there are essentially pump and dump scams which offer nothing new or useful. I would personally say there are less than half a dozen alt coins which shouldn't be labeled scam coins; Namecoin, Devcoin, PPCoin, Novacoin, and Litecoin, and perhaps 1 or 2 other alt coins. I'm not so sure about PPCoin and Novacoin but they do offer new PoS features.

Litecoin doesn't really offer much beyond faster block confirmation speeds and scrypt-based mining, but since it was one of the first alt coins to offer these new features it has gained a genuine foothold in the crypto-currency market. Not only does this project offer a new coin with unseen features, but those new features are not small or trivial. Imagine always being able to download the blockchain within seconds or minutes as well as significantly faster transaction speeds.

Why am I making such a big deal of this? Well consider threads like this:
WARNING! Bitcoin will soon block small transaction outputs
New video: Why the blocksize limit keeps Bitcoin free and decentralized

All this concern over max block sizes, the SD "spam dust", the transaction capacity reaching its limit, all of this is nicely solved with a mini-blockchain + account tree implementation. Now I'm not saying Bitcoin is obsolete or outdated or that this new scheme will replace it, Bitcoin still has certain advantages over the mini-blockchain scheme and vice versa. However if this scheme turns out to work it does have the potential to seriously compete with bitcoin.

It was only a matter of time before someone was able to improve on the Bitcoin protocol and offer a new coin with highly desirable advantages over the original protocol, but I don't think that will mean the original will ever die out. Just because this scheme can offer more scalability and speed doesn't make it better as a tool for storing wealth. It does sort of make it better as a currency though, which is really what we should be aiming for I believe.

So how will the project be organized?

See: [BOUNTY] $20,000 Mini-Blockchain Implementation


Project Address: 1AZjrg6h9nfvFt16kaszLTJkQi13kMwZz2

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
1711724982
Hero Member
*
Offline Offline

Posts: 1711724982

View Profile Personal Message (Offline)

Ignore
1711724982
Reply with quote  #2

1711724982
Report to moderator
"Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711724982
Hero Member
*
Offline Offline

Posts: 1711724982

View Profile Personal Message (Offline)

Ignore
1711724982
Reply with quote  #2

1711724982
Report to moderator
1711724982
Hero Member
*
Offline Offline

Posts: 1711724982

View Profile Personal Message (Offline)

Ignore
1711724982
Reply with quote  #2

1711724982
Report to moderator
NickCoin
Member
**
Offline Offline

Activity: 115
Merit: 10



View Profile
May 25, 2013, 04:45:42 PM
 #2

This idea sounds great, would love to be part of it as the designer!
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
May 25, 2013, 05:28:07 PM
 #3

There is potentially synergy between this blockchains features an my economic model for offering a crypto-USD, crypto-GOLD, etc that maintains near parity without having any counter party risk.   If a new chain were to be created I believe it should include as many 'good ideas' as possible because we will be stuck with it for a while if it works.

I will investigate your proposal and would appreciate if you would investigate my p2p bank/exchange system.


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
May 25, 2013, 05:57:38 PM
Last edit: May 25, 2013, 06:58:17 PM by bitfreak!
 #4

There is potentially synergy between this blockchains features an my economic model for offering a crypto-USD, crypto-GOLD, etc that maintains near parity without having any counter party risk.   If a new chain were to be created I believe it should include as many 'good ideas' as possible because we will be stuck with it for a while if it works.

I will investigate your proposal and would appreciate if you would investigate my p2p bank/exchange system.
I actually took a look at your thread a few hours ago and your idea seems fairly complex. I would recommend writing a white paper or something. While I agree it may be beneficial to mix together as many good ideas as possible it's still problematic. At this point my goal is simply to just implement this mini-blockchain scheme to see if it actually works. The job is already difficult enough and I don't want to go including all these other untested ideas, it will just make the process longer and harder. As I said, the goal of this project is really just to stay as close to the bitcoin protocol as possible and just play it safe. I would recommend the same thing with your project as well, first just build it as you imagine it and see if it actually performs as you believe it will. When you try to start off with too much on your plate it can often lead you to troubles. At some later point maybe we can have a mini-blockchain + PoS + your exchange model (although I'm still skeptical of the PoS stuff and I'd need to understand your proposal better for actually backing it), but right now that isn't the best course of action to take in my opinion.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
May 25, 2013, 06:16:58 PM
 #5

There is potentially synergy between this blockchains features an my economic model for offering a crypto-USD, crypto-GOLD, etc that maintains near parity without having any counter party risk.   If a new chain were to be created I believe it should include as many 'good ideas' as possible because we will be stuck with it for a while if it works.

I will investigate your proposal and would appreciate if you would investigate my p2p bank/exchange system.

Not to derail your design, but it is very complex (perhaps more-so than necessary).

Given the current bitcoin block chain, you can deterministically generate the min set of all 'outputs' that are still valid.  This will generate a very small list (compared to the block chain).  This list would include the hash of the transaction + the output index + script + balance + block num.   It would drop all of the inputs to the transaction and all spent outputs.  Furthermore, outputs with 'identical scripts' could in theory be compressed into a deterministic lookup table.

The hash of this list could then be included in the merkle tree of the existing block chain.  Because all nodes can deterministically calculate the same list they can all validate the hash of the list as part of the block-chain validation.

Anyone can then fetch this list and have just as much confidence in the validity of the outputs as anyone who had the full block chain.   All that would be required is to store the block-headers for the full chain + the output summary list of your 'origin' + however many blocks with full transactions you feel you need.

Thus a light-weight client could constantly prune transaction history and just keep 120 blocks, while full up banks could hold the entire chain for all of history.  

I believe this solution would be cheaper, easier, and more flexible than your solution.  It requires no significant changes to bitcoin other than generating a deterministic output summary and hashing it and then including that hash in the merkel tree.  The table could be trusted by all because otherwise the block would have been rejected by other nodes.

Such a change to bitcoin would be so 'small' that it could probably be implemented with a well-planned hard-fork.  The hard fork being validating the 'summary hash' as part of block verification.  That said, it could be a soft-fork that only miners need to be aware of because blocks could still be generated that would be accepted by old and new clients and miners supporting the new feature could only accept blocks with valid 'summary hashes' or blocks with 'no summary hashes' and then new clients could trim the block chain at any block that includes a valid summary hash.  This would only require proof that 90% of the past 10000 blocks contain valid summary hashes to be sure that no block with an invalid summary hash could possibly make it into the longest chain without sustained 51% attack.  Once 90% of miners are including valid summary hashes, they can start rejecting blocks (and miners) that do not include it.

I will probably implement this as part of BitShare currency rather than your proposed approach... that is unless you can show me something I am missing.





https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
May 25, 2013, 06:28:48 PM
 #6

Quote
Not to derail your design, but it is very complex (perhaps more-so than necessary).
Well I'm not sure what you just said is any less complex, it certainly confused me. But if what you are saying is valid, you are claiming that a small change to the existing Bitcoin protocol can basically provide something similar to a finite mini-blockchain? I'm certainly very skeptical about that, I don't think my system is overly complex, I believe it has the minimum components required to make the mini-blockchain scheme secure and robust.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
May 25, 2013, 06:44:38 PM
 #7

There is potentially synergy between this blockchains features an my economic model for offering a crypto-USD, crypto-GOLD, etc that maintains near parity without having any counter party risk.
Based on this statement I'm not convinced that you understand counterparty risk.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
May 25, 2013, 06:57:05 PM
 #8

Ok, I can summarize my solution as such:

Given the bitcoin blockchain C define a deterministic function F(C) that generates an output index  I

I = F(C)

Then include SHA256(I) in the merkel tree when you generate block B.

To validate block B + 1 the 'brute force' way you would calculate  SHA256(F(C+B)) and verify it exists in the the merkel tree.

To do it the 'easy way', you would remove all outputs from I that are consumed by inputs in B and then add all outputs in B to I.  This would be 'cheap' and then you can do SHA256(I+ delta from B) and then validate the result exists in the merkel tree.

Bitcoin already operates based upon an index of outputs.  The problem is that these outputs are tied to a transaction which has to be kept around to lookup the output.  The transaction (being the smallest prunable unit) includes other spent outputs + inputs and input scripts most of which is not relevant.  A transaction cannot be pruned until all of its outputs are spent.

I would design F(C) to generate the following table

TRX_HASH,  OUTPUT_NUM,  SPEND_SCRIPT, BLOCK_NUM, AMOUNT

Then sort it by TRX_HASH + OUTPUT_NUM to get a deterministic (and log(n) searchable) index.

The effort to create F(C) is probably 8 man hours (max).   The effort to create a method to implement I+B such that I+B = F(C+B) would probably be less than 4 man hours.

Including the resulting SHA256(I) in the merkel tree perhaps 4 hours.
Validating the merkel tree... 4 hours.

Thus I suspect the total implementation time required to enable pruning of all transaction history is less than 1 week for the backend / miners.   Then individual clients could pick when they want to start trusting I vs the long tail of C.  I suspect that 10,000 blocks is enough for just about anyone.  

You cannot hack nor replace outputs even with a 51% attack and thus it is entirely secure.    

The level of compression offered by your approach would be *slightly* better because it would collapse all outputs with an identical SPEND_SCRIPT into a single entry and I could not do that because transaction inputs must reference a valid output.   However, I suspect your system requires maintaining much more complex hash chains, merkel account trees, and other data structures that take up space.  Breaking backward compatibility would also be a downside.




https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
May 25, 2013, 07:00:06 PM
 #9

There is potentially synergy between this blockchains features an my economic model for offering a crypto-USD, crypto-GOLD, etc that maintains near parity without having any counter party risk.
Based on this statement I'm not convinced that you understand counterparty risk.

Counter-party risk is depending upon someone else to be willing and able to honor a promise to pay.

Trading goods on the market is not counter-party-risk.  It is instead 'exchange risk' which is different.

Creating market forces that push two goods toward parity value can minimize exchange risk without introducing counter-party-risk.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
May 25, 2013, 07:12:58 PM
 #10

Well unfortunately math is not my strongest talent so you kind of lost me with that, but it seems like you may be onto something. What you are saying seems some what similar to the other rolling chain solution I mentioned in my paper. I hope it actually is possible to implement something like this on top of bitcoin, that will give me much more faith in the long term future of bitcoin.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 01, 2013, 09:02:24 AM
 #11

Ok, I can summarize my solution as such:

Given the bitcoin blockchain C define a deterministic function F(C) that generates an output index  I

I = F(C)

Then include SHA256(I) in the merkel tree when you generate block B.

To validate block B + 1 the 'brute force' way you would calculate  SHA256(F(C+B)) and verify it exists in the the merkel tree.

To do it the 'easy way', you would remove all outputs from I that are consumed by inputs in B and then add all outputs in B to I.  This would be 'cheap' and then you can do SHA256(I+ delta from B) and then validate the result exists in the merkel tree.

Bitcoin already operates based upon an index of outputs.  The problem is that these outputs are tied to a transaction which has to be kept around to lookup the output.  The transaction (being the smallest prunable unit) includes other spent outputs + inputs and input scripts most of which is not relevant.  A transaction cannot be pruned until all of its outputs are spent.

I would design F(C) to generate the following table

TRX_HASH,  OUTPUT_NUM,  SPEND_SCRIPT, BLOCK_NUM, AMOUNT

Then sort it by TRX_HASH + OUTPUT_NUM to get a deterministic (and log(n) searchable) index.

The effort to create F(C) is probably 8 man hours (max).   The effort to create a method to implement I+B such that I+B = F(C+B) would probably be less than 4 man hours.

Including the resulting SHA256(I) in the merkel tree perhaps 4 hours.
Validating the merkel tree... 4 hours.

Thus I suspect the total implementation time required to enable pruning of all transaction history is less than 1 week for the backend / miners.   Then individual clients could pick when they want to start trusting I vs the long tail of C.  I suspect that 10,000 blocks is enough for just about anyone.  

You cannot hack nor replace outputs even with a 51% attack and thus it is entirely secure.    

The level of compression offered by your approach would be *slightly* better because it would collapse all outputs with an identical SPEND_SCRIPT into a single entry and I could not do that because transaction inputs must reference a valid output.   However, I suspect your system requires maintaining much more complex hash chainhttps://bitcointalk.org/index.php?topic=195275.msg2289285#msg2289285s, merkel account trees, and other data structures that take up space.  Breaking backward compatibility would also be a downside.

You can't expect to hash list of all outputs after every blockchain modification. It is several GB of data. UTXO would need to be stored in some kind of hash tree. It was already discussed and it would work.
https://bitcointalk.org/index.php?topic=88208.0

Problem is that it doesn't solve blockchain size problem, because mining node still needs to hold entire blockchain history. With bitfreak design no one would need to do it.
Furthermore account balances enables more nice features. I posted it in white-paper thread
here: https://bitcointalk.org/index.php?topic=195275.msg2083026#msg2083026
https://bitcointalk.org/index.php?topic=195275.msg2083400#msg2083400
https://bitcointalk.org/index.php?topic=195275.msg2289285#msg2289285

EDIT: You now what is greatest problem with improving bitcoin? Mining pools cartel run this thing now and they won't support any changes that will hurt their business in any way.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 01, 2013, 09:15:41 AM
 #12

Apparently bytemaster's idea isn't going to work out like he had hoped. He posted this in his BitShare Economic Theory thread a little while ago:

The only way to make BitShares work anything close to what I had dreamed would require users to post collateral in excess of the current exchange rate to create crypto-GLD (closer to Version 1.0)

Why didn't I see this before?  I was looking at small 'incremental' rises that would push it up and then extrapolating wrong.  I was thinking that individuals who 'wanted interest bearing USD' would pay a premium to get the return, and therefore cover losses.  It might work for small movements, but certainly not for large ones.

Why couldn't anyone convince me before?  Because no one could explain it in such simple terms.

I'm now trying to persuade him to join this project.  Wink

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 01, 2013, 09:52:20 AM
 #13

It looks like digitalindustry might have also given up on his PoS + Mini-Blockchain project because he nows appears to be managing the nibble alt-coin. It appears to be just another run of the mill coin that offers nothing new. One thing about it did catch my attention though:
Quote
Ascending reward system that proved effective and prevented insta-mining, pre-mining, unfair rewards for early adopters.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
Impaler
Sr. Member
****
Offline Offline

Activity: 826
Merit: 250

CryptoTalk.Org - Get Paid for every Post!


View Profile
June 01, 2013, 12:21:47 PM
 #14

Why not implement your new protocol on top of Terracoin, TRC is basically a strait BTC clone so your staying close to its code as you said you wanted to.  And it would be an excellent dry run so to speak for bringing the feature to BTC some day.  From what I've heard TRC would be friendly to trying out such a feature as it exists to do this kind of experimentation.  I always recommend people look to expand on existing coins rather then make new ones so we see less fragmentation of the ecosystem.

 
                                . ██████████.
                              .████████████████.
                           .██████████████████████.
                        -█████████████████████████████
                     .██████████████████████████████████.
                  -█████████████████████████████████████████
               -███████████████████████████████████████████████
           .-█████████████████████████████████████████████████████.
        .████████████████████████████████████████████████████████████
       .██████████████████████████████████████████████████████████████.
       .██████████████████████████████████████████████████████████████.
       ..████████████████████████████████████████████████████████████..
       .   .██████████████████████████████████████████████████████.
       .      .████████████████████████████████████████████████.

       .       .██████████████████████████████████████████████
       .    ██████████████████████████████████████████████████████
       .█████████████████████████████████████████████████████████████.
        .███████████████████████████████████████████████████████████
           .█████████████████████████████████████████████████████
              .████████████████████████████████████████████████
                   ████████████████████████████████████████
                      ██████████████████████████████████
                          ██████████████████████████
                             ████████████████████
                               ████████████████
                                   █████████
CryptoTalk.org| 
MAKE POSTS AND EARN BTC!
🏆
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 01, 2013, 12:33:46 PM
 #15

Why not implement your new protocol on top of Terracoin
...
I always recommend people look to expand on existing coins rather then make new ones
Unfortunately the scheme can't be built on top of an existing blockchain scheme. The closest thing to something like that is the "ultimate blockchain compression" scheme. We were just talking about how this scheme is quite similar to the ultimate blockchain compression scheme in the white paper thread. It is very similar but because we're not trying to apply a change on top of an existing blockchain scheme we can leave out many unnecessary features and make it more efficient than the ultimate blockchain compression scheme. I did start off looking for ways to improve the Bitcoin blockchain but eventually I ended up designing this whole new scheme.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
stellarman
Newbie
*
Offline Offline

Activity: 60
Merit: 0


View Profile
June 01, 2013, 12:40:11 PM
 #16

There is potentially synergy between this blockchains features an my economic model for offering a crypto-USD, crypto-GOLD, etc that maintains near parity without having any counter party risk.   If a new chain were to be created I believe it should include as many 'good ideas' as possible because we will be stuck with it for a while if it works.

I will investigate your proposal and would appreciate if you would investigate my p2p bank/exchange system.
I actually took a look at your thread a few hours ago and your idea seems fairly complex. I would recommend writing a white paper or something. While I agree it may be beneficial to mix together as many good ideas as possible it's still problematic. At this point my goal is simply to just implement this mini-blockchain scheme to see if it actually works. The job is already difficult enough and I don't want to go including all these other untested ideas, it will just make the process longer and harder. As I said, the goal of this project is really just to stay as close to the bitcoin protocol as possible and just play it safe. I would recommend the same thing with your project as well, first just build it as you imagine it and see if it actually performs as you believe it will. When you try to start off with too much on your plate it can often lead you to troubles. At some later point maybe we can have a mini-blockchain + PoS + your exchange model (although I'm still skeptical of the PoS stuff and I'd need to understand your proposal better for actually backing it), but right now that isn't the best course of action to take in my opinion.

+1. I think we need a "proof-of-concept" implementation first. Then think about tying this to other ideas.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 02, 2013, 06:53:13 AM
 #17

+1. I think we need a "proof-of-concept" implementation first. Then think about tying this to other ideas.
Yes exactly, I'm fairly confident in the idea but we can't be 100% sure that the concept will work as we except it to. That's why I just want to leave out all the extra stuff for now, so we can focus on what is important and get it done as quickly as possible.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
scooter
Member
**
Offline Offline

Activity: 100
Merit: 10


View Profile
June 02, 2013, 08:00:46 AM
 #18

First altcoin proposal that truly looks interesting to me.
Looking forward to following your progress.
tom1
Full Member
***
Offline Offline

Activity: 130
Merit: 100



View Profile
June 02, 2013, 08:17:31 AM
 #19

Wouldn't it be better to improve Bitcoin rather than creating a new currency?

nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 02, 2013, 02:32:37 PM
 #20

Wouldn't it be better to improve Bitcoin rather than creating a new currency?

The problem with the increasing blockchain size is within the bitcoin protocol itself. As mentioned in the white paper there is the thread about 'ultimate blockchain compression' for bitcoin. But it is by far not as good as this new proposed coin. It only tries to fix some effects without really fixing the underlying problem. If you have a proposal, which could improve the existing bitcoin protocol which is comparable to the performance of this proposal here, then everyone would definately like to hear it.

This new coin proposed by bitfreak is really designed from a new perspective to reduce the bloat which we see in BTC. So I think it really deserves to be implemented and tested!

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

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 02, 2013, 02:44:28 PM
Last edit: June 02, 2013, 02:58:19 PM by bitfreak!
 #21

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

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 03:19:55 PM
 #22

Quote
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


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 02, 2013, 03:36:45 PM
 #23

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.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 02, 2013, 03:37:10 PM
 #24

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.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 02, 2013, 03:49:33 PM
Last edit: June 02, 2013, 04:59:13 PM by bitfreak!
 #25

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

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 05:43:02 PM
 #26

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.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 02, 2013, 06:08:46 PM
 #27

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

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 06:29:16 PM
 #28

Quote
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 Grin


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 02, 2013, 06:44:11 PM
 #29

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

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 06:54:43 PM
 #30

Quote
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 Grin
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 Smiley 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?


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 02, 2013, 07:29:31 PM
 #31

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

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 02, 2013, 07:36:01 PM
 #32

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


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
stellarman
Newbie
*
Offline Offline

Activity: 60
Merit: 0


View Profile
June 03, 2013, 01:18:48 AM
 #33

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! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 03, 2013, 09:34:37 AM
Last edit: June 03, 2013, 09:58:12 AM by bitfreak!
 #34

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

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

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 03, 2013, 11:53:08 AM
 #35

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
Newbie
*
Offline Offline

Activity: 60
Merit: 0


View Profile
June 03, 2013, 12:14:11 PM
 #36

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

Quote
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
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 03, 2013, 01:12:55 PM
 #37

Quote
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

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 03, 2013, 01:21:19 PM
 #38

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

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 03, 2013, 01:58:17 PM
 #39

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

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 03, 2013, 02:47:00 PM
 #40

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.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 03, 2013, 06:00:47 PM
 #41

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.
Account ledger does not keep track of coins so you can't do it exactly same as in bitcoin. If it would be really needed then nothing stop us from creating special colored accounts which can only move coins to other accounts of same color or to new empty accounts which are colored upon creation, but... I don't see reason to worry about it now. We need to implement basic system first.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 03, 2013, 06:38:31 PM
 #42

but... I don't see reason to worry about it now. We need to implement basic system first
Agreed.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 03, 2013, 08:57:13 PM
 #43

Although the basic implementation is itself a chanlenge, I would still try to keep in a backlog possible advanced features like multi-sig transactions, zero-coin like strong privacy, etc.

I also would like to look into the differences between Account Tree and Ripple Ledger structures as they seem to have something in common.
stellarman
Newbie
*
Offline Offline

Activity: 60
Merit: 0


View Profile
June 04, 2013, 02:36:46 AM
 #44

zero-coin like strong privacy, etc.

In case you are not familiar with it, zero-coin is a very interesting proposal by a very smart guy. See his blog entry about zero-coin here: http://blog.cryptographyengineering.com/2013/04/zerocoin-making-bitcoin-anonymous.html

In a nutshell, zero-coin is an extension for BTC that allows for completely anonymous transactions.

It occurs to me that having the account tree as a separate module might actually make implementing zero-coin easier than with BTC.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 04, 2013, 07:39:38 AM
 #45

It occurs to me that having the account tree as a separate module might actually make implementing zero-coin easier than with BTC.
Based on my rather poor understanding of zerocoin I would say that you are correct because you could create special zerocoin accounts in the account tree or something along those lines. But the implementation of such a system would probably increase the rate of growth of the account tree by a lot, and this scheme does provide a bit of extra anonymity already.

On an unrelated note, I found this new forum advertisement kind of ironic:
"I'm sure that in 20 years there will either be very large transaction volume or no volume." -- Satoshi

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 05, 2013, 09:07:56 PM
Last edit: June 05, 2013, 09:25:54 PM by aaaxn
 #46

I think we can get secure coin laundry without complications of zero coin with Chaum's blind signatures.

It seems complicated, but from user point of view it can be just special button 'Send anonymously' which would automatically divide specified sum into mixing intentions, send it to network and claim tickets. It would cost more than standard transfers to cover additional network load. Its main disadvantage is that if you won't claim your tickets in time you can loose your money.

First let's define Mixing Set.
Mixing Set consists of header and list of inputs to mix. Header includes:
- mixing denomination (1 coin, 100 coin, etc)
- mixing size (how many inputs)
- mixing public key
- time available for ticket redeeming
- input coins used as collateral

Mixing parameters should be standardized so it would be easier to find matching inputs.

Users sends to network intentions to mix which include
- sufficient amount of coins (denomination + fee)
- requested denomination
- requested minimum mixing size
- requested ticket redeeming window
- blinded mixing ticket = blind(random string + payout address). We need random string so every ticket is unique.

Miners monitor received mixing intentions and if miner find set which can be used for creating Mixing Set he can create one.
Miner generates new key pair just for single Mixing Set and includes this key in header. With this key he make blind signatures of all mixing tickets and include such transaction in block.
When Mixing Set is included coins are taken from all participants but are not deposited anywhere.

All mixing participants can now see that their mixing intentions were included in blockchain. They unblind their tickets and with it create output transactions against Mixing Set (their tickets are signed with blocks private key).
Redeem transactions can be included in any next block until redeeming time is up.
When redeeming is over we can have 3 outcomes
- there was less redeemed tickets than input. In this case outputs are credited normally and creator of Mixing Set gets free money.
- all tickets was redeemed. Outputs are credited normally.
- there was more redeemed tickets than inputs. This mean creator of Mixing Set cheated so he looses his collateral (miner who mined block containing first extra ticket gets it) and money is returned to senders. Users can't ever loose their money.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
BitcoinAshley
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
June 06, 2013, 02:14:53 AM
 #47

Great proposal, I will donate to the bounty.

-Including a zerocoin-esque feature would be great, even if it's just what aaaxn described above. 
-Including certain features commonly requested in BTC would be great. Throwing Coin Control into the GUI, perhaps M of N support, etc.
-Heck, going the extra mile and throwing in cold wallet support in the GUI (like Armory) would give people even MORE reason to celebrate an alt-coin that is NOT just a copy-pasta with a couple minor changes.

I realize it's quite the laundry list, and all you really want to to is try out this new blockchain idea, which is a great idea, but also think of the potential success of an cryptocoin that really "Gets it right" - not just with one major innovation, but that major innovation with a few key features that folks are really looking for.

If you release a copy of the bitcoin-qt/litecoin-qt client with the only change being the smaller blockchain... well, it'll be simple, but it won't stand out quite as much as if you spend some time putting in some great features that people have been asking for in BTC for a while.

The problem with alt-coins is not just that they are copypasta of the bitcoin concept, but also that they are copypasta of the CODE, complete with spaghettification and ugly external dependencies and magic numbers. Many people have called for completely reconfiguring it to comply with good coding practices, and reduce the risk of nasty bugs that might show up later on. I know this is not your intention, to change too much at once, but anything you can do to this effect would be welcomed by the alt-coin community who, after FTC and CNC, have had it up to here with pointless copypasta introduced entirely for speculation. I think if I run another ______-qt executable that shows the same flash screen, same GUI, with no new features... I will facepalm. Grin A major back-end change like what you've proposed with the blockchain almost makes it forgivable. Grin



maco
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
June 06, 2013, 06:24:29 AM
 #48

Great recommendations BitcoinAshley. I have to concur with the following quote.

I am also a C++/C# and Web/Database Developer.. Oracle, Java, JavaScript, SQL, etc..

What area do you need others involved in and how many do you have on-board now?

Great proposal, I will donate to the bounty.

-Including a zerocoin-esque feature would be great, even if it's just what aaaxn described above. 
-Including certain features commonly requested in BTC would be great. Throwing Coin Control into the GUI, perhaps M of N support, etc.
-Heck, going the extra mile and throwing in cold wallet support in the GUI (like Armory) would give people even MORE reason to celebrate an alt-coin that is NOT just a copy-pasta with a couple minor changes.

I realize it's quite the laundry list, and all you really want to to is try out this new blockchain idea, which is a great idea, but also think of the potential success of an cryptocoin that really "Gets it right" - not just with one major innovation, but that major innovation with a few key features that folks are really looking for.

If you release a copy of the bitcoin-qt/litecoin-qt client with the only change being the smaller blockchain... well, it'll be simple, but it won't stand out quite as much as if you spend some time putting in some great features that people have been asking for in BTC for a while.

The problem with alt-coins is not just that they are copypasta of the bitcoin concept, but also that they are copypasta of the CODE, complete with spaghettification and ugly external dependencies and magic numbers. Many people have called for completely reconfiguring it to comply with good coding practices, and reduce the risk of nasty bugs that might show up later on. I know this is not your intention, to change too much at once, but anything you can do to this effect would be welcomed by the alt-coin community who, after FTC and CNC, have had it up to here with pointless copypasta introduced entirely for speculation. I think if I run another ______-qt executable that shows the same flash screen, same GUI, with no new features... I will facepalm. Grin A major back-end change like what you've proposed with the blockchain almost makes it forgivable. Grin




lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 06, 2013, 08:34:43 AM
 #49

I think we could leverage on a few libraries/technologies as a building blocks:

We could usde zeromq as a basic commnuncation library
DHT for client discovery and additional data storage (libtorrent?)
A lightweight (non-sql?) database for account tree and mini-blockhain indexing (leveldb?)

Also I would love to see a Turing-complete yet secure language for scripts.

It would be good to separate a project into several modules like connectivity, account tree, mini blockchain and assign them to different developers so we can start working on them in parallel.

PS: The last thing I want is to start a flame war on programming languages, but I would give a little time to consider other languages like Java/C#/Python/Ruby instead of C/C++ for the reference implementation.
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 08:55:26 AM
 #50

In theory we should avoid using bitcoin source, because it's a mess, but it also represents massive amount of work and it wouldn't be so easy to implement such thing from scratch.
Ideally conformal will finish their bitcoin implementation in Go (https://blog.conformal.com/) and we could base on that. It seems to be nicely abstracted and use much nicer language than C++. That would really speed up development.

Quote
Also I would love to see a Turing-complete yet secure language for scripts.
Idea is to drop scripts and replace it with transaction/account types defined in source, so tx would be Turing-complete, but each new type would need to be accepted by majority.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 06, 2013, 09:32:04 AM
Last edit: June 06, 2013, 09:51:04 AM by bitfreak!
 #51

Great proposal, I will donate to the bounty.

-Including a zerocoin-esque feature would be great, even if it's just what aaaxn described above.
-Including certain features commonly requested in BTC would be great. Throwing Coin Control into the GUI, perhaps M of N support, etc.
-Heck, going the extra mile and throwing in cold wallet support in the GUI (like Armory) would give people even MORE reason to celebrate an alt-coin that is NOT just a copy-pasta with a couple minor changes.
The ability for zerocoin-like anonymity and also the ability conduct secure 0-confirmation transactions are definitely two things at the top of the to-do list after we get a working implementation. The GUI can always be made more complex as we move along so I don't think that should be of particularly large concern right now. But I do feel what you are saying, the Bitcoin GUI could definitely use some more features, especially the ability to easily import private keys.

Thanks for the donation btw, every little bit helps.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 06, 2013, 09:40:20 AM
 #52

In theory we should avoid using bitcoin source, because it's a mess, but it also represents massive amount of work and it wouldn't be so easy to implement such thing from scratch.
Ideally conformal will finish their bitcoin implementation in Go (https://blog.conformal.com/) and we could base on that. It seems to be nicely abstracted and use much nicer language than C++. That would really speed up development.majority.
C++ may not be the nicest language but it is the fastest and Satoshi made Bitcoin in C++ for a reason. Remember the goal of this project is to try and take the safe road, stick as close to Bitcoin as possible. Using an entirely new Go implementation which has just been built from the ground up is simply for asking for trouble. Maybe if it had already been tested for a year or two I would go for it but at this point I would be strongly against such a plan. It can't be that hard to work with the C++ code considering how many Bitcoin variants now exist. Even if the code really is as bad as some people make it out to be, at least we know it's tested and secure with many years of operation in the wild. Plus there is probably way more information and references concerning the default implementation, at the end of the day it'll probably be easier to fork a C++ implementation such as Litecoin and alter the code to fit our needs.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 10:13:51 AM
 #53

C++ may not be the nicest language but it is the fastest and Satoshi made Bitcoin in C++ for a reason. Remember the goal of this project is to try and take the safe road, stick as close to Bitcoin as possible. Using an entirely new Go implementation which has just been built from the ground up is simply for asking for trouble. Maybe if it had already been tested for a year or two I would go for it but at this point I would be strongly against such a plan. It can't be that hard to work with the C++ code considering how many Bitcoin variants now exist. Even if the code really is as bad as some people make it out to be, at least we know it's tested and secure with many years of operation in the wild. Plus there is probably way more information and references concerning the default implementation, at the end of the day it'll probably be easier to fork a C++ implementation such as Litecoin and alter the code to fit our needs.
Yeah bitcoin is tested so it works good as bitcoin. You know what is the problem with messy code-base? Any little change can cause some serious bugs. And we are not planning to do little changes. After our modification extensive testing would need to be done no matter on what code we will base it.
I don't insist on btcd, they won't probably finish anytime soon anyway.
Litecoin developers recently announced they are doing some serious work around their code so i may be good choice.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 06, 2013, 10:17:42 AM
 #54

Any little change can cause some serious bugs. And we are not planning to do little changes.
That is a valid point but we will still be able to re-use a fairly large portion of the existing code base because many things will stay the same. I also think we need to keep in mind the speed factor, how fast is the Go language?

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 06, 2013, 11:23:59 AM
 #55

Love the project. New features are key.

Here is what I would like to see:

1) proof-of-stake

There are multiple reasonable ways of doing this. Once I understand your design better, I'll suggest some simple proof-of-stake system that is compatible with your approach.

2) reduced blockchain size

What you are doing sounds great. I will be reading and thinking about your paper carefully. Don't stop here though.

3) improved wallet security

Basic idea is an account with restricted authority. You could keep the account online 24/7 without risking loss of all its coins. You would not need to mess with paper wallets under normal circumstances. This would make a hot wallet almost as safe as a bank account.

This account does the following:
a) specifies a single trusted address when it first receives coins (the address cannot be changed subsequently, address could belong to an online service provider, an offline paper wallet, a friend, whatever)
b) specifies an amount of coins, x, when it first receives coins. Account can send x coins per month (or week) to any address. Once this limit is up, further spending is not possible with one exception.
c) emergency withdrawal; account can send any amount of funds to its unique trusted address at any time.


4) zero-conf txns

I suggested something for zero-conf txns here: http://www.reddit.com/r/CryptoCurrency/comments/1evxuk/how_toalt_coin_with_secure_zeroconf_txns/
I think aaaxn must have proposed something similar. Aaaxn, what's the link for your idea again?


BTW 2864285 is cunicul keyed into a touchtone phone
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 11:59:54 AM
 #56

4) zero-conf txns

I suggested something for zero-conf txns here: http://www.reddit.com/r/CryptoCurrency/comments/1evxuk/how_toalt_coin_with_secure_zeroconf_txns/
I think aaaxn must have proposed something similar. Aaaxn, what's the link for your idea again?


BTW 2864285 is cunicul keyed into a touchtone phone

Generally my idea is in principles similar to yours. It uses account withdrawal limit to ensure that offender cannot empty his account in alternate chain in less than 6 blocks so honest transaction still can be included even after 5 block chain reorganization. This is coupled with double spend detecting and punishment. Detail needs to be ironed out yet but I think it would work. I am currently exploring idea to make this thing working universally for all accounts by prioritizing small payments over large. Large payments wouldn't be executed at moment of inclusion in blocks but later. If in mean time some smaller transaction were included big tx is cancelled. Result would be that small payments (for less than 1/6 account) would be instant while larger would take more than 6 blocks to confirm. I don;t have details yet.

Description is added to wiki.
http://bitfreak.info/mbc-wiki/index.php?title=Secure_0-confirmation_transactions
http://bitfreak.info/mbc-wiki/index.php?title=Punishing_double-spending

BTW We should really name this project. It don't need to be final name. Maybe evercoin [like coin sustainable for ever;]?


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 06, 2013, 12:07:12 PM
 #57

Love the project. New features are key.

Here is what I would like to see:

1) proof-of-stake

There are multiple reasonable ways of doing this. Once I understand your design better, I'll suggest some simple proof-of-stake system that is compatible with your approach.
+1
I hope this will be a priority, because the concepts of proof-of-stake are now available and working. It just doesn't make sense to further waste energy and resources. Why would someone want to create a new alt-coin with inferior techniques if new ones are available?
*EDIT* you could even use this approach to implement incentives to not have too many different addresses in the account tree, right?

Just another thougth (don't know if it was mentioned before):
The mini-blockchain has also the advantage that new blocks can be propagated through the network much faster because it just needs to propagate the proof cell(~ 100 byte) without propagating all transactions (~1 MB). So it should be 10000 times faster to propagate. Of course you would have to wait a little until you see the included transactions, but to start mining the next block it would be enough to have the proof cell... Is that correct?

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 06, 2013, 12:09:14 PM
 #58

Any little change can cause some serious bugs. And we are not planning to do little changes.
That is a valid point but we will still be able to re-use a fairly large portion of the existing code base because many things will stay the same. I also think we need to keep in mind the speed factor, how fast is the Go language?

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow

aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 12:10:52 PM
 #59

+1
I hope this will be a priority, because the concepts of proof-of-stake are now available and working. It just doesn't make sense to further waste energy and resources. Why would someone want to create a new alt-coin with inferior techniques if new ones are available?

Just another thougth (don't know if it was mentioned before):
The mini-blockchain has also the advantage that new blocks can be propagated through the network much faster because it just needs to propagate the proof cell(~ 100 byte) without propagating all transactions (~1 MB). So it should be 10000 times faster to propagate. Of course you would have to wait a little until you see the included transactions, but to start mining the next block it would be enough to have the proof cell... Is that correct?
If that would work then Bitcoin could propagate just block header and achieve same thing. Problem is that without block contents you cannot verify if block is valid and without knowing included transactions you can't start working on next block.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 06, 2013, 12:13:46 PM
 #60

+1
I hope this will be a priority, because the concepts of proof-of-stake are now available and working. It just doesn't make sense to further waste energy and resources. Why would someone want to create a new alt-coin with inferior techniques if new ones are available?

Just another thougth (don't know if it was mentioned before):
The mini-blockchain has also the advantage that new blocks can be propagated through the network much faster because it just needs to propagate the proof cell(~ 100 byte) without propagating all transactions (~1 MB). So it should be 10000 times faster to propagate. Of course you would have to wait a little until you see the included transactions, but to start mining the next block it would be enough to have the proof cell... Is that correct?
If that would work then Bitcoin could propagate just block header and achieve same thing. Problem is that without block contents you cannot verify if block is valid and without knowing included transactions you can't start working on next block.

But that's the whole idea of the proof-chain. You can verify the proof-of-work without needing the whole block.
Of cause if you start mining the next block and you just have the previous proof-cell and not the transactions, you could only include transactions which are not very old to be sure that they were not already included in the previous block.

*EDIT* it could happen that the last block is invalid, but the probability for that is quite low. Why would anyone try to mine an invalid block, because after a few seconds/minutes everyone has all block contents and would discard the block.

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 12:14:49 PM
 #61

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow
I would add that application have typically only small portion of code which must be really optimized (in bitcoin it is probably tx verification) and if our coin would become so widely used so that would become bottleneck this small part can always be rewritten in C without modifying anything else.

But that's the whole idea of the proof-chain. You can verify the proof-of-work without needing the whole block.
Of cause if you start mining the next block and you just have the previous proof-cell and not the transactions, you could only include transactions which are not very old to be sure that they were not already included in the previous block.
Yes you can verify proof of work, but you cannot verify what node was working on Wink
If you don't know which tx were included in previous block you cannot verify if tx is valid (maybe account was emptied in previous block?) and you don't have previous ledger state so cannot compute new ledger state for next block.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
Anon136
Legendary
*
Offline Offline

Activity: 1722
Merit: 1217



View Profile
June 06, 2013, 12:20:59 PM
 #62

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 12:24:49 PM
 #63

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.
Blockchain bloat is not only about storage. Every node must verify every tx ever done from block 0 in order to synchronize with network it can take a lot of time. As for tps limit I think we can make single transaction significantly smaller than in bitcoin (2-3x reduction for average tx) so we can get more tps with same block size limit.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 06, 2013, 12:55:20 PM
 #64


blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 06, 2013, 12:57:53 PM
 #65

Any little change can cause some serious bugs. And we are not planning to do little changes.
That is a valid point but we will still be able to re-use a fairly large portion of the existing code base because many things will stay the same. I also think we need to keep in mind the speed factor, how fast is the Go language?

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow


Yes, it is certainly a problem.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 06, 2013, 01:01:58 PM
 #66

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.
The Bitcoin client is artificially limited to 7 tps because of blockchain bloat. If the transaction rate was much higher the blockchain would grow extremely quickly and no one would be able to handle the growth. But with a mini-blockchain which is trimmed we don't have to worry about that problem so much and we can increase the transaction rate by a lot. And also as aaaxn mentioned, each transaction should be reasonably smaller in size.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 06, 2013, 01:12:07 PM
 #67

Any little change can cause some serious bugs. And we are not planning to do little changes.
That is a valid point but we will still be able to re-use a fairly large portion of the existing code base because many things will stay the same. I also think we need to keep in mind the speed factor, how fast is the Go language?

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow


Yes, it is certainly a problem.

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:

1. It's almost the same speed as C/C++ (worst case it's 3x slower only)
2. It's objectively the most secure, battle-hardened, portable virtual machine ever created
3. It has a huge set of libraries to boost the development (p2p, cryptography, UI, etc)
4. It supports a lot of languages Java, Scala, Clojure, JRuby, etc.


bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 06, 2013, 01:23:58 PM
 #68

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 01:30:46 PM
 #69

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.
Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 06, 2013, 01:35:03 PM
 #70

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.
Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.

There is also http://code.google.com/p/bitcoinj/


Quote
bitcoinj implements both the lightweight "simplified payment verification" mode of Satoshis paper which does not store a full copy of the block chain

This is a part we have to re-write anyway.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 06, 2013, 01:49:40 PM
 #71

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.
Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.
I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.

There is also http://code.google.com/p/bitcoinj/


Quote
bitcoinj implements both the lightweight "simplified payment verification" mode of Satoshis paper which does not store a full copy of the block chain

This is a part we have to re-write anyway.
You do also make a valid point about having to re-write the payment verification part. And I do like the GUI of the MultiBit client (it uses bitcoinj). I would definitely be open to using this because I know it has a lot of testing.

If you guys are really set on making this in Java I could accept using bitsofproof or bitcoinj as long as the other develops who come along agree with it. Personally I would prefer to go with bitcoinj if we did go with one of them.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
scooter
Member
**
Offline Offline

Activity: 100
Merit: 10


View Profile
June 06, 2013, 04:15:16 PM
 #72

Java is for chumps. 
FORTRAN 4 EVER!
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 06, 2013, 07:26:19 PM
 #73

I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
Anon136
Legendary
*
Offline Offline

Activity: 1722
Merit: 1217



View Profile
June 06, 2013, 07:33:28 PM
 #74


blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.


bandwidth

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 06, 2013, 07:36:12 PM
 #75

I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.

I'm neutral between bitsofproof and bitcoinj.
nomailing
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 06, 2013, 07:47:50 PM
 #76

I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.

On the other hand bitcoinj is probably used in more open-source wallet applications. This would be very useful if the new coin is successful.

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
johnyj
Legendary
*
Offline Offline

Activity: 1988
Merit: 1007


Beyond Imagination


View Profile
June 06, 2013, 11:19:56 PM
 #77

The problem with blockchain is that when transactions get more and more, the whole network will be stalled due to the same transaction must be broadcasted to the whole network no matter how small they are. I don't see how this new design can prevent that from happening

I agree that recording all the transactions is stupid, should be enough with a ledger of account balance

bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 07, 2013, 07:29:43 AM
 #78

I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.

On the other hand bitcoinj is probably used in more open-source wallet applications. This would be very useful if the new coin is successful.
The code quality of bitcoinj doesn't look too bad either, apparently it was written by a guy from Google. And it has been under development for more than 2 years now, which seems to be a lot longer than bitsofproof has existed.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 07, 2013, 08:26:03 AM
 #79

The code quality of bitcoinj doesn't look too bad either, apparently it was written by a guy from Google. And it has been under development for more than 2 years now, which seems to be a lot longer than bitsofproof has existed.
And bitcoinj code is far more documented. My first impression was wrong, bitcoinj seems to be more suited for our needs.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 07, 2013, 09:05:58 AM
 #80


blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.


bandwidth

Is 200 kB/s managable? That is like 400 txn per second for transmitting txns. And then blocks of about 100 MB every 10 minutes, so a total of about 400 kB/s.

Plenty of household computers in the US could handle this, right? I'm still not understanding the problem.


bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 07, 2013, 10:07:45 AM
 #81

so a total of about 400 kB/s.

Plenty of household computers in the US could handle this, right?
Yeah plenty of household computers in the US could handle it, but the US isn't the world, and we are designing a global crypto-currency which will be used by people all around the world, many of whom will have fairly slow connection speeds, especially upload speeds. One of the benefits of the mini-blockchain scheme is that mining doesn't have to become a highly specialized and centralized industry because almost anyone can handle the size of the mini-blockchain. The aim should be to exclude the minimal amount of nodes possible, meaning we need to take into consideration the connection speeds of people all around the world. So even though many people may be able to handle a huge number of transactions per second will still need to balance it and place a cap on it. This is why I believe a dynamic max block size is necessary, because this isn't something which will remain the same over time. In the future the majority of people will have much faster connection speeds.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 07, 2013, 10:45:01 AM
 #82

The code quality of bitcoinj doesn't look too bad either, apparently it was written by a guy from Google. And it has been under development for more than 2 years now, which seems to be a lot longer than bitsofproof has existed.
And bitcoinj code is far more documented. My first impression was wrong, bitcoinj seems to be more suited for our needs.
Ok well we can all agree on that. I might add to the opening post that we plan to work with bitcoinj and thus require Java developers.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
daybyter
Legendary
*
Offline Offline

Activity: 965
Merit: 1000


View Profile
June 07, 2013, 11:28:18 AM
 #83

I like Java...but only wrote trading software so far...


bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 07, 2013, 11:41:03 AM
 #84

I like Java...but only wrote trading software so far...
Well if you've written trading software in Java you should be able to help out with some of the coding, perhaps not the hardest parts but I'm sure there's a lot you could contribute.

BTW I want to thank who ever made that recent donation. When we create a website for the new coin we might need to add a section for recognizing donators.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 07, 2013, 02:02:33 PM
 #85

Is 200 kB/s managable? That is like 400 txn per second for transmitting txns. And then blocks of about 100 MB every 10 minutes, so a total of about 400 kB/s.

Plenty of household computers in the US could handle this, right? I'm still not understanding the problem.
There is really no need to send full block to network. Most peers have already seen most txns which made it into block so just list of their hashes should be sufficient.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 07, 2013, 02:26:18 PM
 #86

Ok well we can all agree on that. I might add to the opening post that we plan to work with bitcoinj and thus require Java developers.

That's an excellent decision.
While you are gathering a team, I will try to create an adhoc performance test for a database/tree-storage of "account tree", i.e. generate 100million accounts, pack in the Merkle tree, store them and run common queries.

Also I really-really wish to make it extendible from the beginning. For example, I think it's not hard to assume that you can have more than "account tree", mini-block chain, etc.
daybyter
Legendary
*
Offline Offline

Activity: 965
Merit: 1000


View Profile
June 07, 2013, 07:09:35 PM
 #87

Create a model for it...

Start with use cases (UML)...

maco
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
June 07, 2013, 07:49:26 PM
 #88

Is this your Github? Can I fork off of it to improve some functions and help out?
Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 07, 2013, 09:05:43 PM
 #89

Is this your Github? Can I fork off of it to improve some functions and help out?
Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.
No we haven't set up a main repository yet because we are still deciding on some of the details. If you read through the thread you'll see we decided to go with bitcoinj instead of bitsofproof, so if you want to start anywhere, start by looking at bitcoinj. Hopefully we'll have a repository set up soon so some of you can get to work, we also need to decided on a nice name for the coin before we can set it up.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
BitcoinAshley
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
June 07, 2013, 11:15:10 PM
 #90

I like the idea of using bitcoinj to start with. Already we are a step up from the myriad bitcoin-qt copycats.

Silly name ideas:
EverCoin (already suggested by another poster, b/c coin is sustainable, forever)
SmallCoin
TinyCoin
LittleCoin
ShortCoin
OneCoin (the one coin, to rule them all!)
Ethercoin (because the rest of the blockchain just vanishes into the ether)
BalanceCoin (b/c entire ledger history is not necessary, just the balance!)


cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 08, 2013, 07:13:58 AM
Last edit: June 08, 2013, 10:27:53 AM by cunicula
 #91

Added a proposed feature to the netcoin wiki:

http://www.netcoin.io/wiki/Theft_Protection_through_Reversibility_and_Failsafe_Accounts
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 08, 2013, 08:25:48 AM
 #92

Silly name ideas:
EverCoin (already suggested by another poster, b/c coin is sustainable, forever)
SmallCoin
TinyCoin
LittleCoin
ShortCoin
OneCoin (the one coin, to rule them all!)
Ethercoin (because the rest of the blockchain just vanishes into the ether)
BalanceCoin (b/c entire ledger history is not necessary, just the balance!)

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.
daybyter
Legendary
*
Offline Offline

Activity: 965
Merit: 1000


View Profile
June 08, 2013, 01:40:52 PM
 #93

BetterCoin ?
Better Crypto Currency => BCC ?

r3wt
Hero Member
*****
Offline Offline

Activity: 686
Merit: 504


always the student, never the master.


View Profile
June 08, 2013, 01:42:30 PM
 #94

if you need a name, how about NanoToken (NNO)

My negative trust rating is reflective of a personal vendetta by someone on default trust.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 08, 2013, 06:34:57 PM
Last edit: June 08, 2013, 08:38:35 PM by bitfreak!
 #95

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.
Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the name unless someone thinks of something extremely clever which hasn't been used already.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
moltenmich
Full Member
***
Offline Offline

Activity: 130
Merit: 100



View Profile WWW
June 08, 2013, 07:58:38 PM
 #96

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.
Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the same unless someone thinks of something extremely clever which hasn't been used already.

Why hasn't anyone used the term "credits" yet? Is it because it assumes a debt relationship?  XCC- Exchange Credits sounds so universal tho. 

█ Professional Design & Multimedia █

michpalmer.com
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 09, 2013, 04:31:56 PM
 #97

I believe that merged-mining was part of this next-gen crypto-currency,  I would like those following this thread to consider a new approach to scalable merged-mining that allows a 'fixed-size' proof-of-work regardless of the number of chains involved in merged-mining.

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


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 10, 2013, 04:04:48 AM
 #98

Quote
I believe that merged-mining was part of this next-gen crypto-currency
I don't believe that merged-mining is part of this scheme, although it would be a part of something like the ultimate blockchain compression scheme. It seems like you still aren't fully understanding the way this new scheme is designed to work.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 05:12:08 AM
 #99

Quote
I believe that merged-mining was part of this next-gen crypto-currency
I don't believe that merged-mining is part of this scheme, although it would be a part of something like the ultimate blockchain compression scheme. It seems like you still aren't fully understanding the way this new scheme is designed to work.

I have read a lot of different papers on this forum, so I may have gotten some parts confused.  I went back to re-read the white paper to check to see what I thought I rememberd and what I was actually thinking of was the 'proof-of-work chain' in this system.   I was suggesting that it could be updated to use the accumulator method to allow any number of 'proofs' to be stored in the same proof-of-work chain and therefore it would be usable by every blockchain out there without increasing the size.

The account tree structure and mini-block-chain approach is 100% the way I think things need to go.   I am attempting to implement a new blockchain and started designing something very similar to the white paper.   So on closer look, I have to give this approach strong backing.   


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 05:26:19 AM
 #100

Quote
In order to make sure the same signed transaction isn't processed by the network more than
once, the signer of the transaction will need to include in the transaction the hash of any
accounts referenced as inputs for the transaction (we don't need to worry about the outputs
because we have no control over how those accounts change). After the transaction is
applied the accounts will have a different hash and therefore nodes will know not to accept
that same signed transaction again because they can see the account hashes don't match.

The challenge here is that in the event of a chain split, this transaction could not be applied upon re-merging of the forked chain.  It also limits transactions to 'one per account per block' where as bitcoin could in theory have many different transaction per address provided they were all based upon different outputs and incoming transactions would not interfere with outgoing transactions.

To address this issue transactions will need to include an 'initial and final' block number that they may be stored in, then the hash of the transaction must be stored until the 'final' block number in which it will expire to prevent double-spends.   Otherwise you assume all transactions make it into the account any other changes to that account and no one person has control over all changes to an account (after all someone else could send the account funds at the same time you send your trx). 

Conclusion, all transactions must have an expiration block number and must be stored until that date.  This could be as simple as including all transactions in the 'mini-block-chain' until they fall of the end, though I suspect they would only need to be kept around for 48 hours or so.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 10, 2013, 05:34:00 AM
Last edit: June 10, 2013, 05:51:50 AM by bitfreak!
 #101

The account tree structure and mini-block-chain approach is 100% the way I think things need to go.   I am attempting to implement a new blockchain and started designing something very similar to the white paper.   So on closer look, I have to give this approach strong backing.
We will have a github repo up very soon and it would help if you could contribute to the project. We plan to work with bitcoinj, are you any good with Java?

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 10, 2013, 06:15:31 AM
 #102

Quote
The challenge here is that in the event of a chain split, this transaction could not be applied upon re-merging of the forked chain.  It also limits transactions to 'one per account per block' where as bitcoin could in theory have many different transaction per address provided they were all based upon different outputs and incoming transactions would not interfere with outgoing transactions.
That's a good observation which I hadn't realized. Although I'm having a bit of trouble seeing how your proposed solution would allow multiple transactions using the same account... my brain isn't working well today.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 10, 2013, 06:31:41 AM
 #103

Quote
The challenge here is that in the event of a chain split, this transaction could not be applied upon re-merging of the forked chain.  It also limits transactions to 'one per account per block' where as bitcoin could in theory have many different transaction per address provided they were all based upon different outputs and incoming transactions would not interfere with outgoing transactions.
This initial scheme wasn't as bad as you say. You could include any number of tx in same block, because versions changes was applied only during block inclusion.
Anyway I spotted weakness in this approach already and posted refined proposal in wiki few days ago.
http://bitfreak.info/mbc-wiki/index.php?title=Transaction_Signing


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 06:33:53 AM
 #104

I have done Java, though c++ is my primary language.    I think that we need to solve some of the design details that are language independent first and if there is a solid java implementation then I could be tempted to go that route.  

I have a strong need for many parallel chains with combined proof-of-work as a means of providing scaling beyond what a single chain could do.   So off of the top of my head some small changes I would make:

1) move the nonce to the proof chain and replace the block-hash with an accumulator (see ZeroCoin), this would allow all mining efforts for all chains using the same 'proof of work' to support as many chains as possible with almost no extra work.   The nonce would only add 8 to 12 bytes per proof header and thus would not really affect the result.

2) Define sector sizes and what goes in each sector.  Assuming you use something like sha224 you incur 28 bytes of overhead for each level in the merkel tree.  If you have a deep tree, then to 'address' a particular change would require 28 bytes per layer.   If you have a 'flat tree' then recalculating the root hash would require hashing your entire data set.    From a purely big-O stand point you want a hash tree that grows in depth as your data set grows.   The only question you have to consider is the 'branching factor' with 2 being the lowest and something on the order of 1 MB of accounts being the 'largest'.   From a network perspective, having each 'sector' of the dataset fit in a single UDP packet may be the right sector size.   Assuming each account is 48 bytes this means about 32 accounts per sector and each node in your merkel tree would in turn contain about 32 hashes 'children'.   The end result would be log32( total accounts size ) * sizeof(sha224) to prove a prove a particular 'account' has membership in the root hash.       Something to consider regarding making the sector size too large is the probability of a random transaction causing a change to a sector.   If 1% of all addresses see changes in every block and your sector size is 128 then chances are *every sector* will change every time and thus you have little savings.  

    To counter this 'random' behavior, free slots should be deterministically selected from the most-frequently changed sector first.   In fact each block should not just update/replace certain sector, but instead should 'sort' the addresses by least-recently accessed.   So, assume 5 addresses change in 5 different sectors resulting in 5*32 addresses that are part of a changed sector.   Users would have to fetch entire sectors at a time anyway so we might as well use the fact that these sectors have 'changed' to re-sort all 5 sectors moving the 5 changes into the same 'new sector' and moving the least recently changed into other sectors.   This will result in a 'hot set' and a 'cold' set and thus minimize the total number of sector fetches that must occur.  

   Ultimately you need all accounts to be accessed via a hash table and to validate that you have the 'entire hash table'.   Moving addresses around within the sectors would cause significant overhead in updating your hash-table index that allows you to find the addresses quickly.  This might be 'unavoidable' if you want to minimize sync overhead as you would be trading CPU time for network time.  

3) Identify how splits / remerges will be handled.  I think the white paper fails to properly handle this issue along with handling multiple transactions from a single account in a single block.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 06:36:02 AM
 #105

Quote
The challenge here is that in the event of a chain split, this transaction could not be applied upon re-merging of the forked chain.  It also limits transactions to 'one per account per block' where as bitcoin could in theory have many different transaction per address provided they were all based upon different outputs and incoming transactions would not interfere with outgoing transactions.
This initial scheme wasn't as bad as you say. You could include any number of tx in same block, because versions changes was applied only during block inclusion.
Anyway I spotted weakness in this approach already and posted refined proposal in wiki few days ago.
http://bitfreak.info/mbc-wiki/index.php?title=Transaction_Signing

It looks like the solution posted on the wiki is the same solution I came up with, so we are all on the same page!   

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 10, 2013, 06:36:47 AM
Last edit: June 10, 2013, 07:02:05 AM by aaaxn
 #106

I have done Java, though c++ is my primary language.    I think that we need to solve some of the design details that are language independent first and if there is a solid java implementation then I could be tempted to go that route.  
I think we should put design together in wiki before touching code.
I already made a page regarding account tree implementation. I think we should just stick with binary tree.
http://bitfreak.info/mbc-wiki/index.php?title=Account_Ledger

EDIT:
Quote
1) move the nonce to the proof chain and replace the block-hash with an accumulator (see ZeroCoin), this would allow all mining efforts for all chains using the same 'proof of work' to support as many chains as possible with almost no extra work.   The nonce would only add 8 to 12 bytes per proof header and thus would not really affect the result.
As for merged mining I think it would be nice to include it, but I need to think it over. Do you know any good quality resources where it is described?

Quote
Ultimately you need all accounts to be accessed via a hash table and to validate that you have the 'entire hash table'.   Moving addresses around within the sectors would cause significant overhead in updating your hash-table index that allows you to find the addresses quickly.  This might be 'unavoidable' if you want to minimize sync overhead as you would be trading CPU time for network time. 
I think we should treat account ledger as just list of accounts. Account never changes its place on ledger unless it is emptied. This way we can address accounts by just its offset in ledger. This would enable us to make transaction a lot smaller because offset would fit in 5 bytes while public key is 32 bytes.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 07:21:34 AM
 #107

I have done Java, though c++ is my primary language.    I think that we need to solve some of the design details that are language independent first and if there is a solid java implementation then I could be tempted to go that route.  
I think we should put design together in wiki before touching code.
I already made a page regarding account tree implementation. I think we should just stick with binary tree.
http://bitfreak.info/mbc-wiki/index.php?title=Account_Ledger

EDIT:
Quote
1) move the nonce to the proof chain and replace the block-hash with an accumulator (see ZeroCoin), this would allow all mining efforts for all chains using the same 'proof of work' to support as many chains as possible with almost no extra work.   The nonce would only add 8 to 12 bytes per proof header and thus would not really affect the result.
As for merged mining I think it would be nice to include it, but I need to think it over. Do you know any good quality resources where it is described?
I recently stumbled across these two papers which show that it is possible to prove a 'hash' exists in a fixed sized accumulator.  This is the basis behind ZeroCoin.

http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf
http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 10, 2013, 07:35:52 AM
 #108

I think we should put design together in wiki before touching code.
I already made a page regarding account tree implementation. I think we should just stick with binary tree.
http://bitfreak.info/mbc-wiki/index.php?title=Account_Ledger

We should also choose the "slot" size optimaly for the Account Ledger tree.
We can use the results from http://ecommons.library.cornell.edu/bitstream/1813/5655/1/TR2004-1944.pdf
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 10, 2013, 07:38:33 AM
 #109

I recently stumbled across these two papers which show that it is possible to prove a 'hash' exists in a fixed sized accumulator.  This is the basis behind ZeroCoin.

But why we actually need an accumulator here? Can we just add the transactions to the block and mine it as usual? We can have a separate account ledger for any other currency to store balances.
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 10, 2013, 07:38:46 AM
 #110

I recently stumbled across these two papers which show that it is possible to prove a 'hash' exists in a fixed sized accumulator.  This is the basis behind ZeroCoin.

http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf
http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf
It is just theoretical work. We would need already implemented stable libraries.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 07:41:24 AM
 #111

I think we should treat account ledger as just list of accounts. Account never changes its place on ledger unless it is emptied. This way we can address accounts by just its offset in ledger. This would enable us to make transaction a lot smaller because offset would fit in 5 bytes while public key is 32 bytes.
Great insight, except these slots can be reused if the balance reaches 0.  To safely use just offsets would require that the slot be empty for 24 hours or so before being reused.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 07:45:32 AM
 #112

I recently stumbled across these two papers which show that it is possible to prove a 'hash' exists in a fixed sized accumulator.  This is the basis behind ZeroCoin.

http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf
http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf
It is just theoretical work. We would need already implemented stable libraries.

I have contacted the ZeroCoin author attempting to get his implementation for ZeroCoin and creating such a library.   Even without a full implementation, this chain could be designed to potentially work with merged mining by moving the nonce but just use a simple non-merged-mining hash for initial versions.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 07:46:52 AM
 #113

I recently stumbled across these two papers which show that it is possible to prove a 'hash' exists in a fixed sized accumulator.  This is the basis behind ZeroCoin.

But why we actually need an accumulator here? Can we just add the transactions to the block and mine it as usual? We can have a separate account ledger for any other currency to store balances.

THis would be for the proof chain and would allow people to search for proof of work on multiple chains at once without requiring any chain to be overly bloated. 

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 10, 2013, 07:50:53 AM
 #114

I think we should treat account ledger as just list of accounts. Account never changes its place on ledger unless it is emptied. This way we can address accounts by just its offset in ledger. This would enable us to make transaction a lot smaller because offset would fit in 5 bytes while public key is 32 bytes.
Great insight, except these slots can be reused if the balance reaches 0.  To safely use just offsets would require that the slot be empty for 24 hours or so before being reused.
One problem I see with instant pruning is when receiver account is emptied while there is pending tx which sends funds to it. I think we should add tx validity rule. Tx has block number under which they were created. I think we could just drop transaction which has this block earlier than last slot pruning. Introducing delay is still good idea and it should be done too.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 10, 2013, 08:00:25 AM
 #115

THis would be for the proof chain and would allow people to search for proof of work on multiple chains at once without requiring any chain to be overly bloated. 

But accumulator can only check if it contains an element but not how they are linked, right? I mean for "proof chain" you need to have a linked list and accumulator cannot reproduce it.
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 10, 2013, 08:18:58 AM
 #116

If I was mining for Namecoin and Bitcoin I would create an accumulator that included the hash of the block-header for both.  The block-header for each chain would contain the previous node in that chain.

Then when I found the work, I could submit  accumulator + namecoin header hash + key  as the proof of work for the namecoin chain and accumulator + bitcoin header hash + bckey to the bitcoin network.  Thus I solved 2 blocks at once, but each block still has a unique previous hash.

Of couse if the two chains have different difficulties it may only work for namecoin and not for bitcoin unless the resulting hash was good enough for both.


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 10, 2013, 08:41:56 AM
 #117

Assuming each account is 48 bytes this means about 32 accounts per sector and each node in your merkel tree would in turn contain about 32 hashes 'children'.   The end result would be log32( total accounts size ) * sizeof(sha224) to prove a prove a particular 'account' has membership in the root hash.      
You mean 32-branches at every level of tree or just joining accounts in 32 blocks and construct binary tree over such blocks?
If you mean former then to prove membership you need to include all siblings on your path to leaf which means 32 * log32(accounts number) * (size of hash)
If you mean latter you get 2 * log2(accounts / 32) * (size of hash)


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 10, 2013, 11:20:44 AM
 #118

If I was mining for Namecoin and Bitcoin I would create an accumulator that included the hash of the block-header for both.  The block-header for each chain would contain the previous node in that chain.

Then when I found the work, I could submit  accumulator + namecoin header hash + key  as the proof of work for the namecoin chain and accumulator + bitcoin header hash + bckey to the bitcoin network.  Thus I solved 2 blocks at once, but each block still has a unique previous hash.

Of couse if the two chains have different difficulties it may only work for namecoin and not for bitcoin unless the resulting hash was good enough for both.
You could do it with simple hash tree. You include root hash of merge mined blockchains headers and every single chain can prove its inclusion with 2 * logN hashes. I think its affordable and does not need inclusion of new untested and potentially complicated algorithms.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
BitcoinAshley
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
June 10, 2013, 05:25:36 PM
 #119

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.
I understand, but your statement is somewhat of a non-sequitur. The naming convention "****coin" is not at all incompatible with an ISO currency code starting with X. The USD could be called "DollarCoin" and the ISO code would still be USD. So this currency could be called "FailCoin" and the code would still be XFL or XFC or something like that.
However, it was suggested to stay away from the _____Coin convention, and I think that's probably a good idea provided we can think of a non-stupid name - but I just wanted to point out that this convention is not inherently incompatible with an ISO convention. It is just the Bitcoin community's resistance that prevents XBT from being adopted; not that the name "bitcoin" itself prevents this code from being used.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 12, 2013, 02:28:06 PM
Last edit: June 12, 2013, 04:42:54 PM by bitfreak!
 #120

Ok after some discussion with other members, the name has been decided and a github repo has been created.

The name we are going with is Peercash and the repo can be found here (it's still empty right now):
https://github.com/peercash/peercash

Currency code: XPC

The name probably isn't as awesome as it could have been but it was hard to come up with something unique and with the domain name still available. Still I think it's a pretty good name and describes what the project is about so I'm not unhappy with the decision.

The concept is still being fully developed in the project wiki and aaaxn probably wont be around for a little while, so the real development still hasn't started yet. However if anyone wants to start contributing to the project repository that is fine.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 15, 2013, 02:01:18 AM
 #121

I have a question about the proof-chain.

The proofs are only valid if they are newer than the head of the chain because old proofs say nothing about new blocks.   Therefore, having a history of 'random proofs' for which you no longer have the block header used to generate the proof nor any of the data from that block that serves to confirm the initial condition of the oldest block in the mini-chain is actually worthless.   Any attacker could start building off of the proof chain at any point and ultimately 100% of your security comes from the mini-chain. 

The only 'value' the proof chain could provide is to the extent that it enables new proofs to be performed *after* the most recent mini blockchain node. 

Please let me know what I am missing and why I should care about the old proofs which confirm nothing about the initial state of the mini chain.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 15, 2013, 05:04:06 AM
 #122

I have a question about the proof-chain.

The proofs are only valid if they are newer than the head of the chain because old proofs say nothing about new blocks.   Therefore, having a history of 'random proofs' for which you no longer have the block header used to generate the proof nor any of the data from that block that serves to confirm the initial condition of the oldest block in the mini-chain is actually worthless.   Any attacker could start building off of the proof chain at any point and ultimately 100% of your security comes from the mini-chain.  

The only 'value' the proof chain could provide is to the extent that it enables new proofs to be performed *after* the most recent mini blockchain node.  

Please let me know what I am missing and why I should care about the old proofs which confirm nothing about the initial state of the mini chain.
This seems like a good point to me. Couldn't the old proof chain be reapplied by anyone? I mean you don't actually have to make a fresh 'old proof chain' to support an attack chain. Instead you build on top of the old proof chain, you make up an arbitrary coin distribution at the beginning of te mini-blockchain, and then you build on it with your own attack blocks. The 'old proof chain' serves no obvious function.

Is the following approach a viable alternative? It is still txn based rather than account based.

1) For the last say 20000 blocks record all txns. This is the miniblockchain. We don't save block-by-block txn data besides this.
2) Every 10000 blocks, net changes in account balances occurring during a 10,000 block period are summarized in a 'superblock'. Say for example that address A starts with 10 coins at time k. Between k and k+ 10,000, address A sends all these coins to various addresses and ends up with 0. All the superblock needs to record is {address A -10}. We don't need to preserve the nitty gritty details of all txns and precisely when they occurred. However, we still preserve a basic historical record of account balance changes.
3)Say it time t=T right now, where t is measured in blocks. At genesis, t=0 and all addresses start with 0. We have periodic snapshots of account balances at times 0, 10000, 20000, 30000, ..., most recent superblock) {I am to tired to write down the timing of the most recent superblock right now}.
4) We also have block-by-block snapshots of account balances for the last 20000 blocks. There is an overlap interval between the miniblockchain and the last superblock to allow for short-reorgnaizations, which might orphan this superblock.
5) You can incorporate PoW based on superblocks and in the old proof chain. Since superblocks behave very similarly to giant merged blocks, so they cannot be altered without redoing all the old PoW. You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

I got on a plane at midnight and arrived at 6 this morning. If this is nonsensical I will try again after I have slept.
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 15, 2013, 07:44:59 AM
 #123

This problem was already discussed:
https://bitcointalk.org/index.php?topic=195275.msg2035208#msg2035208

In short:
- how many full blocks node stores is configurable (with minimum)
- nodes will not accept competing blockchain unless they have history all the way up to the moment branches diverged.
- if it happened before last available block nodes queries other nodes for missing blocks
- if node cannot find missing history it just refuses to operate and require manual intervention

Too put things into perspective. Mini blockchain should contains something like 1 month of txns minimum. If anyone can do 1 month deep chain reorganization currency would by DEAD no matter if this means overwriting balances or just reverting all transactions.

Anyway whitepaper is little outdated already and update wouldn't hurt.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 15, 2013, 07:59:10 AM
 #124

In other words the proof chain is worthless and the mini-block chain must have at least 1 month of history.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 15, 2013, 08:00:41 AM
 #125

I have a question about the proof-chain.

The proofs are only valid if they are newer than the head of the chain because old proofs say nothing about new blocks.   Therefore, having a history of 'random proofs' for which you no longer have the block header used to generate the proof nor any of the data from that block that serves to confirm the initial condition of the oldest block in the mini-chain is actually worthless.   Any attacker could start building off of the proof chain at any point and ultimately 100% of your security comes from the mini-chain.  

The only 'value' the proof chain could provide is to the extent that it enables new proofs to be performed *after* the most recent mini blockchain node.  

Please let me know what I am missing and why I should care about the old proofs which confirm nothing about the initial state of the mini chain.
This seems like a good point to me. Couldn't the old proof chain be reapplied by anyone? I mean you don't actually have to make a fresh 'old proof chain' to support an attack chain. Instead you build on top of the old proof chain, you make up an arbitrary coin distribution at the beginning of te mini-blockchain, and then you build on it with your own attack blocks. The 'old proof chain' serves no obvious function.

Is the following approach a viable alternative? It is still txn based rather than account based.

1) For the last say 20000 blocks record all txns. This is the miniblockchain. We don't save block-by-block txn data besides this.
2) Every 10000 blocks, net changes in account balances occurring during a 10,000 block period are summarized in a 'superblock'. Say for example that address A starts with 10 coins at time k. Between k and k+ 10,000, address A sends all these coins to various addresses and ends up with 0. All the superblock needs to record is {address A -10}. We don't need to preserve the nitty gritty details of all txns and precisely when they occurred. However, we still preserve a basic historical record of account balance changes.
3)Say it time t=T right now, where t is measured in blocks. At genesis, t=0 and all addresses start with 0. We have periodic snapshots of account balances at times 0, 10000, 20000, 30000, ..., most recent superblock) {I am to tired to write down the timing of the most recent superblock right now}.
4) We also have block-by-block snapshots of account balances for the last 20000 blocks. There is an overlap interval between the miniblockchain and the last superblock to allow for short-reorgnaizations, which might orphan this superblock.
5) You can incorporate PoW based on superblocks and in the old proof chain. Since superblocks behave very similarly to giant merged blocks, so they cannot be altered without redoing all the old PoW. You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

I got on a plane at midnight and arrived at 6 this morning. If this is nonsensical I will try again after I have slept.


This would work, however, maintaining even the diffs of the entire account history would require GB of data for any large number of accounts.    I think the right solution is to not require anything more than 1 year.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 15, 2013, 09:11:00 AM
 #126

In other words the proof chain is worthless and the mini-block chain must have at least 1 month of history.
Proof chain with block headers is needed to prove that historical block you hold is valid (for example you hold block with certain txn which you want to keep record forever). Proof chain on its own is absolutely useless imo.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 15, 2013, 09:55:53 AM
Last edit: June 15, 2013, 10:07:38 AM by bitfreak!
 #127

In other words the proof chain is worthless and the mini-block chain must have at least 1 month of history.
The proof chain is simply a container of expended energy, all it needs to do is prove that some sort of work was done. aaaxn already gave a link to where we discussed the issue you brought up. It's really a minor issue because chances are it would never happen and if it does happen we have a good failsafe plan mentioned by aaaxn:

Quote
I think new nodes in this situation (it should be extremely rare or never) should just query nodes for blockchain all the way to block in which competing chains diverged and if no one around has this long history node should just refuse to operate and wait until thing settle. Or it can be advised to download updated client which should in this situation contain hardcoded checkpoint provided by community pointing to right chain.

It's really only new nodes which would be at risk so dealing with it in that way is acceptable.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 15, 2013, 06:13:16 PM
 #128



This would work, however, maintaining even the diffs of the entire account history would require GB of data for any large number of accounts.    I think the right solution is to not require anything more than 1 year.
The balance sheet is the diff of the entire account history from genesis. This is always needed.

You could aggregate 'superblocks' in a telescoping fashion. The past snapshots would become progressively macroscopic; e.g.  

1,2,4,8,16,32,64,128,256,512,1024,2048,4096,8132,16384,32678, 65536, 131072, 262144, ...,

That is 18 sets of differences for 5 years worth of blockchain. 19 snapshots for 10 years and so on.

The overlapping miniblockchain could be quite short, say a day.

1,2,3,...,142,143,144 (the end)

I don't think that would necessarily be larger in size than a month long mini-blockchain and a balance sheet.

I'm still wrapping my head around the idea. Intuitively ignoring the past seems correct, but then you begin to wonder why keep a month of information in the blockchain, why not just a day? Is there a good answer for this? What problems arise as you decrease the time interval?
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 15, 2013, 06:22:03 PM
 #129

Well, Bitcoin seems to think that 1 day is sufficient to handle chain-reorgs.

There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 15, 2013, 06:38:23 PM
 #130

Well, Bitcoin seems to think that 1 day is sufficient to handle chain-reorgs.

There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.

Yes, I guess if you can rent PoW, then renting a month is much more expensive than renting a day. It then follows that renting 10 years is much more expensive then renting a month.

If you can't rent PoW and must own the capital, then 1 day = 1 month = 1 year. more or less.

aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 16, 2013, 08:33:21 AM
 #131

Quote
You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

You just pushed problem one step back. All you have to do is start from known superblock  and proceed to next one which can be arbitrary and then wait util txn between this blocks are forgotten. It is impossible to overcome this "problem", but it isn't any problem in real world, because very deep reorgs are not expected to happen and if they do community wil react anyway. Imagine bitcoin was attacked today with chain making 10000 blocks reorg and cancelling all txns. What would happen? Of course coummunity will apply patch with checkpoint cancelling this emerged fork.

Quote
There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.
Attacker just adopts existing proofchain (it doesn't prove anything without txns after all) into his attack so it gives us nothing.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 16, 2013, 10:18:51 AM
 #132

Quote
You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

You just pushed problem one step back. All you have to do is start from known superblock  and proceed to next one which can be arbitrary and then wait util txn between this blocks are forgotten. It is impossible to overcome this "problem", but it isn't any problem in real world, because very deep reorgs are not expected to happen and if they do community wil react anyway. Imagine bitcoin was attacked today with chain making 10000 blocks reorg and cancelling all txns. What would happen? Of course coummunity will apply patch with checkpoint cancelling this emerged fork.

Quote
There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.
Attacker just adopts existing proofchain (it doesn't prove anything without txns after all) into his attack so it gives us nothing.

I think it is possible to overcome this "problem". You need to introduce POW that depends on historical superblocks, but not recent history. I am not going to specify the details because I don't have a clear enough understanding of the problem yet. You should be more hesitant to declare things impossible.

Useless to solve perhaps, but impossible, no, I strongly suspect you are wrong.
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 16, 2013, 11:07:31 AM
 #133

I think it is possible to overcome this "problem". You need to introduce POW that depends on historical superblocks, but not recent history. I am not going to specify the details because I don't have a clear enough understanding of the problem yet. You should be more hesitant to declare things impossible.

Useless to solve perhaps, but impossible, no, I strongly suspect you are wrong.
You are trying to replace real txn data which have account owner signatures with some summary data, which is smaller, but cannot be verified. You secure such smaller set with PoW. Txn data is irreversibly lost so you cannot distinguish 'real' summary from made up one and you must rely on PoW honesty. There is no way around it.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
klee
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
June 16, 2013, 01:44:30 PM
 #134

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.
This! Though if we can have smaller blockchain would be a plus!
I like very much this idea and the quality talk here.
When I can I will add a small amount in the bounty - wish I could give more...

And I am here for any help needed, not so much interested in programming but whatever else I can help!
klee
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
June 16, 2013, 01:52:41 PM
 #135

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.
Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the name unless someone thinks of something extremely clever which hasn't been used already.
Supercoin Tongue

EDIT: PeerCash is great!
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 16, 2013, 02:20:26 PM
 #136

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.
This! Though if we can have smaller blockchain would be a plus!
I like very much this idea and the quality talk here.
When I can I will add a small amount in the bounty - wish I could give more...

And I am here for any help needed, not so much interested in programming but whatever else I can help!

The bloat may not be a problem for you, but I am building a blockchain with built in exchange which means having as much data as possible in Ram to match bids / orders.  It also means an order of magnitude more transactions.  If you end up paging things out to disk that will be a problem.   I will also have clients that want to be on multiple parallel chains at the same time and thus what isn't a problem for one chain can become a problem when you start multiplying the problem.


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
klee
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
June 16, 2013, 03:57:53 PM
 #137

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.
This! Though if we can have smaller blockchain would be a plus!
I like very much this idea and the quality talk here.
When I can I will add a small amount in the bounty - wish I could give more...

And I am here for any help needed, not so much interested in programming but whatever else I can help!

The bloat may not be a problem for you, but I am building a blockchain with built in exchange which means having as much data as possible in Ram to match bids / orders.  It also means an order of magnitude more transactions.  If you end up paging things out to disk that will be a problem.   I will also have clients that want to be on multiple parallel chains at the same time and thus what isn't a problem for one chain can become a problem when you start multiplying the problem.


So you work with bitfreak for this? Or you follow your own designs (seen them in other threads).
Just to add something, I think that in the long term any coin should adopt P2P exchange infrastructures and be like Ripple (coin+platform).

In time...
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 16, 2013, 05:33:44 PM
 #138

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 17, 2013, 07:46:27 AM
Last edit: June 17, 2013, 08:01:36 AM by cunicula
 #139


You are trying to replace real txn data which have account owner signatures with some summary data, which is smaller, but cannot be verified. You secure such smaller set with PoW. Txn data is irreversibly lost so you cannot distinguish 'real' summary from made up one and you must rely on PoW honesty. There is no way around it.
It probably makes no sense to use txns at all. Instead users should sign current balances (not differences in balances, actual current balances).

User signs his own balance A using private key and another balance B.

Validity rules for inclusion of balance sheet update in block (these replace txns):

New balance A < Old Balance A
New Balance A - Old Balance A + balance B = 0

Due to this modification, every single deduction in the balance sheet would be signed by the balance's private key owner.

Similar to bitcoin and unlike the miniblockchain, txns could not be forged only deleted.
Similar to the miniblockchain and unlike bitcoin, you would not need to preserve records of all history. Instead you could preserve snapshots.

I'm not sure if the snapshots can be telescoping or not yet (I can't figure out how they could be, but feel like someone else probably could).

I'm also still puzzling over the details of attaching PoW to snapshots and interweaving this with PoW attached to current balance sheet updates.

[I can do this later. I have been on two economy night flights within a 48 hours span. I feel like one of those hangovers where you wake up drunk.]

cunicula
Legendary
*
Offline Offline

Activity: 1050
Merit: 1003


View Profile
June 17, 2013, 08:00:03 AM
 #140

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

I think this is a great attitude. It is sad to see stuff degenerate into separate competing teams.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 17, 2013, 08:03:01 AM
 #141


You are trying to replace real txn data which have account owner signatures with some summary data, which is smaller, but cannot be verified. You secure such smaller set with PoW. Txn data is irreversibly lost so you cannot distinguish 'real' summary from made up one and you must rely on PoW honesty. There is no way around it.
It probably makes no sense to use txns at all. Instead users should sign current balances (not differences in balances, actual current balances).

User signs balance A using private key and another balance B.
And what would happen if the balance of the receiving account changes before the transaction is accepted into a block? What you suggest would still produce signed transactions, the data being signed is simply different, and signing the balances is not the best way to do it.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
June 17, 2013, 08:15:11 AM
 #142

It probably makes no sense to use txns at all. Instead users should sign current balances (not differences in balances, actual current balances).

Correct me if I'm wrong, but what you propose looks like Ripple Ledger+PoW. I think it is also a viable approach.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 17, 2013, 08:19:21 AM
Last edit: June 17, 2013, 11:40:35 AM by bitfreak!
 #143

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

I think this is a great attitude. It is sad to see stuff degenerate into separate competing teams.
Well so far it seems like BitShare is going to function as a Decentralized Exchange / Messaging System / Storage Network. It's a very different project from this project, it will require much more work and effort to build a system which is capable of providing all that functionality in one package.

This project is an attempt to bring together many new ideas, but those ideas are basically just focused on creating a more efficient and speedy crypto-currency, not to build a multi-function alt-coin designed to do all sorts of weird and wonderful things. It is designed and streamlined for one job only: to be a virtual currency.

BitShares sounds like a decent idea, but then again I think some of these systems simply work better by themselves and don't need to be integrated into one unified platform. Torrent technology and file upload services already provide all my storage needs and I wouldn't care about using BitShare for that.

Likewise, all my messaging needs are already taken care of by free email and chat services. For secure encrypted email I some times like to use Bitmessage because it provides all the functionality I need and avoid spam. If I needed to safely send a large file I'd just encrypt it and then upload it to the net.

However I will say that if a decentralized system can be designed which is capable of handling messages and large file attachments, with the ability to pay to have messages sent quickly, that would provide advantages over Bitmessage, but I'm sure there will be scalability issues and other difficulties in attempting to build such a system.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 17, 2013, 11:13:28 AM
 #144

User signs his own balance A using private key and another balance B.

Validity rules for inclusion of balance sheet update in block (these replace txns):

New balance A < Old Balance A
New Balance A - Old Balance A + balance B = 0
You need to privide more details, because I see lot of ways this could go wrong. For example it won't work without txns serialization. You send money to B but while your tx wait for inclusion in block your balance changes and you end up sending other amount than requested. And also remember attacker can create valid signatures for his own accounts so he can sign something which isn't true and you can't tell if he did because old txns are lost.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 17, 2013, 02:01:54 PM
 #145

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

I think this is a great attitude. It is sad to see stuff degenerate into separate competing teams.
Well so far it seems like BitShare is going to function as a Decentralized Exchange / Messaging System / Storage Network. It's a very different project from this project, it will require much more work and effort to build a system which is capable of providing all that functionality in one package.

This project is an attempt to bring together many new ideas, but those ideas are basically just focused on creating a more efficient and speedy crypto-currency, not to build a multi-function alt-coin designed to do all sorts of weird and wonderful things. It is designed and streamlined for one job only: to be a virtual currency.

BitShares sounds like a decent idea, but then again I think some of these systems simply work better by themselves and don't need to be integrated into one unified platform. Torrent technology and file upload services already provide all my storage needs and I wouldn't care about using BitShare for that.

Likewise, all my messaging needs are already taken care of by free email and chat services. For secure encrypted email I some times like to use Bitmessage because it provides all the functionality I need and avoid spam. If I needed to safely send a large file I'd just encrypt it and then upload it to the net.

However I will say that if a decentralized system can be designed which is capable of handling messages and large file attachments, with the ability to pay to have messages sent quickly, that would provide advantages over Bitmessage, but I'm sure there will be scalability issues and other difficulties in attempting to build such a system.

Bit shares and bit postage are two different ideas and chains.  I would not dream of combining them.   

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 17, 2013, 03:43:31 PM
 #146

Quote
Bit shares and bit postage are two different ideas and chains.  I would not dream of combining them.
Oh ok, well that makes a bit more sense then. Personally I think the bit postage idea is worth building first because even if you can't support massive file attachments it would still be nice to use bitpostage coins to pay for postage, or something like that, instead of having to generate the proof of work with each new message you want to send. That was the basic idea right?

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 17, 2013, 04:01:16 PM
 #147

Quote
Bit shares and bit postage are two different ideas and chains.  I would not dream of combining them.
Oh ok, well that makes a bit more sense then. Personally I think the bit postage idea is worth building first because even if you can't support massive file attachments it would still be nice to use bitpostage coins to pay for postage, or something like that, instead of having to generate the proof of work with each new message you want to send. That was the basic idea right?

Well I have funding for bit shares.    The bigger idea with bit postage is that you can pay for storage not just transmission.  End result is massively decentralized torrent of everything.  Clearly something that should be built.   After bitshares. 

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 19, 2013, 03:19:59 AM
 #148

Solution for erasing chain history:  you can delete all transactions after '2 weeks' provided you have a proof-chain difficulty that is at a all time high from the last 'trusted signature' on the block state.  If you have stayed connected, then you do not need any signatures and thus keep rolling on 1 month or even 1 week intervals.  The 'first' trusted signature is the genesis block and others can be added like the bitcoin checkpoints. 

The challenge is having the new node connect to the network.  If the difficulty is not at an all-time high then they must download all transactions back to the last 'check point with a trusted signature' or the all time difficulty high.

The complete transaction history could be stored in a distributed manner and thus new nodes could connect and verify as far back as they need to, including all the way back to the genesis block.   There would be little need to do that however because there are enough other 'checks' that you can perform to validate that you have a 'trustable' initial condition.   The primary check being, 'does your initial condition have consensus' among all of your friends, family and merchants.

Why does this work?   Because any attacker attempting to build on a false proof-chain would have to have 100% of the hashing power of the network starting at the time of the fork in order to prevent a drop in hash power on their fork.    They would then have to grow their hashing power at the same rate as the main network to create believable alternative history and thus alternative initial condition.   If they ever went 'public' with a 1 month old 'remerge' people would demand the complete transaction history before they could accept that merge and therefore all they could accomplish is a double spend.  Otherwise they would have to 'isolate' their victim.

Now lets assume the attacker first uses their hash power to increase the difficulty on the valid chain, then they switch all of their hashing power on to a new 'false chain'   The main chain and the 'false chain' would each experience a fall in difficulty and thus all nodes would store all transaction history until a new high was reached.   To effectively attack this system would require far more than a 51% attack.  It would require an attacker to 'instantly' switch on a level of hashing power equal to 101% of the entire network and even then they could only potentially 'fool' new nodes by presenting a false initial condition.   Such an attack would be very public and thus everyone would know and clients would be updated to 'reject' the bogus chain. 

Another factor that will enable users to identify the 'true chain' is to ask any merchant what the 'current chain' is.  The merchants would be running full nodes around the clock and thus could not be 'tricked' by a bogus initial condition and any client that started up would simply ask a handful of trusted merchants what the initial condition is. 

Conclusion:  you need the proof-chain all the way back to the last trusted/signed state (perhaps the genesis block) and this chain is very valuable for telling a client how far back they must validate transactions upon a new connection to the network.  Once connected to the network almost no transaction history is required provided you keep track of all unspent outputs.   The only transaction history you must maintain is enough to cover all reasonable 'chain merges' which should be 1 week to 1 month at most.   This 'stored transaction history' could be distributed and queried as necessary when a merge happens and therefore most 'light nodes' could discard transactions and let the 'full nodes' keep them in case of a merge.   


https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 19, 2013, 05:50:39 AM
 #149

Conclusion:  you need the proof-chain all the way back to the last trusted/signed state (perhaps the genesis block) and this chain is very valuable for telling a client how far back they must validate transactions upon a new connection to the network.  Once connected to the network almost no transaction history is required provided you keep track of all unspent outputs.   The only transaction history you must maintain is enough to cover all reasonable 'chain merges' which should be 1 week to 1 month at most.   This 'stored transaction history' could be distributed and queried as necessary when a merge happens and therefore most 'light nodes' could discard transactions and let the 'full nodes' keep them in case of a merge.
I really don't understand what you are talking about, the transactions are stored within the mini-blockchain like the normal blockchain. When a block is trimmed from the mini-blockchain the transaction data is discarded with it but the block header (or proof cell) is kept as part of the proof chain. When a new node connects to the network it doesn't rely at all on validating transactions, the new node simply attempts to obtain the proof chain with the highest cumulative difficulty and then obtains the mini-blockchain associated with that proof chain. If the new node detects two competing chains which originate from the same proof chain it will execute the contingency measures described by aaaxn. There is no point for a new node to validate transactions when synchronizing because the whole idea is to discard old transaction data and rely solely on the proof chain to prove which mini-blockchain is the right one. Once the new node is properly synchronized with the network it will then start validating new blocks as it receives them, like any normal node. There is no need to track all the unspent outputs or anything else, and in fact there is no such thing as unspent outputs in this system because it uses an account ledger.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 19, 2013, 06:35:25 AM
 #150

I understand your account ledger system which is effectively just 'unspent outputs' assuming each output was a unique address.

I am dealing only with the more theoretical how does the mini-chain agree on the initial condition.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 19, 2013, 06:55:27 AM
 #151

I am dealing only with the more theoretical how does the mini-chain agree on the initial condition.
I'm not sure what you mean by "how does the mini-chain agree on the initial condition", I assume you mean how do new nodes agree on which mini-blockchain is the correct one. An attacker trying to build upon the real proof chain would need to keep up with the hash power of the real chain for a full cycle in order to pull off the attack you brought up. And the attacker would have to do it in secret for a full cycle of the mini-blockchain before broadcasting the fake chain in order for new nodes to be unable to detect it was fake. Obviously such an attack would be extremely difficult to pull off, and I doubt it would ever actually happen. But if it did then the contingency plan described by aaaxn is perfectly adequate for dealing with it. If a new node detects two competing chains which originate from the same proof chain and it cannot determine which is the real one it will simply refuse to participate in the network until the situation is resolved or until the client is updated with the latest checkpoint.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 19, 2013, 07:02:07 AM
 #152

That works, so the contribution I believe I made is that by looking at the most difficult block difficulty you can determine the maximum mini-blockchain length required.... you may be able to go shorter.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 19, 2013, 07:18:42 AM
 #153

That works, so the contribution I believe I made is that by looking at the most difficult block difficulty you can determine the maximum mini-blockchain length required.... you may be able to go shorter.
So you're suggesting that the length of the mini-blockchain should be dynamic? I'm not sure if that's really a good idea because many other calculations depend on the length of the mini-blockchain. The concept as it is now is to use a statically sized mini-blockchain (as in the number of blocks is fixed) which would probably hold something like a day to a few weeks of transaction history. However nodes could have the ability to store more older blocks if they wanted. And as aaaxn mentioned, new nodes could ask for those older blocks as a way to help them detect fake chains. Although there would be no requirement for anyone to save the older blocks and things should work perfectly fine without them.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
wizzardTim
Legendary
*
Offline Offline

Activity: 1708
Merit: 1000


Reality is stranger than fiction


View Profile
June 21, 2013, 08:48:09 AM
 #154

Interested. Keeping an eye on this.

Behold the Tangle Mysteries! Dare to know It's truth.

- Excerpt from the IOTA Sacred Texts Vol. I
klee
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
June 21, 2013, 12:01:36 PM
 #155

Can someone indulge me on how is MC2 and Peercash different in handling the blockchain?

Thanks in advance!
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 21, 2013, 01:02:16 PM
Last edit: June 22, 2013, 06:23:36 AM by bitfreak!
 #156

Can someone indulge me on how is MC2 and Peercash different in handling the blockchain?
Well when I read the MC2 white paper a few weeks ago I noticed that it does also make use of a "novel hash tree" but the use of the hash tree is much different. MC2 appears to use a polymorphic hash tree as part of the PoW mechanism, where as Peercash will use a hash tree database for storing information about non-empty addresses so that old transaction data can be discarded. As the MC2 white paper states "The principles of both LTC and PPC are extended in Memcoin2", meaning MC2 is mainly focused on making the PoW protocol more robust and memory-hard and combining that with the PoS concept.

Peercash changes things on a much deeper level. We are totally rethinking the way that crypto-currency needs to work in order to create a more scalable and speedy coin. This is achieved with new mechanisms such as the account tree and mini-blockchain. We most likely wont integrate PoS into the system but are developing concepts which will allow secure 0-confirmation transactions and a dynamic max block size. I hope this has answered your question, but you can always read the wiki or white paper if you really want to understand the idea.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
BrightAnarchist
Donator
Legendary
*
Offline Offline

Activity: 853
Merit: 1000



View Profile
June 22, 2013, 03:35:04 AM
 #157

Awesome! I have proposed the "rolling chain" concept myself. It's the future for sure.

Do you have a code repository up yet? I absolute would like to contribute to this project.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 22, 2013, 06:43:19 AM
 #158

Do you have a code repository up yet? I absolute would like to contribute to this project.
Yes we do but it's still empty: https://github.com/peercash/peercash

We are still lacking a team of core developers but if anyone wants to start working on the code I would welcome it. It's harder than I expected it would be to get some good programmers in on this project. I think once we get started on the code things will naturally progress at a faster rate and more programmers will be attracted to the project. And it's not like the project is totally unfunded so contributions will be rewarded.

And I'm still not entirely sure whether working in Java is the best idea. Would you prefer to work in C++ or Java? It seems most of the good bitcoin programmers are better with C++ so I'm not sure that building it in Java is the best idea after all. We need to decide this carefully before writing the first line of code.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 22, 2013, 07:06:52 AM
 #159

I have a team of 3-4 developers that will be working to implement BitShares in c++ over the next couple of months.  BitShares will be implementing many of the features described in this thread in an attempt to reach the same goals.   

I have significantly revamped, updated, clarified, and extended the BitShares white paper:

https://docs.google.com/document/d/1RLcjSXWuU9vBJzzqLEXVACSCdn8zXKTTJRN_LfoCjNY/edit#

It will have the following characteristics described in this thread:

1) Rolling / Minimal Possible Transaction History (mini-blockchain)
2) 'account tree' which I call 'unspent transaction outputs'
3) Merged Mining / Proof-Chain
4) Potentially the 0-confirmation (spend limit)

While BitShares will implement many other features, they could be easily removed in a fork that implemented only the subset described here. 

The white paper is open to comments on google docs and I am actively looking for additional feedback and developers.  To the extent that we can pool resources the better.



https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 22, 2013, 07:33:19 AM
 #160

2) 'account tree' which I call 'unspent transaction outputs'
That is just really confusing. The account tree isn't a collection of unspent outputs, because all the unspent outputs are merged into a single balance for any given address. When dealing with an account tree you're probably over complicating the matter by referring to is as such.

While BitShares will implement many other features, they could be easily removed in a fork that implemented only the subset described here. 
Yes I suppose that would be possible but at this point we're still going with Java and if we did fork BitShares we couldn't start coding our project simultaneously. BitShares seems like it will be fairly complicated and I doubt much of it will really be what we need for Peercash anyway. And the more sensible way to do it would be to build Peercash first and then build BitShares on top of that if we were going to work together.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 22, 2013, 02:05:41 PM
 #161

2) 'account tree' which I call 'unspent transaction outputs'
That is just really confusing. The account tree isn't a collection of unspent outputs, because all the unspent outputs are merged into a single balance for any given address. When dealing with an account tree you're probably over complicating the matter by referring to is as such.

While BitShares will implement many other features, they could be easily removed in a fork that implemented only the subset described here. 
Yes I suppose that would be possible but at this point we're still going with Java and if we did fork BitShares we couldn't start coding our project simultaneously. BitShares seems like it will be fairly complicated and I doubt much of it will really be what we need for Peercash anyway. And the more sensible way to do it would be to build Peercash first and then build BitShares on top of that if we were going to work together.

I understand that you are merging all unspent outputs with the same script into a single balance.  After much thought and consideration, using account balances creates challenges that are intractable when it comes to paying dividends and several other things.   By using unspent outputs and charging fees anytime a transaction creates more unspent outputs than it consumes and several other things market forces will align to minimize the number of unspent outputs. 

If you do create the next generation crypto-currency then it should probably offer something other than just reduced resources.  There is already someone working on ultimate blockchain compression. 

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 22, 2013, 02:47:41 PM
 #162

If you do create the next generation crypto-currency then it should probably offer something other than just reduced resources.  There is already someone working on ultimate blockchain compression. 
Yeah but the mini-blockchain scheme will be much more efficient than the ultimate blockchain compression scheme and it should be easier to implement. Plus it should have several new features including secure 0-confirmation transactions and other things which no other alt-coin has. Once it has been implemented you will be able to fully understand why it is so superior to the old blockchain scheme, assuming it works of course.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 22, 2013, 03:00:38 PM
 #163

If you do create the next generation crypto-currency then it should probably offer something other than just reduced resources.  There is already someone working on ultimate blockchain compression. 
Yeah but the mini-blockchain scheme will be much more efficient than the ultimate blockchain compression scheme and it should be easier to implement. Plus it should have several new features including secure 0-confirmation transactions and other things which no other alt-coin has. Once it has been implemented you will be able to fully understand why it is so superior to the old blockchain scheme, assuming it works of course.

Trust me I know it doesn't take much to be superior to the bitcoin blockchain.  It just takes a lot to actually work without compromising security.    In theory the limit you face is on total unique accounts rather than transaction volume.

I did an analysis of the Bitcoin blockchain and looked at just unspent transaction outputs over time.   You immediately get a 8:1 compression.   If you can eliminate the need to store the inputs to the unspent outputs you end up with 16:1 compression.     Lastly, when you provide fees for creating new unspent outputs and don't charge people for large transactions that merge dust along with taxing all unspent outputs over 1 year old (to keep them fresh and prove private key ownership wasn't lost) then you end up with about 32:1 compression on the data that must be stored.  In effect, the current bitcoin transaction volume / user base would only require about 400 MB of data that would grow proportional to the user-base rather than proportional to transaction volume. 

In your system you compress it one step further by always merging all 'balances' into one address.   In my system I create economic incentives for users to do this but do not require it due to other implementation/security challenges.  Therefore, I would guess that the theoretical gains of compressing down to just one output per address would be very small compared to where I think BitShares is now and it comes at a cost that limits flexibility on dividends.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 22, 2013, 03:17:15 PM
 #164

In theory the limit you face is on total unique accounts rather than transaction volume.
Yes that is correct, but you don't really need to do any of the calculations you did to work out how fast the account tree will grow. Simply look at what fields each account in the account tree holds to workout the size of each account and then you can look at how fast new addresses are introduced into the Bitcoin blockchain to get an idea of how fast it will grow. Even if you take every single address the Bitcoin network has ever seen it's still quite small in size. But obviously not all the addresses that the Bitcoin network has seen remain unempty, and the account tree can drop all the non-empty addresses.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 22, 2013, 03:20:13 PM
 #165

Have you actually calculated the total number of unique addresses with non-0 balances vs the total unspent?  I suspect the majority is people with automatic mining pool payments every .01 BTC that have not 'spent' them together yet.  Create financial incentive (like dividends / fees) to combine this kind of thing and we are not far off in data requirements.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 22, 2013, 03:27:48 PM
 #166

Have you actually calculated the total number of unique addresses with non-0 balances vs the total unspent?
No I don't think I have. I have done what I just said though, I calculated how fast the account tree should grow but I can't really remember the result which I why I didn't give exact figures (based on all unique addresses seen by the network). I'd have to do the calculation again when I have a free moment.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 22, 2013, 04:05:22 PM
Last edit: June 22, 2013, 05:16:33 PM by bitfreak!
 #167

http://bitcoin.stackexchange.com/questions/2828/how-many-bitcoin-addresses-are-have-been-carrying-a-balance

If that link is anything to go by the number of non-empty addresses stayed at about 600,000 through 2011 and 2012, although it might be higher now. I can't be certain exactly how large each account in the account tree will be, but you can see how that is an extremely small number even using the most conservative estimations.

EDIT: here's another interesting link:
http://bitcoin.stackexchange.com/questions/10850/how-many-bitcoin-addresses-are-there?rq=1

The top answer states that as of 12th May 2013 there were 1.6 million Bitcoin addresses which carried a positive balance, although the writer of the answer doesn't provide any links our sources for his answer, unlike the answer in the first link.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
June 22, 2013, 07:06:01 PM
 #168

Those are some very interesting numbers, 1.6 million addresses each of which requires the following information:

1) Block              4 bytes (last change)
2) Balance           8 bytes
3) out Script       40 bytes
4) Unit                2 bytes

The result would be about 100 MB scaling with the number of users.   

The bitcoin block transaction fee system is perverse and does not encourage users to combine outputs and in fact makes it uneconomical to do so.   There are about 1M net new unspent outputs every month for the past several months.   Many of these outputs are SDICE and mining pools which are making small transactions. 

What I can conclude is that with proper incentives you could cause the unspent outputs to approximate actual accounts in number. 



https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 22, 2013, 07:24:09 PM
 #169

The result would be about 100 MB scaling with the number of users.
Probably even smaller because I'm sure there will be ways to compress data in the account tree.

What I can conclude is that with proper incentives you could cause the unspent outputs to approximate actual accounts in number.
Well what I can conclude is that incentive isn't enough and if we want to take crypto-currency to the next level we need something like a mini-blockchain scheme. Although if you are forced to use the old transaction model for BitShares then your only hope may be to provide incentives.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Sr. Member
****
Offline Offline

Activity: 359
Merit: 250



View Profile
June 22, 2013, 08:18:01 PM
 #170

Those are some very interesting numbers, 1.6 million addresses each of which requires the following information:

1) Block              4 bytes (last change)
2) Balance           8 bytes
3) out Script       40 bytes
4) Unit                2 bytes

The result would be about 100 MB scaling with the number of users.   

The bitcoin block transaction fee system is perverse and does not encourage users to combine outputs and in fact makes it uneconomical to do so.   There are about 1M net new unspent outputs every month for the past several months.   Many of these outputs are SDICE and mining pools which are making small transactions. 

What I can conclude is that with proper incentives you could cause the unspent outputs to approximate actual accounts in number. 
I think a lot of addresses are created "by accident" because of change sending. User wouldn't intentionally create them so account number in ledger system might be smaller.


                                                                              █
                              █████████                  ██████ 
                      ███████████████████████████   
              ███████████████████████████████   
            ████████████████████████████████   
        █████████████████████████████████     
    ████████████████████████████████████   
    ████████          █████████          █████████   
  ████████                ██████              ████████   
█████████                █████                ████████   
███████████                █                ███████████ 
██████████████                      ██████████████ 
█████████████████            ████████████████ 
███████████████                  ███████████████ 
█████████████                          █████████████ 
███████████              ███                ██████████ 
█████████                █████                ████████   
  ████████              ███████              ███████     
    █████████        █████████          ████████     
      █████████████████████████████████       
        ██████████████████████████████           
            ███████████████████████████             
              ████████████████████████                 
                  ████████████████████                     
CorionX


















Powered by,
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 23, 2013, 11:59:02 AM
Last edit: June 23, 2013, 12:14:33 PM by bitfreak!
 #171

I think a lot of addresses are created "by accident" because of change sending. User wouldn't intentionally create them so account number in ledger system might be smaller.
That's a good point to keep in mind as well. Now looking at the current average block size for the Bitcoin network it appears to be at about 0.125MB. At a rate of 1 block every 10 minutes the Bitcoin blockchain should be growing at a rate of something like 125MB every 7 days. I think a full week is an ideal amount of history for the mini-blockchain. So adding it all up, if the Bitcoin network were to be converted into a mini-blockchain scheme right now each node would only need to download something close to 200MB in order to become fully synchronized with the network and operate as a full node. Compared to the 8 gigabyte blockchain the advantage is clear.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
BrightAnarchist
Donator
Legendary
*
Offline Offline

Activity: 853
Merit: 1000



View Profile
June 26, 2013, 12:15:28 AM
Last edit: June 26, 2013, 12:25:40 AM by BrightAnarchist
 #172

Do you have a code repository up yet? I absolute would like to contribute to this project.
Yes we do but it's still empty: https://github.com/peercash/peercash

We are still lacking a team of core developers but if anyone wants to start working on the code I would welcome it. It's harder than I expected it would be to get some good programmers in on this project. I think once we get started on the code things will naturally progress at a faster rate and more programmers will be attracted to the project. And it's not like the project is totally unfunded so contributions will be rewarded.

And I'm still not entirely sure whether working in Java is the best idea. Would you prefer to work in C++ or Java? It seems most of the good bitcoin programmers are better with C++ so I'm not sure that building it in Java is the best idea after all. We need to decide this carefully before writing the first line of code.

Personally I can't stand writing code in Java (checked exceptions...), but I do acknowledge that bitcoinj and supernode are much furthur along than any other managed language implementation (such as bitcoin C#)

Also, recommend you call the unit XPC
fishy
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


What do you call a fish with no eyes? A Fsh!


View Profile
June 26, 2013, 12:21:12 AM
 #173

I can make a logo if you would like, just shoot me a PM with the abbreviation and some info!  Smiley

\   \  \ \\\\\\\\\\\\\\\\◥◣◢◤//////////////// /  /   /
Win88.me ❖ Fair, Trusted Online BTC Gambling ❖
/   /  / ////////////////◢◤◥◣\\\\\\\\\\\\\\\\ \  \   \
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 26, 2013, 12:54:25 AM
 #174

Personally I can't stand writing code in Java (checked exceptions...),
Well I don't really think Java is a bad language to write in, but I am feeling like C++ is a better option because most programmers who are familiar with bitcoin technology have worked with the C++ implementation and we might be able to get things done quicker if we go that way.

Also, recommend you call the unit XPC
Yes that is the currency code we are going with.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
June 26, 2013, 01:00:37 AM
 #175

I can make a logo if you would like, just shoot me a PM with the abbreviation and some info!  Smiley
Well at this point I'm not too concerned with things such as the logo, but if you want to have a go at making a logo that's cool. I don't really know what info you need... the name of the currency is Peercash and the currency code is XPC. You shouldn't need anything more than that for the logo. I will use your logo if it's good but I can't guarantee it'll be used.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
July 01, 2013, 11:44:12 AM
 #176

If nobody else will kickoff the development, I will fork bitcoinj and start implementation in the beginning of August. I hope to be able to spend around 10-15 hours a week on this.
daybyter
Legendary
*
Offline Offline

Activity: 965
Merit: 1000


View Profile
July 01, 2013, 11:49:34 AM
 #177

What will be your target plattform? J2SE or Android?

lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
July 01, 2013, 12:41:18 PM
 #178

What will be your target plattform? J2SE or Android?

J2SE.
daybyter
Legendary
*
Offline Offline

Activity: 965
Merit: 1000


View Profile
July 01, 2013, 01:46:14 PM
 #179

Wouldn't it be better to use a mobile plattform? Just to avoid any single point of failure?

lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
July 01, 2013, 01:53:06 PM
 #180

Wouldn't it be better to use a mobile plattform? Just to avoid any single point of failure?

I don't see how running something on regular consumer-level PC creates a single point of failure. Also it's much harder to develop for mobile platform from the day 1. The first goal is at least to have a working code for plain J2SE. Then one can port it to a mobile platform or create a thin client like Electrum.
Cryptoin
Full Member
***
Offline Offline

Activity: 155
Merit: 100



View Profile
July 01, 2013, 07:29:09 PM
 #181

Interesting stuff.  Any workplan to date for development and launch?
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
July 01, 2013, 11:54:29 PM
Last edit: July 02, 2013, 07:39:49 AM by bitfreak!
 #182

Wouldn't it be better to use a mobile plattform? Just to avoid any single point of failure?

I don't see how running something on regular consumer-level PC creates a single point of failure. Also it's much harder to develop for mobile platform from the day 1. The first goal is at least to have a working code for plain J2SE. Then one can port it to a mobile platform or create a thin client like Electrum.
Indeed, it would be silly to develop the first client for mobile platforms because we need the hashing power of desktop CPU's and GPU's.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
July 10, 2013, 04:44:58 AM
 #183

Quote
Interesting stuff.  Any workplan to date for development and launch?
Well lexxus said he will begin working on it at the start of August but that's about the only plan we have so far.
I will now perform my mystic coder dance in order to attract a torrential flood of developers into the project.
lol... seriously though folks we need all the help we can get, I really want to see this get developed and tested.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
July 15, 2013, 02:32:26 AM
 #184

Some thoughts on the merits of an account tree approach:

1) The purpose is to reduce the data storage requirements to allow the network to sync / scale faster and thereby keep the network more decentralized.

2) Blockchain size and sync/time are ultimately only part of the problem, the other part of the problem is transaction volume and bandwidth.   If the goal is to support 100 million users each of whom is able to run the software on their home PC / average internet connection without entirely saturating it, then you would have to limit your bandwidth to something along the lines of 1 Megabit/sec or around 100 transactions per second which would mean each user could only do about 2 transactions per month and you are only involving about 1% of the world population in this network.   This network would be generating 10 GB / month or 120 GB / year in transactions.   Lets assume we could prune 50% of the transactions, 1 year would be 60 GB of data.

Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.

B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account.   This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.

C) The resulting database size would be 200 GB without any indexes or other data structures. 

D) To create a sha256 merkle tree on these accounts would require 64 GB

E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB

Conclusion:  The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.   

The end result is that the account tree and full-block chain system have identical support for transaction volume, with only about a 6x gain in data storage efficiency or break even with 6 years of transaction volume.

Clearly the bandwidth is the bottle neck of scalability and not the data storage.    If you allow the bandwidth to scale enough to accommodate the transaction volume of VISA then everyone would require a 1 Gigabit connection to the internet at which point you are already well beyond the scale of the average individual and well into the realm of centralized financial institutions which would be logging every transaction forever anyway, the account tree system would just be extra book-keeping for these organizations which would probably maintain a separate index optimized for their queries.

A decentralized blockchain is transaction rate limited, not storage limited.   If the only change you made to the blockchain was to automatically expire / invalidate any unspent output more than 12 months old you would solve the data storage problem, the dust problem, the bootstrap problem, and the lost-key problem.   And you would be left with the same scalability problems as the account-tree based approach. 

What I conclude is that the account tree system at most provides some benefits for medium-scale systems involving perhaps 1 million users but is entirely irrelevant once you scale to the size Bitcoin aims to achieve.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
Anon136
Legendary
*
Offline Offline

Activity: 1722
Merit: 1217



View Profile
July 15, 2013, 02:46:37 AM
 #185

Some thoughts on the merits of an account tree approach:

1) The purpose is to reduce the data storage requirements to allow the network to sync / scale faster and thereby keep the network more decentralized.

2) Blockchain size and sync/time are ultimately only part of the problem, the other part of the problem is transaction volume and bandwidth.   If the goal is to support 100 million users each of whom is able to run the software on their home PC / average internet connection without entirely saturating it, then you would have to limit your bandwidth to something along the lines of 1 Megabit/sec or around 100 transactions per second which would mean each user could only do about 2 transactions per month and you are only involving about 1% of the world population in this network.   This network would be generating 10 GB / month or 120 GB / year in transactions.   Lets assume we could prune 50% of the transactions, 1 year would be 60 GB of data.

Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.

B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account.   This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.

C) The resulting database size would be 200 GB without any indexes or other data structures. 

D) To create a sha256 merkle tree on these accounts would require 64 GB

E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB

Conclusion:  The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.   

The end result is that the account tree and full-block chain system have identical support for transaction volume, with only about a 6x gain in data storage efficiency or break even with 6 years of transaction volume.

Clearly the bandwidth is the bottle neck of scalability and not the data storage.    If you allow the bandwidth to scale enough to accommodate the transaction volume of VISA then everyone would require a 1 Gigabit connection to the internet at which point you are already well beyond the scale of the average individual and well into the realm of centralized financial institutions which would be logging every transaction forever anyway, the account tree system would just be extra book-keeping for these organizations which would probably maintain a separate index optimized for their queries.

A decentralized blockchain is transaction rate limited, not storage limited.   If the only change you made to the blockchain was to automatically expire / invalidate any unspent output more than 12 months old you would solve the data storage problem, the dust problem, the bootstrap problem, and the lost-key problem.   And you would be left with the same scalability problems as the account-tree based approach. 

What I conclude is that the account tree system at most provides some benefits for medium-scale systems involving perhaps 1 million users but is entirely irrelevant once you scale to the size Bitcoin aims to achieve.


wow you clearly have a deep understanding of the limitations of the bitcoin protocol. this post alone has caused me to value your input so if you dont mind me asking, how do you believe the scalability problem will be addressed?

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
July 15, 2013, 03:08:25 AM
 #186

The solution to scalability must be parallel chains each supporting perhaps 500K users max.   Unfortunately, this would mean that there would be 1000's of crypto currencies and markets for trading between them as they would not be fungible.   You would need a crypto-currency that had some other properties that drive its value so that it is effectively pegged against some outside unit of value while still remaining 100% trust-free.  As a result it wouldn't matter which 'alt-chain' you were on, your unit of account would be dominated in 'silver'.

I believe there is a continuum between decentralized, trust-free and expensive and centralized, trust-based, and cheap.    

I believe a blockchain must make a commitment to a maximum bandwidth that makes the chain accessible to everyone who can afford the fees for transacting on the network.   Enable efficient cross-chain-trading and most users would only need to live on one chain and could easily trade / spend to other chains as necessary.

The reason why I have thought about this problem very in depth is because of my work on the BitShares protocol which was attempting to utilize an 'account tree' like system.   There are significant space requirements for large merkle trees that only update a small fraction of the tree.  If you opt to save space on your merkle tree, you quickly become CPU bound.  Ultimately you realize you want a lot of 'mini-merkle trees', say one every 10 minutes, and that is when I realized why Bitcoin had to be implemented like it is.    

*edit*   One additional feature of all of these chains is the requirement that all transaction outputs be spent within 12 months so you can limit your long-term storage requirements to something that the average user could support.   This means that each user is committed to 1 transaction per year min and that will put an upper limit on the number of users who can possibly use a given chain to something around 1 million for a reasonable bandwidth and only a few transactions per year per user.



https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
July 15, 2013, 06:29:21 AM
Last edit: July 15, 2013, 07:16:30 AM by bitfreak!
 #187

Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.

B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account.   This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.

C) The resulting database size would be 200 GB without any indexes or other data structures.

D) To create a sha256 merkle tree on these accounts would require 64 GB

E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB

Conclusion:  The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.  
The main thing that you are not taking into consideration is the fact that we wont reach 1 billion accounts in the account tree for an extremely long time, and by then it wont be unreasonable to expect people to deal with those sorts of large data sets (presumably). Now calculate how long it would take for the bitcoin blockchain to reach 300GB at the current rate of growth. Not too long I'm willing to bet, even with good pruning.

Furthermore, each account will be much smaller than 200 bytes, it will be closer to the 54 byte example you gave on the last page. No higher than 80 bytes in the worste case. If we assume 60 bytes instead of 200 bytes per account you'll find that it's only 55 gigabytes required. Also, the mini-blockchain will probably keep 1 weeks history or less, a full month is far too long if we need to account for very large transaction rates.

EDIT: But I do agree the system is not perfect and has its limitations, like any decentralized system. The answer is multiple competing crypto-currencies as you mentioned in your last post. But I don't think we would need thousands or even hundreds of coins, if we were to use the mini-blockchain / account tree scheme for those crypto-currencies, a few dozen or so could handle the entire worlds transaction needs I believe.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
July 15, 2013, 07:40:16 AM
 #188

Some thoughts on the merits of an account tree approach:
...

Btw what do you think about scalability of Ripple?
slothbag
Sr. Member
****
Offline Offline

Activity: 369
Merit: 250



View Profile
July 15, 2013, 08:03:51 AM
Last edit: July 15, 2013, 08:33:35 AM by slothbag
 #189

Btw what do you think about scalability of Ripple?

Great question, something I'd like an answer too also.. Ripple seems like the perfect fit for a multi currency scenario, dozens of crypto currencies could be traded seamlessly and easily using another decentralised solution.  But then if Ripple was capable of sustaining world wide transaction volume then why bother with a dozen other crypto's? Just stick with XRP or something similar using the protocol.

From what I understand of the consensus approach is each transaction is actually broadcast amongst validators multiple times until consensus is reached, therefore I would assume bandwidth consumption is perhaps higher than bitcoin when comparing similar transaction volume.

Edit: Oh yeah, and after only 6 months of low transaction volume the storage requirements for ripple are more than the bitcoin blockchain after 4-5 years.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
July 15, 2013, 09:22:37 AM
 #190

Some thoughts on the merits of an account tree approach:
...

Btw what do you think about scalability of Ripple?
Well until we actually have a purely P2P and open source version of Ripple in operation that seems like a mute question to me.
The only reason Ripple is able to do some of the things it does is because it makes use of centralized servers.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
July 15, 2013, 10:09:33 AM
 #191

Some thoughts on the merits of an account tree approach:
...

Btw what do you think about scalability of Ripple?
Well until we actually have a purely P2P and open source version of Ripple in operation that seems like a mute question to me.
The only reason Ripple is able to do some of the things it does is because it makes use of centralized servers.

Yeap. I think if you want fast VISA-like transaction processing centalization (like Ripple today) or at least fedearation (like OT today and hopefully Ripple in the future) is inevitable. But frankly speaking scaling is still a minor problem unless you really want to compete with VISA. I would happily trade it for additional "extensibility" and rich functionality.
Anon136
Legendary
*
Offline Offline

Activity: 1722
Merit: 1217



View Profile
July 15, 2013, 02:58:41 PM
 #192

The solution to scalability must be parallel chains each supporting perhaps 500K users max.   Unfortunately, this would mean that there would be 1000's of crypto currencies and markets for trading between them as they would not be fungible.   You would need a crypto-currency that had some other properties that drive its value so that it is effectively pegged against some outside unit of value while still remaining 100% trust-free.  As a result it wouldn't matter which 'alt-chain' you were on, your unit of account would be dominated in 'silver'.

I believe there is a continuum between decentralized, trust-free and expensive and centralized, trust-based, and cheap.    

I believe a blockchain must make a commitment to a maximum bandwidth that makes the chain accessible to everyone who can afford the fees for transacting on the network.   Enable efficient cross-chain-trading and most users would only need to live on one chain and could easily trade / spend to other chains as necessary.

The reason why I have thought about this problem very in depth is because of my work on the BitShares protocol which was attempting to utilize an 'account tree' like system.   There are significant space requirements for large merkle trees that only update a small fraction of the tree.  If you opt to save space on your merkle tree, you quickly become CPU bound.  Ultimately you realize you want a lot of 'mini-merkle trees', say one every 10 minutes, and that is when I realized why Bitcoin had to be implemented like it is.    

*edit*   One additional feature of all of these chains is the requirement that all transaction outputs be spent within 12 months so you can limit your long-term storage requirements to something that the average user could support.   This means that each user is committed to 1 transaction per year min and that will put an upper limit on the number of users who can possibly use a given chain to something around 1 million for a reasonable bandwidth and only a few transactions per year per user.




Hm i think off chain transactions for small to medium sided transactions and the blockchain for large transactions and as a clearing house to be used by the firms that provide the off chain accounting is a better solution than 1000 blockchains.

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 566

fractally


View Profile WWW
July 15, 2013, 08:35:49 PM
 #193

The market can balance the # of chains vs the trx fees vs the demand for decentralization.  You would only have 1000 chains if there was high demand for decentralization.

There is another technique that is probably just as effective as account trees and that is the use of smart compression of both the transaction data transmitted and the database.

In the current block chain there is a ton of redundant info:  same address in multiple transactions, trx id referenced once for each input is stored multiple times if a trx has many outputs.    These are all 32 byte numbers that could be reduced to 4 to 8 bytes and yield a 50% savings for the second use and 75% for each subsequent use.     With a proper protocol for agreeing on what these identifiers are (say first bits... ) I estimate you could double the transaction volume for equal bandwidth and half the data storage requirements.

Combine this with a financial incentive to generate transactions that have more inputs than outputs and a one year maximum chain size and a DHT for storing 'pruned' transactions and you would have a solution that would probably be about the same size as the account tree.

https://fractally.com - the next generation of decentralized autonomous organizations (DAOs).
bybitcoin
Hero Member
*****
Offline Offline

Activity: 672
Merit: 500



View Profile
July 20, 2013, 06:49:37 PM
 #194

Hi BitFreak!
Nice idea and scheme, actually had an open eye on this thread for about a month. But since I didn't know how I can help, didn't jump in before.
I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)
Still if the problem is about finding developers to implement it, then why don't you try to use the Python framework (as the head and glue) to define and construct the building codes and then write integrate the parts into it by using other proper languages like c or java or whatever. In that case, I may also be able to contribute a part to the development.
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
July 20, 2013, 07:24:43 PM
 #195

I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)

Will you be interested in trying out a strong privacy schemes like zerocoin? When the prototype will be ready, you could really help with that as there are not many people around who really understand all the details of it.

Regarding doing everything in Python: there is no solid codebase like in case of bitcoinj that we can use and python won't give much of the advantage in development speed compared to Java. So it doesn't make much sense to do a rough prototype in Python and then throwing it away.
bybitcoin
Hero Member
*****
Offline Offline

Activity: 672
Merit: 500



View Profile
July 20, 2013, 09:06:19 PM
 #196

I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)

Will you be interested in trying out a strong privacy schemes like zerocoin? When the prototype will be ready, you could really help with that as there are not many people around who really understand all the details of it.
Yes I will Smiley
Regarding doing everything in Python: there is no solid codebase like in case of bitcoinj that we can use and python won't give much of the advantage in development speed compared to Java. So it doesn't make much sense to do a rough prototype in Python and then throwing it away.
[/quote] I just meant using python as a glue and accelerator, but you seem right, Java would be a cleaner and wiser choice.
stellarman
Newbie
*
Offline Offline

Activity: 60
Merit: 0


View Profile
July 28, 2013, 01:00:52 AM
 #197

What other help is needed on this project. I believe in what you are doing, and would like to help, but I am not a programmer.

Is some development occurring?
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


View Profile
July 28, 2013, 05:27:35 AM
 #198

Is this project going to support colored coins and multi-sig ?

Both are important to my own project.

co-founder, Monetas
creator, Open-Transactions
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
July 28, 2013, 10:46:32 AM
 #199

Is this project going to support colored coins and multi-sig ?

Both are important to my own project.
Yes it should be capable of handling multi-sig transactions and other types of complex transactions like bitcoin, but probably not all the types of transactions that bitcoin supports. And I'm not exactly sure how colored coins are supposed to work, but it seems like something which is layered on top of bitcoin and I see no reason it couldn't be layered on top of the mini-blockchain scheme in a similar way. Of course we could include something in the protocol which makes it easier to "color" coins. I'd need to look into the colored coin idea more before giving you a proper answer.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


View Profile
July 28, 2013, 10:51:50 PM
 #200

Is this project going to support colored coins and multi-sig ?

Both are important to my own project.
Yes it should be capable of handling multi-sig transactions and other types of complex transactions like bitcoin, but probably not all the types of transactions that bitcoin supports. And I'm not exactly sure how colored coins are supposed to work, but it seems like something which is layered on top of bitcoin and I see no reason it couldn't be layered on top of the mini-blockchain scheme in a similar way. Of course we could include something in the protocol which makes it easier to "color" coins. I'd need to look into the colored coin idea more before giving you a proper answer.

Colored coins allow you to use the blockchain for issuing real-world assets. Like issuing "gold ounce" units that are tracked on the blockchain.

In OT, this is useful for divorcing the issuer from the transaction server. (It works in combination with multi-sig.)

co-founder, Monetas
creator, Open-Transactions
kalon
Newbie
*
Offline Offline

Activity: 45
Merit: 0



View Profile
August 26, 2013, 02:14:33 AM
 #201

Is there continued movement on this project? I just read the white paper a couple days ago.  For the most part it's too complex for my tiny brain but it did touch on something aside from the unending block chain growth of Bitcoin which has bothered me for some time, the long term deflation. In the paper you had mentioned possibly expunging unused accounts after 100 years and considering the coins lost and to be recirculated. Personally I think the time should be far less than that but even 100 years would be an improvement.

I'd hate to see something as punitive as Freicoin but a system which encourages the use of the currency or at least the shuffling at some small cost seems like a good one to me. A successful long term Bitcoin economy would clearly be one in which wealthy people amass huge sums and with deflation just spend nearly endless fractions of coins in the future. It's a recipe for plutocracy far worse than we have today.

Forcing people to occasionally spend or move coins solves several problems: Lost coins can be remind and moved ensures there will be enough tx fees to keep miners happy. Both ensure a constant and fairly distributed money supply on a network which is well secured. The even money supply would also give a much better impression of the health of the network.

That's a wordy way of saying I think this project is on the right track and I hope there will be continued progress. Just don't forget about the importance of remining lost coins and consider a smaller time frame, perhaps 10 years. It should be a problem for most as long as the coins are first-in / first-out and perhaps a system of notification could be built into the client.

That's my ramble. I'd be happy to know your thoughts on this.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
August 26, 2013, 11:57:01 AM
 #202

Quote
Is there continued movement on this project?
I don't think there's really much happening with this project at the moment. lexxus said he would do some work on it this month but I don't know whether he has or hasn't. I've been pretty focused on other projects recently but the project funds are still sitting there waiting for anyone who wants to work on this project.

Quote
That's a wordy way of saying I think this project is on the right track and I hope there will be continued progress. Just don't forget about the importance of remining lost coins and consider a smaller time frame, perhaps 10 years. It should be a problem for most as long as the coins are first-in / first-out and perhaps a system of notification could be built into the client.
I very much agree with your sentiments concerning the re-mining of lost coins, but the reason why I don't want to put a lot of focus on re-mining is because 1) there are more important things that need to be done first and 2) it's a very controversial issue. I made a thread a while ago about the possibility of implementing re-mining lost coins into bitcoin and I found that many people strongly disagreed with the idea because it impinges on there ability to store coins in the same address for very long periods of time. The reason it needs to be at least 100 years is because then people feel safer about the idea and if they lose their coins they can't exactly say they weren't given enough time to move them.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
August 27, 2013, 08:51:59 AM
 #203

Quote
Is there continued movement on this project?
I don't think there's really much happening with this project at the moment. lexxus said he would do some work on it this month but I don't know whether he has or hasn't. I've been pretty focused on other projects recently but the project funds are still sitting there waiting for anyone who wants to work on this project.

Sorry for not keeping you posted. I've strated working on bitcoinj code but it's moving slowly. My first goal is to bring up network connectivity and basic block mining functionality.
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
August 27, 2013, 10:13:55 AM
 #204

Quote
Is there continued movement on this project?
I don't think there's really much happening with this project at the moment. lexxus said he would do some work on it this month but I don't know whether he has or hasn't. I've been pretty focused on other projects recently but the project funds are still sitting there waiting for anyone who wants to work on this project.

Sorry for not keeping you posted. I've strated working on bitcoinj code but it's moving slowly. My first goal is to bring up network connectivity and basic block mining functionality.
Good to hear, I just appreciate that someone is working on it. If you need a bit of funding to keep you going let me know. Also, how do you intend to do things like implement the proof chain? Will it be just as a chain of block headers or a chain of proof cells? I would suggest going with a normal chain of block headers because it'll be quicker and easier and the other method doesn't offer a huge advantage anyway.

If you have any questions about how something should be done, feel free to ask. Most of the uncertainties are documented in the wiki so I would recommend going through the project wiki if you haven't done so already. I recently disabled account creation for the wiki because there was so many spam accounts being created, but if you want an account so that you can edit things then I will create one for you manually.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
ndsdb
Newbie
*
Offline Offline

Activity: 49
Merit: 0


View Profile
September 27, 2013, 10:03:06 PM
 #205

Hi,

If any leftover job is here, i am ready to contribute.
AnonyMint
Hero Member
*****
Offline Offline

Activity: 518
Merit: 521


View Profile
October 15, 2013, 01:19:42 PM
 #206

Some thoughts on the merits of an account tree approach:

1) The purpose is to reduce the data storage requirements to allow the network to sync / scale faster and thereby keep the network more decentralized.

2) Blockchain size and sync/time are ultimately only part of the problem, the other part of the problem is transaction volume and bandwidth.   If the goal is to support 100 million users each of whom is able to run the software on their home PC / average internet connection without entirely saturating it, then you would have to limit your bandwidth to something along the lines of 1 Megabit/sec or around 100 transactions per second which would mean each user could only do about 2 transactions per month and you are only involving about 1% of the world population in this network.   This network would be generating 10 GB / month or 120 GB / year in transactions.   Lets assume we could prune 50% of the transactions, 1 year would be 60 GB of data.

Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.

B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account.   This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.

C) The resulting database size would be 200 GB without any indexes or other data structures. 

D) To create a sha256 merkle tree on these accounts would require 64 GB

E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB

Conclusion:  The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.   

The end result is that the account tree and full-block chain system have identical support for transaction volume, with only about a 6x gain in data storage efficiency or break even with 6 years of transaction volume.

Clearly the bandwidth is the bottle neck of scalability and not the data storage.    If you allow the bandwidth to scale enough to accommodate the transaction volume of VISA then everyone would require a 1 Gigabit connection to the internet at which point you are already well beyond the scale of the average individual and well into the realm of centralized financial institutions which would be logging every transaction forever anyway, the account tree system would just be extra book-keeping for these organizations which would probably maintain a separate index optimized for their queries.

A decentralized blockchain is transaction rate limited, not storage limited.   If the only change you made to the blockchain was to automatically expire / invalidate any unspent output more than 12 months old you would solve the data storage problem, the dust problem, the bootstrap problem, and the lost-key problem.   And you would be left with the same scalability problems as the account-tree based approach. 

What I conclude is that the account tree system at most provides some benefits for medium-scale systems involving perhaps 1 million users but is entirely irrelevant once you scale to the size Bitcoin aims to achieve.  
The main thing that you are not taking into consideration is the fact that we wont reach 1 billion accounts in the account tree for an extremely long time, and by then it wont be unreasonable to expect people to deal with those sorts of large data sets (presumably). Now calculate how long it would take for the bitcoin blockchain to reach 300GB at the current rate of growth. Not too long I'm willing to bet, even with good pruning.

Furthermore, each account will be much smaller than 200 bytes, it will be closer to the 54 byte example you gave on the last page. No higher than 80 bytes in the worste case. If we assume 60 bytes instead of 200 bytes per account you'll find that it's only 55 gigabytes required. Also, the mini-blockchain will probably keep 1 weeks history or less, a full month is far too long if we need to account for very large transaction rates.

EDIT: But I do agree the system is not perfect and has its limitations, like any decentralized system. The answer is multiple competing crypto-currencies as you mentioned in your last post. But I don't think we would need thousands or even hundreds of coins, if we were to use the mini-blockchain / account tree scheme for those crypto-currencies, a few dozen or so could handle the entire worlds transaction needs I believe.

USA is way behind rest of the world, e.g. Hong Kong residents can get 0.5 Gbps for $25 monthly. This is due to telcom monopolies. Google is installing 1 gigabit where it can:

http://www.huffingtonpost.com/2013/07/24/us-internet-speed_n_3645927.html

So the USA crashes and burns in a heap of socialism debris. Bitcoin moves to Asia where the future is.

Also as we make our way through this global financial implosion, the mainstream are going to herd with the socialism and not adopt the new technology. It is only AFTER the destruction of their financial system, after the reset they make their way to the new thing. So mostly you will see the adoption of the digital coins limited to the astute who want to jump off the Titantic:

https://bitcointalk.org/index.php?topic=279771.msg3340053#msg3340053

We shouldn't have the scaling problems, because by the time the mainstream comes on board after 2033 (when mining ceases in Bitcoin), the relevant places of growth in the reset economy will have more than 1 gigabit connections.

unheresy.com - Prodigiously Elucidating the Profoundly ObtuseTHIS FORUM ACCOUNT IS NO LONGER ACTIVE
CoinHoarder
Legendary
*
Offline Offline

Activity: 1484
Merit: 1026

In Cryptocoins I Trust


View Profile
December 06, 2013, 05:07:35 AM
 #207

Is this project still under development? No updates since August 27, 2013 Cry
bitfreak! (OP)
Legendary
*
Offline Offline

Activity: 1536
Merit: 1000


electronic [r]evolution


View Profile WWW
December 06, 2013, 05:27:13 AM
 #208

Is this project still under development? No updates since August 27, 2013 Cry

I gave up on trying to form a team of developers and instead set up a bounty:

[BOUNTY] $20,000 Mini-Blockchain Implementation

I heard rumors that some people were working on an implementation but the bounty is still unclaimed so far.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
CoinHoarder
Legendary
*
Offline Offline

Activity: 1484
Merit: 1026

In Cryptocoins I Trust


View Profile
December 06, 2013, 05:41:05 AM
 #209

Is this project still under development? No updates since August 27, 2013 Cry

I gave up on trying to form a team of developers and instead set up a bounty:

[BOUNTY] $20,000 Mini-Blockchain Implementation

I heard rumors that some people were working on an implementation but the bounty is still unclaimed so far.

Thanks for the update! I'm glad to see you made a bounty for this, how selfless of you. I hope someone comes through and claims this bounty. Block chain bloat is something I think will become a problem in the future.
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
January 30, 2014, 07:36:35 PM
 #210

We're looking to implement this (or a reasonably similar system).

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
aminorex
Legendary
*
Offline Offline

Activity: 1596
Merit: 1029


Sine secretum non libertas


View Profile
July 12, 2014, 04:09:16 PM
 #211

track

Give a man a fish and he eats for a day.  Give a man a Poisson distribution and he eats at random times independent of one another, at a constant known rate.
Pages: 1 2 3 4 5 6 7 8 9 10 11 [All]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!