Bitcoin Forum
December 14, 2017, 01:28:06 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
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 23221 times)
bitfreak!
Legendary
*
Offline Offline

Activity: 1535


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
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513214886
Hero Member
*
Offline Offline

Posts: 1513214886

View Profile Personal Message (Offline)

Ignore
1513214886
Reply with quote  #2

1513214886
Report to moderator
bitfreak!
Legendary
*
Offline Offline

Activity: 1535


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


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

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


bitfreak!
Legendary
*
Offline Offline

Activity: 1535


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

Activity: 238



View Profile WWW
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.
lexxus
Sr. Member
****
Offline Offline

Activity: 322


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


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



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

Activity: 1535


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



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
Hero Member
*****
Offline Offline

Activity: 798


Stack-overflow Guru


View Profile WWW
June 08, 2013, 07:13:58 AM
 #91

Added a proposed feature to the netcoin wiki:

http://www.netcoin.io/wiki/Theft_Protection_through_Reversibility_and_Failsafe_Accounts

▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
        AltCoinInternalExperts                Get Your Altcoin Promoted On Social Media       
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lexxus
Sr. Member
****
Offline Offline

Activity: 322


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


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

BetterCoin ?
Better Crypto Currency => BCC ?

r3wt
Hero Member
*****
Offline Offline

Activity: 686


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

Activity: 1535


electronic [r]evolution


View Profile WWW
June 08, 2013, 06:34:57 PM
 #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



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

BitShares


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://steemit.com  Blogging is the new Mining
bitfreak!
Legendary
*
Offline Offline

Activity: 1535


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

BitShares


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://steemit.com  Blogging is the new Mining
bytemaster
Hero Member
*****
Offline Offline

Activity: 770

BitShares


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://steemit.com  Blogging is the new Mining
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!