Oh well I wasn't worrying about the early adopters trying to keep the price *down*, I figured in most new blockchains keeping it *up* would be the challenge. If it goes *too far up*, you can simply start yet another blockchain, which is almost certain to start out nice and low in price.  Also, if there is any truth in ideas that alternate chains would be *competing* to lower each other's value instead of *co-operating* to make them all in general rise in value, then maybe starting a new chain might help bring down the value of your previous chain. If so you wouldn't have to mess with making more of the previous chain to lower its price, just start up a "competitor". I still think these alternates should help bitcoin value not lower it though, at least as long as the people or groups behind them continue to treat original bitcoins as the grand-daddy of them all, the blue chip, the most attractive one to use as "reserves" for "backing" your alternates and so on. -MarkM- |
|
|
|
|
You could try some of your ideas simply by getting in as an early adopter on any new blockchain that is at low difficulty or low price, thus allowing you to becomea major holder of the things. Then in your capacity as a major holder you should be able to stabilise the price, yes?
I figured this is what would hopefully happen with bitcoin: major holders would hopefully obtain so much fiat by selling at peak prices that they could from then on use that fait to keep buying back bitcoin any time its price in terms of fiat starts to drop.
This assumes of course that major holders actually intend to stick around and support bitcoin rather than treat it as a ponzi scheme, cashing out to fiat and not using that fiat to uphold the value of bitcoins.
-MarkM-
|
|
|
|
|
It is not an attempt to peg bitcoin to anything.
It is entirely new coinbases.
However, if you are going to give out more or less coins depending on current prices you are probably chasing a red herring. The number of coins being created soon becomes quite small compared to the number of coins already existing.
So it seems likely that the number of already existing coins people decide to dump or hoard might have far more effect on prices than the number of coins being created by miners.
I do not really see all the alternate blockchain coinbases "competing with" bitcoin at all, I see them as "co-operating with" bitcoin.
It is painful trying to use fiat currencies, exchanges that exchange only between various blockchain-based currencies will I hope be much easier to deal with than trying to exchange with fiat currencies. So I'd like to see a whole bunch of different blockchain-based currencies one can trade between without needing to bother with fiat at all.
-MarkM-
|
|
|
|
|
Currently we have I think about two to four people with clients online listening on port 51333 so that other clients have someone to connect to.
We have people lurking on the #groupcoin channel in Freenode IRC.
We have tested some of the feaures DEVcoin is to have; DEVcoin will be starting from scratch once we have deeloed and tested the code for the desired features.
I have now set the four byte hello sequences for GRouPcoin that wll prevent it fro mtalking to bitcoin, testnet, namecoin etc if it happens to stumble across such a client, best come to the IRC channel for co-ordination in switching to that system all at once to minimise time of not being able to connect.
I have been testing new code privately without affecting the real GRouPcoin blockchain, which should not need any "restart" unless for some reason we are unable to develop DEVcoin (on which development seems to be proceeding okay).
See you at #groupcoin ?
-MarkM-
|
|
|
|
|
A whole series of early-adoption opportunities are flowing.
Get in on the ground floor. Find out what new blockchains are starting up and get in at the startup.
If namecoins are too high in difficulty already for your taste, or have too many earlier-adopters thatn you for your taste, pick something even newer. I think there are still a couple of miner bounties outstanding for the GRouPcoin->DEVcoin project, you could still be able to get yourself a genuine original BiTCoin just by setting up a groupcoind with some nominal amount of hashing turned on - even just a CPU or two.
There are plenty more in the wings, albeit quite a few of them are wanting to "back" their coins in some way and thus are waitign for the "licensed miners" capability the GRouPcoin->DEVcoin project is working on.
Or be the very earliest adopter of your own new blockchain: pick up a copy of Multicoin and roll your own!
-MarkM-
|
|
|
|
|
Ach well here's the beauty o' the reserves system, lad...
...They dinna need t'a store yon beer, on account'a they kin store Scotch Tokens 'n Wine Tokens instead, ye ken?
...An' o'course them Catholics dinna need t'store yon wine, d'ya ken, on account'a they kin store Beer Tokens 'n Scotch Tokens instead, ye ken?
...So lets drink up all this Scotch, aye laddies, an keep reserves o'yon Beer 'n Wine tokens t'back oor Scotch Tokens wi', eh?
-MarkM-
|
|
|
|
|
They claim to be foreigners working in China, that might be to explain their English or if true might explain their English.
I have seen better scam-sites than that though, as well as worse. Who will send money first?
-MarkM-
|
|
|
|
|
It would probably be useful to make an entry-level unit with just one chip on the card, as the lower you keep the cost of entry the more sales you will probably be able to make.
-MarkM-
|
|
|
|
It doesn't seem like a massively serious proposal . I dunno, he's clearly put in some effort. What is definitely serious is the infrastructure to support more experimental currencies. I doubt that BTC is the last word on chain-of-work currencies. Definitely. A lot of people pooh-pooh alternative block chains but there is a lot of potential. -MarkM- |
|
|
|
It doesn't seem like a massively serious proposal . Maybe we'll be better able to judge that when the Italians and Scotts get their blockchains up and running, by checking his exchange rates for beer vs wine vs scotch. -MarkM- |
|
|
|
That seems to be working. -MarkM- |
|
|
|
|
You have to specify where the command is, because Unix, and Linux, defaults to looking in the places listed in its PATH environment setting.
The current directory is . so you can do ./bitcoin or ./bitcoind if they are in the directory you are in.
Or if you don't bother navigating all the way down to /bitcoin/bin/64 you could say /bitcoin/bin/64/bitcoin or /bitcoin/bin/64/bitcoind
bitcoin will want Xwindows, so you will have to've used ssh -X instead of just ssh so that it will know at what IP address, and at which X-windows display of that IP address, to bring up its GUI. (If you are on Windows, it does not typically come with an Xwondows display, that is an extra you have to go find, some of them are commercial, long time since I went looking for such a thing.)
The basic point is that for security reasons . (the current directory) is deliberately omitted from PATH (too many nasty tricks can be played on people who put . into their PATH).
-MarkM-
|
|
|
|
I tried it your way too. Still get memory corruption. Notice it happens 4 times. Maybe you are correct about it being the thread-safe problem. Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
07/14/11 05:15 hashmeter 4 CPUs 1343 khash/s
BitcoinMiner:
proof-of-work found
hash: 000000000d2655bd92fe0c45a1aa5176324ab7a07ae7b1fa60ac324e4a96a02b
target: 0000000014c1a700000000000000000000000000000000000000000000000000
CBlock(hash=000000000d2655bd92fe, ver=1, hashPrevBlock=00000000140c7f022ff7, hashMerkleRoot=bcda71509c, nTime=1310620588, nBits=1c14c1a7, nNonce=411743883, vtx=2)
CTransaction(hash=54eba8ca6e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, -1), coinbase 04a7c1141c0111)
CTxOut(nValue=50.00000000, scriptPubKey=04ef6abceb89cf2c0bb444cb55157d)
CTransaction(hash=b80248d783, ver=1, vin.size=1, vout.size=2, nLockTime=0)
CTxIn(COutPoint(2b12e8a5e1, 0), scriptSig=3046022100fb67b8e49b74b5)
CTxOut(nValue=25.23880000, scriptPubKey=OP_DUP OP_HASH160 e148bc3e1d31)
CTxOut(nValue=0.02000000, scriptPubKey=OP_DUP OP_HASH160 59504bfa9821)
vMerkleTree: 54eba8ca6e b80248d783 bcda71509c
07/14/11 05:16 generated 50.00
keypool keep 1679
WalletUpdateSpent found spent coin 25.2688bc 2b12e8a5e165923c8ad80946f2538f940ae1a95339bb94296ee972e31e96476d
AddToWallet 54eba8ca6e new
AddToWallet b80248d783 new
SetBestChain: new best=000000000d2655bd92fe height=5112 work=92619461300770
ProcessBlock: ACCEPTED
sending: inv (37 bytes)
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c56e010 ***
received: getdata (37 bytes)
received getdata for: block 000000000d2655bd92fe
sending: block (474 bytes)
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c56b010 ***
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c571010 ***
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f5d0c569010 ***
keypool added key 1901, size=101
keypool reserve 1801
^C
I don't know if I can run only one thread on demand other than by running it on a single-CPU machine, both of which are 32 bit Fedora 14 not the 64 bit Fedora 15 I have been running these tests on so far. I will have to move the code to the 32-bit compiling-machine and try. If the thing is not thread safe then maybe we can just do some kind of semaphore around it, that example you linked to seemed to be using some kind of bracketing of the endangered area with some kind of signal to keep the threads from trying to all use it at the same time by the look of it. Using C++ instead of python is probably the least-hackish way to go though of course. -MarkM- |
|
|
|
|
I moved the declarations of the crucial items to the very top of the file, just inside the critical block identifier:
//
// Global state
//
CCriticalSection cs_main;
const int pyResultLength = 8192;
char pyResult[pyResultLength];
and I changed the routine a little to accomodate that:
std::string getPythonResult(const std::string& argumentString)
{
FILE *filePointer;
filePointer = popen((std::string("python ") + argumentString).c_str(), "r");
while (fgets(pyResult, pyResultLength, filePointer) != NULL)
int status = pclose(filePointer);
return std::string(pyResult);
}
This time all four threads ran. But I still got memory errors. I am not confident though that I am not still confusing pointers and arrays. I got compile errors trying to use &pyResult but am not sure just plain old pyResult is actually the same thing as &pyResult. Been a long time since I used C a lot. Gotta think hard on this.
Could be you are right though about it being a thread problem.
-MarkM-
|
|
|
|
|
Threads might turn out to be a problem, but might it simply be that the memory you allocated for the result of your getPythonResult routine gets de-allocated when that routine ends, thus leaving the char* pointers referring to it pointing at de-allocated memory?
In other words did you see my edit above:
EDIT: the string you are returning from your getPythonResult routine is allocated inside that routine, thus is a local variable of that routine. It would need to be copied into some larger-scope allocated memory to survive beyond the invocation of the routine. That might be the memory problem. Do std::string objects auto-allocate space for themselves or do you have to do that explicitly like in C ?
EDIT AGAIN: I don't understand C++ scope, I tried moving the returned string's allocation to just above the function so it would exist outside the function, but then inside the function claimed it was not in scope! So I guess I have no idea how to use variables that exist outside a function from inside the function. Weird as surely lots of functions are using variables declared outside them, I just haven't figured out how they decide which ones they can use and which ones they will decide are "out of scope"...
-MarkM-
|
|
|
|
Yes, that gives memory errors: ThreadBitcoinMiner exiting, 3 threads remaining
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
Running BitcoinMiner with 2 transactions in block
received: verack (0 bytes)
received: getaddr (0 bytes)
received: getblocks (805 bytes)
getblocks -1 to 00000000000000000000 limit 500
sending: addr (6451 bytes)
No valid UPnP IGDs found
07/14/11 04:04 hashmeter 3 CPUs 1373 khash/s
keypool reserve 1687
BitcoinMiner:
proof-of-work found
hash: 0000000010f5a34386a950f513f882e267a7b209a06d12b3c9a5c62b12230956
target: 0000000014c1a700000000000000000000000000000000000000000000000000
CBlock(hash=0000000010f5a34386a9, ver=1, hashPrevBlock=00000000124e9fdb6c96, hashMerkleRoot=3e5d46afd4, nTime=1310616451, nBits=1c14c1a7, nNonce=3761439628, vtx=2)
CTransaction(hash=2346014636, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, -1), coinbase 04a7c1141c0135)
CTxOut(nValue=50.00000000, scriptPubKey=049bbea080bd5b23ae401f6d1763ba)
CTransaction(hash=6d3e0083a2, ver=1, vin.size=1, vout.size=2, nLockTime=0)
CTxIn(COutPoint(394bf27d17, 0), scriptSig=304502200e7ebd73e2375a9d)
CTxOut(nValue=25.26880000, scriptPubKey=OP_DUP OP_HASH160 ce4a95fb61d2)
CTxOut(nValue=0.02000000, scriptPubKey=OP_DUP OP_HASH160 d4d5b4cae13b)
vMerkleTree: 2346014636 6d3e0083a2 3e5d46afd4
07/14/11 04:07 generated 50.00
keypool keep 1687
WalletUpdateSpent found spent coin 25.2888bc 394bf27d17ed6799ef16f5f853ad79e3673997b4ae53a13812dc1d07402acdf8
AddToWallet 2346014636 new
AddToWallet 6d3e0083a2 new
SetBestChain: new best=0000000010f5a34386a9 height=5111 work=92566489266000
ProcessBlock: ACCEPTED
sending: inv (37 bytes)
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f701409a010 ***
received: getdata (37 bytes)
received getdata for: block 0000000010f5a34386a9
sending: block (473 bytes)
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f7014097010 ***
*** glibc detected *** /home/bitcoin/bitcoin/groupcoind-PRIVNET: malloc(): memory corruption: 0x00007f701409c010 ***
keypool reserve 1799
07/14/11 04:07:40 Flushing wallet.dat
^C
Notice also that for some reason one of my four CPU's threads was stopped right at the start. (Maybe though that could be caused by the miner connecting, maybe it drops one of its CPU mining threads in favour of feeding getwork to the miner? Hmm not sure.) On the bright side though, the other machine did receive the 0.02 EDIT: the string you are returning from your getPythonResult routine is allocated inside that routine, thus is a local variable of that routine. It would need to be copied into some larger-scope allocated memory to survive beyond the invocation of the routine. That might be the memory problem. Do std::string objects auto-allocate space for themselves or do you have to do that explicitly like in C ? -MarkM- |
|
|
|
EDIT: oops, I had generator_0.csv instead of receiver_0.csv ! Trying again... Still got errors, plus it made few more receiver-#.csv files with bitcoin addresses instead of groupcoin addresses in them Traceback (most recent call last):
File "receiver.py", line 76, in <module>
main()
File "receiver.py", line 73, in main
writeOutput(sys.argv)
File "receiver.py", line 67, in writeOutput
text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
File "receiver.py", line 44, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
File "receiver.py", line 76, in <module>
main()
File "receiver.py", line 73, in main
writeOutput(sys.argv)
File "receiver.py", line 67, in writeOutput
text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
File "receiver.py", line 44, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
File "receiver.py", line 76, in <module>
main()
File "receiver.py", line 73, in main
writeOutput(sys.argv)
File "receiver.py", line 67, in writeOutput
text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
File "receiver.py", line 44, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
File "receiver.py", line 76, in <module>
main()
File "receiver.py", line 73, in main
writeOutput(sys.argv)
File "receiver.py", line 67, in writeOutput
text = getOutput(directoryName, fileName, int(heightString), float(shareString), int(stepString))
File "receiver.py", line 44, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
-MarkM- |
|
|
|
It pastes the number onto the end of the filename: python: can't open file 'receive.py5108': [Errno 2] No such file or directory python: can't open file 'receive.py5108': [Errno 2] No such file or directory python: can't open file 'receive.py5108': [Errno 2] No such file or directory So I tried adding a space after the filename, also corrected name to receiver.py Still got errors. The top of receiver.py claims it wants lots of arguments, so I ended up with this: CBlock* CreateNewBlock(CReserveKey& reservekey)
{
CBlockIndex* pindexPrev = pindexBest;
// Create new block
auto_ptr<CBlock> pblock(new CBlock());
if (!pblock.get())
return NULL;
// Create coinbase tx
CTransaction txNew;
txNew.vin.resize(1);
txNew.vin[0].prevout.SetNull();
txNew.vout.resize(1);
txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;
// Add our coinbase tx as first transaction
pblock->vtx.push_back(txNew);
// Prepare to pay a beneficiary
int64 payAmount = 2000000;
// std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
std::ostringstream heightStream;
heightStream << pindexPrev->nHeight+1;
std::string heightString = heightStream.str();
std::string payTo = getPythonResult(std::string("receiver.py -directory ./ -input receiver.csv -step 2000 -subsidy 50 -value ") + heightString);
uint160 hash160 = 0;
if(!AddressToHash160(payTo, hash160))
{
return NULL;
}
CWalletTx wtx;
CRITICAL_BLOCK(cs_main)
{
// Send to bitcoin address
CScript scriptPubKey;
scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;
int64 nFeeRequired;
if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
{
// OK
}
else
{
return NULL;
}
}
// Add created but not committed beneficiary transaction
pblock->vtx.push_back(wtx);
// Collect memory pool transactions into the block
But that too gives errors: File "receiver.py", line 67, in <module>
main()
File "receiver.py", line 64, in main
writeOutput(sys.argv)
File "receiver.py", line 58, in writeOutput
text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
File "receiver.py", line 40, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
File "receiver.py", line 67, in <module>
main()
File "receiver.py", line 64, in main
writeOutput(sys.argv)
File "receiver.py", line 58, in writeOutput
text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
File "receiver.py", line 40, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
File "receiver.py", line 67, in <module>
main()
File "receiver.py", line 64, in main
writeOutput(sys.argv)
File "receiver.py", line 58, in writeOutput
text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
File "receiver.py", line 40, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
File "receiver.py", line 67, in <module>
main()
File "receiver.py", line 64, in main
writeOutput(sys.argv)
File "receiver.py", line 58, in writeOutput
text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
File "receiver.py", line 40, in getOutput
modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
What are the various arguments about, and which one should the block number be plugged into? -MarkM- |
|
|
|
I tried python receiver.py -directory test -input receiver.csv -step 2000 -subsidy 50 -value 1995 It wanted a file test/receiver/randomnumber.txt so I echoed a few digits number to make such a file. Now each time I repeat the command I get the exact same address, the top one on the list. What are the step and the value about? Maybe the value is meant to be the block number or something so I get same address because I am in effect asking about the same block each time? The addresses are bitcoin addresses not groupcoin address by the way... we should either convert them (  ) or find out these people's groupcoin addresses... -MarkM- |
|
|
|
|
Apparently that is part of the plan for an Italian cryptocurrency, they are mostly waiting to see how the Brits and Canucks do with their cryptocurrencies first though if even the Czechs can do it, they figure, surely Italians can too.
-MarkM-
|
|
|
|
|
Show Posts
