Will there be a multicoin explorer?
It shouldn't be too hard to make Abe parse MultiCoin configurations. Weeds explorer: http://abe.john-edwin-tobey.org/
Topic: New release of MultiCoin client a branch of the BitCoin client - page 2. (Read 33869 times)
It shouldn't be too hard to make Abe parse MultiCoin configurations. Weeds explorer: http://abe.john-edwin-tobey.org/
Will there be a multicoin explorer?
What do you get if you complete a block on the weeds network?
Although it looks like all my (or at least my first few so far) blocks are being rejected. This is because I am using diablo and two 6870's am I right?
So what happens if user B has Subsidy=500 and user A has Subsidy=5000
Although it looks like all my (or at least my first few so far) blocks are being rejected. This is because I am using diablo and two 6870's am I right?
So what happens if user B has Subsidy=500 and user A has Subsidy=5000
The MultiCoin client is a slightly modified and very experimental Bitcoin client that allows transactions with an unlimited number of crypto currencies block chains and also the creation of new crypto chains. Each different crypto currency can have a different set of rules and a different root block that is controlled by settings in the MultiCoin config file.
Is there rules for demurrage?
With each transaction, a percentage of each input is destroyed multiplied for the difference between this block number and the block number of the previous transaction for the input.
Status of MultiCoin-exp branch and merge mining
This article Last Updated 7/6/11
I finally made some progress on merge mining in the MultiCoin-exp branch. With the setup of a cpuminer branch from forrestv found at: https://github.com/forrestv/cpuminer comitish: f7617f3f7c0eb348e1bf2af21ed5d965f05df24d
This miner was chosen as being the only known miner with algorithms that works best at difficulties less than one as we plan to use this with mergemineTEST net as parent chain that is presently at "difficulty" : 0.12500000. At that same time the weedsnet was at "difficulty" : 0.06249911,
and my present build of MultiCoin-exp used to run both the parent and child chains at comitish:
4e13e3527eca861964bb
I had two multicoin-exp bitcoind running with the bitcoin.config.weeds with port settings of 38333 and rpcport of 38332 and bitcoin.config.mergmine that has port settings of 58333 and rpcport of 58332
these example configs have been released and can be seen at these url bellow:
http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.mergmineTEST
http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.weeds
to start we playing with weedsnet as the child chain and a newly created mergemineTEST chain used as a parent for the weedsnet chain.
setup merged-mine-proxy to run with corrected username:password here:
./merged-mine-proxy --parent-url http://yourusername:[email protected]:58332/ --aux-url http://yourusername:[email protected]:38332/ -w 9992
setup cpuminer
./minerd --url http://127.0.0.1:9992/ --userpass yourusername:yourpassword -t 1
I was getting these results from the miner
[2011-07-24 17:44:35] JSON-RPC call failed: {
"message": "Unknown error: -32601 Method not found ''",
"data": "",
"code": -32099
}
due to the fact that the documented method shown in merged-mine-proxy shows:
help='connect to the parent RPC at this address (default: http://pw:[email protected]:8332/)' with reversed pw : un that should be un : pw. So this took some instrumented lines for me to figure out but finally got results when corrected.
we now have a working proto type merge mine setup using mergemineTEST net as the parent chain for weedsnet. This has been done with the new released changes from namecoin mergedmine branch release of commit 6849ac73f3577c1b445787993d134a596c89c09b that has again been merged with MultiCoin-exp. The changes for MultiCoin-exp have now been released at: https://github.com/sacarlson/MultiCoin-exp as commit 4e13e3527eca861964bb. I noted that I couldn't use weedsnet as the parent for MergemineTEST net due to the fact that the difficulties for weeds were smaller than that of MergemineTEST net. This was noted by the error seen from the console of mergeminTEST of:
ERROR: AUX POW parent hash 0000000964b614867559487da64722a0e4876de8fbc45e3b15bd7e07b2f03625 is not under target 00000007fff80000000000000000000000000000000000000000000000000000
When I reversed the nets parent for child everything worked fine. as seen from miner-proxy:
2011-07-26T13:11:47.651525,solve,0,1
2011-07-26T13:16:25.894304,solve,1,1
and noteing results in block counts of both networks on the rise. So later I will right some more detailed procedures to make clear what needed to be done.
Update: I've also merged the new changes from namecoin that now allow multi chained networks
2011-08-03T03:35:59.129965,solve,1,0,1
in this example I now have one parent and two aux chains by just running more multicoind configs and adding more --aux-url chains on the merge-miner-proxy line with space delimiter
./merged-mine-proxy --parent-url http://yourusername:[email protected]:38332/ --aux-url http://yourusername:[email protected]:10332/ http://yourusername:[email protected]:58332/ -w 9992
I've also created another merge mined chain config for BeerTokens in preliminary review published at: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.beerA . it's set to pay .0001 for each mined block at a difficulty at block 1000 set to be 23509.0 designed to be mining by namecoin miners as the parent. AuxPowStartBlock point is set to start at block 1000 for AuxPowStartBlock that could be from 1 to 4 days depending on mining activity. I guess we are ready to go just need miners to partisipate.
first problem detected not in MultiCoin-exp but in the infrastructure of our block explorer bitcoin-abe I'm getting this error from a fresh start of abe.py , when I run the weeds network in the merge mining mode. I had planed to upgrade the weeds network as soon as possible to merge mining when we have a solution for this. I now get this error OverflowError: long int too large to convert to int detailed trace see: http://paste.ubuntu.com/652878/, Update 7/6/11 This problem now fixed in the new release of bitcoin-abe we now have support for merge mining in a block explorer thanks again to John Tobey.
Update Aug 4, 2011 8:30pm BKK. I found we have a big bug in the new Diff_post_triger and Diff_triger_block config settings in MultiCoin-exp that cause orphaned blocks after block 12 when starting a new system from an empty datadir. So this feature will have to eather be fixed or not used. This feature has only been used on the one config file http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.beerA so the beerA chain is down until this is fixed. I'll take a closer look at it tomaro. This is what happens when you try to do too much tooo fast.
Update Aug 5, 2011 4:59pm BKK. bug above wasn't as bad as I had thought. it was just that I had changed the block position after it past the point, so from fresh start it would fail with orphaned blocks. I put the setting of Diff_triger_block=11 back and every thing worked fine. so I also added another set of values Diff_triger_blockB=1510 Diff_post_trigerB=453237473 and moved the AuxPowStartBlock=1500 to now enable merge mining at block 1500 instead of 1000 to give more time for testing. We are now back on track all systems go.
Update Aug 14, 2011 6:34pm BKK. I seem to have a problem with slow mining using merge mining as it's taken 7 hours to get this 2011-08-14T10:09:41.168619,solve,0,0,1,1,1
I've got many of these 2011-08-14T09:53:57.364787,solve,0,0,0,1,1
the "difficulty" : 0.06198025, one the 2nd aux in this case mm2TEST should not have taken 7 hours
this is with 270kh/sec miner
I see no errors but it just seems very slow to mine
;;bc,calcd 270 0.061 shows it I should get gribble: The average time to generate a block at 270 Khps, given the supplied difficulty of 0.061, is 16 minutes and 10 seconds
I used this in the proxy line:
/home/sacarlson/Downloads/mmproxy --parent-url http://yourusername:[email protected]:48332/ --aux-url http://yourusername:[email protected]:10332/ http://yourusername:[email protected]:12332/ http://yourusername:[email protected]:14332/ http://yourusername:[email protected]:13332/ --merkle-size 4 -w 9992
This is using MultiCoin-exp that uses vinced merged mining code for merge mining with chain configs, bitcoin.conf.namecoin diff 94035.90217415 as parent, aux1 beerA difficulty 50.0, aux2 mm2TEST diff 0.06198025, aux3 mm4TEST diff 0.01475864, aux4 mm3TEST diff 0.00441692,
anyone else getting slow results with merge mining test or did i configure something wrong or maybe my code problems? I'll try some simpler experiments with just a parent and 1 aux to take a closer look at results. I'm using my latest Multicoin-exp release in github commit 06602e7e09875d0e8a46 the multicoin config files are published at: http://exchange.beertokens.info/docs/multicoin/
Update 8/15/11 10:58am BKK:
I ran another merge mine experiment of just parent and one aux with new difficulties parent of .062 and aux chain diff .010
experment ran with 280kh/sec run from 15:07 block2 to 3:25 block 52 = about 14.4minits per block on both parent and aux chain
so the good news is I get about what I would expect on the parent chain ;;bc,calcd 280 0.062
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.062, is 15 minutes and 51 seconds
The bad news is I don't get as much as I would expect from the aux chain. I just don't have a full understanding why.
;;bc,calcd 280 0.010
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.010, is 2 minutes and 33 seconds
sample as seen from proxy:
2011-08-14T15:07:12.921571,solve,1,1
2011-08-14T15:08:53.573864,solve,1,1
2011-08-14T15:32:25.379898,solve,1,1
2011-08-14T15:44:39.154894,solve,1,1
2011-08-14T15:52:37.380143,solve,1,1
2011-08-14T16:08:12.520307,solve,1,1
2011-08-14T16:14:12.460611,solve,1,1
2011-08-14T16:38:22.869591,solve,1,1
2011-08-14T16:42:50.560368,solve,1,1
2011-08-14T16:52:16.580440,solve,1,1
2011-08-14T17:04:32.321299,solve,1,1
2011-08-14T17:06:32.312406,solve,1,1
2011-08-14T17:11:56.703054,solve,1,1
2011-08-14T17:15:28.470930,solve,1,1
2011-08-14T17:31:32.309536,solve,1,1
2011-08-14T17:43:20.232165,solve,1,1
2011-08-14T17:49:24.424827,solve,1,1
2011-08-14T18:04:56.335914,solve,1,1
This article Last Updated 7/6/11
I finally made some progress on merge mining in the MultiCoin-exp branch. With the setup of a cpuminer branch from forrestv found at: https://github.com/forrestv/cpuminer comitish: f7617f3f7c0eb348e1bf2af21ed5d965f05df24d
This miner was chosen as being the only known miner with algorithms that works best at difficulties less than one as we plan to use this with mergemineTEST net as parent chain that is presently at "difficulty" : 0.12500000. At that same time the weedsnet was at "difficulty" : 0.06249911,
and my present build of MultiCoin-exp used to run both the parent and child chains at comitish:
4e13e3527eca861964bb
I had two multicoin-exp bitcoind running with the bitcoin.config.weeds with port settings of 38333 and rpcport of 38332 and bitcoin.config.mergmine that has port settings of 58333 and rpcport of 58332
these example configs have been released and can be seen at these url bellow:
http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.mergmineTEST
http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.weeds
to start we playing with weedsnet as the child chain and a newly created mergemineTEST chain used as a parent for the weedsnet chain.
setup merged-mine-proxy to run with corrected username:password here:
./merged-mine-proxy --parent-url http://yourusername:[email protected]:58332/ --aux-url http://yourusername:[email protected]:38332/ -w 9992
setup cpuminer
./minerd --url http://127.0.0.1:9992/ --userpass yourusername:yourpassword -t 1
I was getting these results from the miner
[2011-07-24 17:44:35] JSON-RPC call failed: {
"message": "Unknown error: -32601 Method not found ''",
"data": "",
"code": -32099
}
due to the fact that the documented method shown in merged-mine-proxy shows:
help='connect to the parent RPC at this address (default: http://pw:[email protected]:8332/)' with reversed pw : un that should be un : pw. So this took some instrumented lines for me to figure out but finally got results when corrected.
we now have a working proto type merge mine setup using mergemineTEST net as the parent chain for weedsnet. This has been done with the new released changes from namecoin mergedmine branch release of commit 6849ac73f3577c1b445787993d134a596c89c09b that has again been merged with MultiCoin-exp. The changes for MultiCoin-exp have now been released at: https://github.com/sacarlson/MultiCoin-exp as commit 4e13e3527eca861964bb. I noted that I couldn't use weedsnet as the parent for MergemineTEST net due to the fact that the difficulties for weeds were smaller than that of MergemineTEST net. This was noted by the error seen from the console of mergeminTEST of:
ERROR: AUX POW parent hash 0000000964b614867559487da64722a0e4876de8fbc45e3b15bd7e07b2f03625 is not under target 00000007fff80000000000000000000000000000000000000000000000000000
When I reversed the nets parent for child everything worked fine. as seen from miner-proxy:
2011-07-26T13:11:47.651525,solve,0,1
2011-07-26T13:16:25.894304,solve,1,1
and noteing results in block counts of both networks on the rise. So later I will right some more detailed procedures to make clear what needed to be done.
Update: I've also merged the new changes from namecoin that now allow multi chained networks
2011-08-03T03:35:59.129965,solve,1,0,1
in this example I now have one parent and two aux chains by just running more multicoind configs and adding more --aux-url chains on the merge-miner-proxy line with space delimiter
./merged-mine-proxy --parent-url http://yourusername:[email protected]:38332/ --aux-url http://yourusername:[email protected]:10332/ http://yourusername:[email protected]:58332/ -w 9992
I've also created another merge mined chain config for BeerTokens in preliminary review published at: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.beerA . it's set to pay .0001 for each mined block at a difficulty at block 1000 set to be 23509.0 designed to be mining by namecoin miners as the parent. AuxPowStartBlock point is set to start at block 1000 for AuxPowStartBlock that could be from 1 to 4 days depending on mining activity. I guess we are ready to go just need miners to partisipate.
first problem detected not in MultiCoin-exp but in the infrastructure of our block explorer bitcoin-abe I'm getting this error from a fresh start of abe.py , when I run the weeds network in the merge mining mode. I had planed to upgrade the weeds network as soon as possible to merge mining when we have a solution for this. I now get this error OverflowError: long int too large to convert to int detailed trace see: http://paste.ubuntu.com/652878/, Update 7/6/11 This problem now fixed in the new release of bitcoin-abe we now have support for merge mining in a block explorer thanks again to John Tobey.
Update Aug 4, 2011 8:30pm BKK. I found we have a big bug in the new Diff_post_triger and Diff_triger_block config settings in MultiCoin-exp that cause orphaned blocks after block 12 when starting a new system from an empty datadir. So this feature will have to eather be fixed or not used. This feature has only been used on the one config file http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.beerA so the beerA chain is down until this is fixed. I'll take a closer look at it tomaro. This is what happens when you try to do too much tooo fast.
Update Aug 5, 2011 4:59pm BKK. bug above wasn't as bad as I had thought. it was just that I had changed the block position after it past the point, so from fresh start it would fail with orphaned blocks. I put the setting of Diff_triger_block=11 back and every thing worked fine. so I also added another set of values Diff_triger_blockB=1510 Diff_post_trigerB=453237473 and moved the AuxPowStartBlock=1500 to now enable merge mining at block 1500 instead of 1000 to give more time for testing. We are now back on track all systems go.
Update Aug 14, 2011 6:34pm BKK. I seem to have a problem with slow mining using merge mining as it's taken 7 hours to get this 2011-08-14T10:09:41.168619,solve,0,0,1,1,1
I've got many of these 2011-08-14T09:53:57.364787,solve,0,0,0,1,1
the "difficulty" : 0.06198025, one the 2nd aux in this case mm2TEST should not have taken 7 hours
this is with 270kh/sec miner
I see no errors but it just seems very slow to mine
;;bc,calcd 270 0.061 shows it I should get gribble: The average time to generate a block at 270 Khps, given the supplied difficulty of 0.061, is 16 minutes and 10 seconds
I used this in the proxy line:
/home/sacarlson/Downloads/mmproxy --parent-url http://yourusername:[email protected]:48332/ --aux-url http://yourusername:[email protected]:10332/ http://yourusername:[email protected]:12332/ http://yourusername:[email protected]:14332/ http://yourusername:[email protected]:13332/ --merkle-size 4 -w 9992
This is using MultiCoin-exp that uses vinced merged mining code for merge mining with chain configs, bitcoin.conf.namecoin diff 94035.90217415 as parent, aux1 beerA difficulty 50.0, aux2 mm2TEST diff 0.06198025, aux3 mm4TEST diff 0.01475864, aux4 mm3TEST diff 0.00441692,
anyone else getting slow results with merge mining test or did i configure something wrong or maybe my code problems? I'll try some simpler experiments with just a parent and 1 aux to take a closer look at results. I'm using my latest Multicoin-exp release in github commit 06602e7e09875d0e8a46 the multicoin config files are published at: http://exchange.beertokens.info/docs/multicoin/
Update 8/15/11 10:58am BKK:
I ran another merge mine experiment of just parent and one aux with new difficulties parent of .062 and aux chain diff .010
experment ran with 280kh/sec run from 15:07 block2 to 3:25 block 52 = about 14.4minits per block on both parent and aux chain
so the good news is I get about what I would expect on the parent chain ;;bc,calcd 280 0.062
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.062, is 15 minutes and 51 seconds
The bad news is I don't get as much as I would expect from the aux chain. I just don't have a full understanding why.
;;bc,calcd 280 0.010
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.010, is 2 minutes and 33 seconds
sample as seen from proxy:
2011-08-14T15:07:12.921571,solve,1,1
2011-08-14T15:08:53.573864,solve,1,1
2011-08-14T15:32:25.379898,solve,1,1
2011-08-14T15:44:39.154894,solve,1,1
2011-08-14T15:52:37.380143,solve,1,1
2011-08-14T16:08:12.520307,solve,1,1
2011-08-14T16:14:12.460611,solve,1,1
2011-08-14T16:38:22.869591,solve,1,1
2011-08-14T16:42:50.560368,solve,1,1
2011-08-14T16:52:16.580440,solve,1,1
2011-08-14T17:04:32.321299,solve,1,1
2011-08-14T17:06:32.312406,solve,1,1
2011-08-14T17:11:56.703054,solve,1,1
2011-08-14T17:15:28.470930,solve,1,1
2011-08-14T17:31:32.309536,solve,1,1
2011-08-14T17:43:20.232165,solve,1,1
2011-08-14T17:49:24.424827,solve,1,1
2011-08-14T18:04:56.335914,solve,1,1
OK I have deleted all my previous text because it was just a mess of me trying to get it to work.
I have 1 connection and I have a weeds address:
mtSJ6gyJyhnqRokpEsp9GLafSMvuhkrAqN
If I try and connect to it with a miner such as diablo I get ThreadRPCServer incorrect password attempt
I have tried changing the password and changing the bitcoin.conf file
trying both un and pw and yourusername and yourpassword
*edit: I just had un and pw round the wrong way lol
I have 1 connection and I have a weeds address:
mtSJ6gyJyhnqRokpEsp9GLafSMvuhkrAqN
If I try and connect to it with a miner such as diablo I get ThreadRPCServer incorrect password attempt
I have tried changing the password and changing the bitcoin.conf file
trying both un and pw and yourusername and yourpassword
*edit: I just had un and pw round the wrong way lol
So who is looking to start a new block chain?
I've been thinking about starting one for Australia and New Zealand but my understanding is that if you try to make something country specific it might break some laws because you are making another currency for that country. Bitcoin doesn't have this problem because its a currency for the whole world e.g. laws making it illegal to make another US currency don't apply because its a world currency.
The other suggestion I have is an alternate namecoin perhaps something like numbercoin where you can use them to register any names under any numeric tld for instance .1 or .2
or perhaps tldcoin where you can register tlds
I've been thinking about starting one for Australia and New Zealand but my understanding is that if you try to make something country specific it might break some laws because you are making another currency for that country. Bitcoin doesn't have this problem because its a currency for the whole world e.g. laws making it illegal to make another US currency don't apply because its a world currency.
The other suggestion I have is an alternate namecoin perhaps something like numbercoin where you can use them to register any names under any numeric tld for instance .1 or .2
or perhaps tldcoin where you can register tlds
I hope and pray that the official bitcoin client will someday support multiple block chains, all backed by the hashing of the normal bitcoin network and the value of bitcoins held in escrow by the network. This would allow seemless transitions of your *coins between block chains without any need for an exchange. See my thoughts on it here: http://forum.bitcoin.org/index.php?topic=31032.0
+1 for backing with escrowed.coins. This is the key to a swcre and sustainable system. Backing with hashing power is not sustainable.
I hope and pray that the official bitcoin client will someday support multiple block chains, all backed by the hashing of the normal bitcoin network and the value of bitcoins held in escrow by the network. This would allow seemless transitions of your *coins between block chains without any need for an exchange. See my thoughts on it here: http://forum.bitcoin.org/index.php?topic=31032.0
See the top article in the create new chain section for more details on that subject. If you need more help join us at #multicoin in freenode for direct assistance.
Thanks sacarlson.
I saw the create new genisis block text before, but it didn't quite give me everything I need. Between that text and your description of the namecoin port, I think I can at least get started.
I'm interested in using MultiCoin for a Stablecoin example currency (I'm calling 1971coin which will be pegged to the 1971 dollar). However, I'm having trouble figuring out where to start. Is there a getting started guide somewhere explaining how to start your own block chain using MultiCoin?
I would be willing to help develop the guide if you could help me out and I can post it on a wiki somewhere.
I would be willing to help develop the guide if you could help me out and I can post it on a wiki somewhere.
See the top article in the create new chain section for more details on that subject. If you need more help join us at #multicoin in freenode for direct assistance.
NameCoin Support added to MultiCoin and Multicoin-qt
Added support for the namecoin net for both MultiCoin and MultiCoin-qt with small changes and created an example bitcoin.conf.namecoin with namecoin chain specs. preliminary tested with MultiCoin and MulitCoin-qt have been a success. To use Multicoin-qt with namecoin I do it like this.
Create a directory /home/yourhome/.bitcoin/namecoin. Copy the file bitcoin.conf.namecoin from the MultiCoin-qt/doc/bitcoin.conf.namecoin into your new created ~/.bitcoin/namecoin/ directory. Rename it to bitcoin.conf in the namecoin dir. Then run your bitcoin-qt as it's named when it's compiled in the MultiCoin-qt like this: cd /path_to_multicoin-qt_build/;
./bitcoin-qt -datadir=/home/yourhomedir/.bitcoin/namecoin ;
To build see https://github.com/sacarlson/MultiCoin-qt/blob/multicoin-qt/README.rst. In Ubuntu 10.04 just installed and ran the qtcreator and select the *.pro file in the MultiCoin-qt dirctory and hit the build botton.
I'm interested in using MultiCoin for a Stablecoin example currency (I'm calling 1971coin which will be pegged to the 1971 dollar). However, I'm having trouble figuring out where to start. Is there a getting started guide somewhere explaining how to start your own block chain using MultiCoin?
I would be willing to help develop the guide if you could help me out and I can post it on a wiki somewhere.
I would be willing to help develop the guide if you could help me out and I can post it on a wiki somewhere.
Update: as of 6/13/11 we have changed the 4 byte magic number in weeds to fix some problems and help support other things like bitcoin-abe that we now have a working version for weeds presently found in my patched branch of bitcoin-abe found here: https://github.com/sacarlson/bitcoin-abe .
Bravo. I've applied the magic number upstream. In fact, I'd already given Abe Weeds support in a more scalable way but hadn't documented it until a minute ago.
Code:
# datadir can supply information about new currencies.
# Note that "address_version" is a byte string: the byte (or, perhaps
# someday, several bytes) preceding the public key hash before base-58
# conversion. Example:
#
#datadir += [{
# "dirname": "/home/weeds/testnet",
# "chain": "Weeds",
# "code3": "WDS",
# "address_version": "o" }]
# Note that "address_version" is a byte string: the byte (or, perhaps
# someday, several bytes) preceding the public key hash before base-58
# conversion. Example:
#
#datadir += [{
# "dirname": "/home/weeds/testnet",
# "chain": "Weeds",
# "code3": "WDS",
# "address_version": "o" }]
If you'd like to establish a canonical Weeds/MultiCoin datadir, I'll include code similar to util.determine_db_dir and load the data by default:
Code:
# This function comes from bitcointools, bct-LICENSE.txt.
def determine_db_dir():
import os
import os.path
import platform
if platform.system() == "Darwin":
return os.path.expanduser("~/Library/Application Support/Bitcoin/")
elif platform.system() == "Windows":
return os.path.join(os.environ['APPDATA'], "Bitcoin")
return os.path.expanduser("~/.bitcoin")
def determine_db_dir():
import os
import os.path
import platform
if platform.system() == "Darwin":
return os.path.expanduser("~/Library/Application Support/Bitcoin/")
elif platform.system() == "Windows":
return os.path.join(os.environ['APPDATA'], "Bitcoin")
return os.path.expanduser("~/.bitcoin")
This is really great, exactly what crypto-currency needs.
Definitely keeping an eye on this
Definitely keeping an eye on this
Hi, if you are considering alternate cryptocurrencies, you might be interested in my ideas here:
http://forum.bitcoin.org/index.php?topic=19130.0
http://forum.bitcoin.org/index.php?topic=19130.0
Update: as of 6/13/11 we have changed the 4 byte magic number in weeds to fix some problems and help support other things like bitcoin-abe that we now have a working version for weeds presently found in my patched branch of John Tobey's bitcoin-abe found here: https://github.com/sacarlson/bitcoin-abe . to upgrade to the new magic number simply update your bitcoin.conf.weeds file from MultiCoin or MultiCoin-qt github software distribution or the updated link found here: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.weeds. I have also found that I have to start MultiCoin from a clean empty wallet -datadir or you will still have problems supporting bitcoin-abe. If you don't use a local running bitcoin-abe then you don't need to mess with any changes of the -datadir wallets to make corrections, just replace the bitcoin.conf.weeds file you now have and restart multicoin. So if you now fail to connect to the Weedsnet and see PROCESSMESSAGE MESSAGESTART NOT FOUND on the console you will know you have not upgraded your bitcoin.conf.weeds or you are running a version of MultiCoin older than 6/7/11. example the way I set mine up is: cp bitcoin.conf.weeds /home/sacarlson/.bitcoin/weeds/bitcoin.conf ; bitcoind -datadir=/home/sacarlson/.bitcoin/weeds/ ; the bitcoin.conf.weeds you us should be the new updated version that you could have got with wget http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.weeds or from the github sources . The one at my exchange site is the most experimental version that is modified first, When I see that works I also transfer the changes to github. Oh another thing I forgot to say was that the feature for changing the 4 byte magic number is also a somewhat new feature and you will also need to upgrade to a version of multicoin no older than release date of 6/7/11 of commitish 62c428988ec76bc97fe934c76ad8d77b7060229b or later from: https://github.com/sacarlson/MultiCoin. As far as I can tell multicoin-qt has always had the changable 4 byte magic number feature from day 1 as it was released after 6/7/11 with the merged features from Multicoin.
Anything Else?
Can we end up where every human being (or commercial entity) will have their own currency block chain part of the main block chain? The value of every individual currency will have flexible exchange rate to the basket of currencies (the bitcoin). Alternate Chain Licensed Mining addition ideas
I would like to get into more detail of how I would like to implement an alternate block chain method using licensed miners. And start to answer some of the questions that might be asked. What is licensed Mining?
Licensed mining as I envision it would be an alternate chain method with some small modifications to the present bitcoin chain rule method. The Lic. Miner method would only allow certain miners that hold certain private keys to be able to mine as an option in some of the newly created alternate block chains of new currencies or other type data chains. And allow networks to change the rules later if and or when they get big enough to no longer need lic. Mining.
Why would we ever need Licensed Mining?
First of all you should ask why not just make a small network clone of how bitcoin does it? Well with a small network I have seen with my own eyes for example in testnet that my transactions I did yesterday magically disappeared. This is what can happen in a very small underpowered network like testnet and others. Not that I really cared in this case as I was only testing something. But in the real world if you wanted to start a small network and start using it for something of real value you would run into problems.
I feel small side block chains could be very useful for many different things including trust share trade transactions, gaming score keeping and many others like something similar to namecoin for open secure methods of data keeping and transaction. It is also useful to open up new methods of transactions sooner like P2P escrow and to provide a platform for developers to work from in a smaller scale and still be provided security even in a very small underpowered network. And yet keep any government or other entity from having the ability to disable it by shutting down a site or stealing a computer server system.
What are the advantages?
The biggest advantage that I see is that you don't need a large powerful power hungry network to develop and test new smaller network secure methods of trade and transaction. To accomplish some of the future goals of crypto chain transaction of speed of transaction combined with improved security between transactors with added contract embedding into the chain transactions without having to wait for these edge ideas to be accepted into the main stream bitcoin network. To open up testing of these new methods and to prove there usefulness or possibilities for failure. Also as I presently see it this method of distributed secured data storage would not require as much power to secure. In this model at the very small end you only need 2 or 3 redundant miners that only require to run at about 1 hash/minit. Wow I't a GREEN idea? In this model we don't need to burn tera flops of power to be relatively secure. for example if some government agency tried to shut a server miner down or someone steals one of the servers they wouldn't be stopping anything and getting nothing since it would be a requirement of a miner system to use a luks encrypted partitioned system similar to something like this https://sites.google.com/site/remotekeyencrypt/home to make it difficult to even obtain one of the miner keys if stolen. and the other miners would continue to operate as if a single miner in bitcoin network was shut down, no problem. Even by chance the government or thief after obtaining one of the encrypted miners found a way to crack the luks encypted partition and obtained one of the miner keys out of it, that miner key could be removed from the list of accepted miners and again we would be back to normal.
What are the disadvantages?
Well in this case your talking to the wrong person oh the disadvantage is we don't have it yet.
ok I was asked how would you provide for distribution with such a method of currency? you can't have only some miners get all the money they mine. How could you store value in such a thing? well I'm not sure about this part as each group would be doing different things in different ways but for example http://forum.bitcoin.org/index.php?topic=9493.0 was one of many possible alternative methods of distrubution. I'm sure there will be others that come up with better ones. (06:58:36 AM) gmaxwell: sacarlson: What is the disadvantage? Come on. The disadvantage is that it's distributed but not decentralized. If you're worried about secondary chains getting easily reversed, why not bind them to bitcoin via the alternative chains stuff? (07:00:11 AM) gmaxwell: Well, it's not for no reason. I mean— there are problems with small bitcoins.. basically the bitcoin security model only works if there is only one hashchain, or just a few nearly equally sized ones. (07:00:26 AM) gmaxwell: But binding to the bitcoin chain solves that neatly. I've also been told that this idea isn't even close to what bitcoin is and is totally unrelated and that this could be done with other methods other than bitcoin or bitcoin like methods.
How does it work?
I gave you the basics above in what is Lic mining. The how it works part is a bit more complex but I'll try to keep this in as simple a form as possible here. First we can setup a miner with very low difficulty (07:25:58 AM) lfm: hradly, put a sleep in the mining loop and reduce the difficulty to 0.00000001. When a miner creates a block in about the same manner as in bitcoin he adds something extra into the data of the block that includes a published nonce (an almost never to repeat incrementing number) or just the hash of the block data would be good enough and he signs that nonce/hash with his private key and also publishes this signed nonce and his public key number into the data. Much the same way that we do proof of identity in bitcoin-otc with signed random number we can prove that this is one of the accepted miners for blocks. So now on the client side when we do a scan for proof of work we add a stage that also looks at the nonce/hash data and it's signed data and published public key, and verify that to see if it has been signed by one of the miners by checking it against the list of public keys for each accepted miner that the client keeps in his config. The list of accepted miners public keys could be one or many and they could be turned on or off at any time by changing the contents of the list in the configs of the clients software. These configs could be distributed in many different methods to be decided by in the group that plan to use it. Probably by publishing the configs at some https site would be one possible method or in the distribution method of the clients software would be another. But it will also require that with a syncing rule that all clients change the list of accepted miners at the same block count time so at some interval of a block counts would require update change over on the client side would have to be performed and be setup to change before the transition of the update mark block count. This however could be overruled in the event of a rouge minner that needed to be shut down. In that event a forced upgrade of the config at some random time might be required but hopefully never or very rarely.
Anything Else?
At this point this is only a rough draft of an idea. I await others to provide input and corrections to this and I will continue to keep editing this post as newer better ideas come to me by others. I hope to see even totally different methods to accomplish the same thing in a different way. If it's too different I won't add it to this post but create another. I am hoping to see example software patches to MultiCoin or MultiCoin-qt or any of the other branches from Bitcoin or Bitcoin-qt for ways of doing something like this. I will publish links to anything I find like github code that appear to be moving in a similar direction. I don't have any money to offer you in exchange but only an added ora of love from the universal conciseness. Thank you for your interest.
Created another branch of MultiCoin called MultiCoin-qt that is a branch of bitcoin-qt using the qt gui libs
this is now completed with preliminary tests complete and published at:
https://github.com/sacarlson/MultiCoin-qt in this gui version you can make cosmetic changes to the gui
from the config file including changing windows title and graphic icon. this version has most of the features of Multicoin except escrow at this time.
this is now completed with preliminary tests complete and published at:
https://github.com/sacarlson/MultiCoin-qt in this gui version you can make cosmetic changes to the gui
from the config file including changing windows title and graphic icon. this version has most of the features of Multicoin except escrow at this time.
Your C++ looks all right to me. 
I'm imagining a world where there are 10,000+ chains of which I'm interested in 100+. Or maybe I'd like to run an exchange or a service similar to Block Explorer that by default supports any new chain on the net. I imagine one p2p network, one port number shared by many or all chains. Peers would exchange lists of chains that interest them so they can avoid useless relaying. The protocol would support a "new chain" message type. Of course, chains would need a unique identifier, perhaps a hash of some implementation of its block acceptance rules.
I'd also like a way to start hashing a chain that does not yet have a genesis block, only rules to validate the genesis block. The rules might require, for example, the coinbase script to contain the hash of a particular (perhaps future) Bitcoin block as timestamp. This would give people a fair chance at the genesis reward (if any) and permit a high difficulty for the block, especially in conjunction with shared proof of work.
I'm imagining a world where there are 10,000+ chains of which I'm interested in 100+. Or maybe I'd like to run an exchange or a service similar to Block Explorer that by default supports any new chain on the net. I imagine one p2p network, one port number shared by many or all chains. Peers would exchange lists of chains that interest them so they can avoid useless relaying. The protocol would support a "new chain" message type. Of course, chains would need a unique identifier, perhaps a hash of some implementation of its block acceptance rules.
I'd also like a way to start hashing a chain that does not yet have a genesis block, only rules to validate the genesis block. The rules might require, for example, the coinbase script to contain the hash of a particular (perhaps future) Bitcoin block as timestamp. This would give people a fair chance at the genesis reward (if any) and permit a high difficulty for the block, especially in conjunction with shared proof of work.
Jump to: