 Show Posts
|
|
Pages: « 1 [2] 3 4 5 »
|
|
There was a proposal on the dev mailing list (from Mark Friedenbach) that I quite like which doesn't seem to have been mentioned here.
Set XBT = 100 Satoshis = 1 uBTC = 0.000001 BTC
This should scale nicely for a little while at least.
This also intrinsically supports a standard unit of 1 uBTC.
Currently:
$700 ~ 1 BTC
$0.7 ~ 1 mBTC
$0.0007 ~ uBTC
$7 for a beer (here in Aus) should be like 10 mBTC or 10,000 uBTC / XBT, so XBT is a little cumbersome at the moment, but that might not last long.
|
|
|
|
BDB0055 illegal flag specified to DB_ENV->open
config still fails at this, have to manually edit it I was seeing illegal flag combination specified to DB_ENV->open in db.log too as well as using the latest version from github with libdb5.1. Removing wallet.dat didn't help. Changing to libdb4.8 fixed the issue. You can find them in the PPA if you're using ubuntu. |
|
|
|
This seems like a not-so-well thought out idea. How does one claim ownership of Nxt funds once the genesis block is mined? They just put in the password? Since there's no signature confirming the initial TX, I suspect anyone else can also attempt to redeem the coins (in the same way redeeming an output like "OP_SHA256 <hash> OP_EQUAL" can be stolen by a miner, as there is no way to validate intended outputs). What happens to the BTC sent to your address? You keep them? Why not take all the public keys from transactions to your 'exodus'-esq address and assign them values at launch? All a user needs to do is import her privkey for the address they sent funds from and you have a more decentralised setup phase which doesn't require using a hash in a private database stored as a 'public message'. On an economic tangent, you say there's no need to send large amounts to your address, but if the amount of Nxt you receive is proportional to the amount of BTC you send, you end up with the same wealth distribution we have in Bitcoin now (or similar enough - those who can pay more will, and thus control a similar-ish chunk of the Nxt pie). Economics is not my area of expertise. I can say nothing about the issue.
Then why are you trying to design a currency? |
|
|
|
Yes Windows and Linux builds will be available at release time, with Qt support, just like ppcoin v0.3.
please can you do a fair launch ( encrypt the whole file with 256 by encryption with a good password and give people a couple of days to download it before the coin is released when its time to release the coin just post up the password to the file  This isn't necessary, see my above post (now expanded). Apologies if it's a little ramble-y. Ideally you want everyone running the software, ready to go, then the genesis block (or the 'start' catalyst) is released, and away people go. Passwords and encryption seem like a long way to go when you could just run the client and have it work automagically. |
|
|
|
Why not follow a release schedule like coblee did with Litecoin, where the client was released ahead of time to let people install & test it, and the release itself consisted of simply releasing a config value?
I'm not sure if that system would work nowadays. Some twat would make their own genesis block and start the chain prematurely. The genuine chain would then start causing all sorts of confusion. There would still be an official chain. People will want to use the real one, and it's easy to recognize which is real and which is fake. This is true. I am only guessing. The genesis block hash is hardcoded into the client. You can't just make your own genesis block and have people accept it. They'd need to recompile. The idea of releasing the client then the IP of a node with the valid genesis block should work just as well; that way everyone has the hash already and you just release the block, as such. Once one person has it in the entire altcoin network it will flood through and people will start mining. One idea to help launch might be to have a network rule that block 1 has to have an output from the only tx in block 0 (the genesis block). Bitcoin can't do this because the coinbase tx of the genesis block can't be spent because of something weird in the way bitcoin-qt/d stores and processes transactions (I think..), but it's theoretically possible. This way, you ensure that the creator can start the mining process with a transaction, and not the genesis block. This means the genesis block can be produced early and allow everyone to get a good binary with the genesis block hash, and still provide a controlled launch. Again, this issue only exists because the genesis block hash pretty much *must* be hardcoded. That is, after all, ultimately what identifies chains, as no two genesis blocks can be the same for completely unique chains. |
|
|
|
Great thanks to you, I want to buy the bad blocks from you and I really appreciate your great help.
I didn't mine any 'bad' blocks; there was only one which was on the end of the chain. You're welcome , it wasn't a huge deal though, and I didn't actually figure out the problem, just work around it. If you'd like to send me some CMC you can here: C72cU8HH6ryHSScDqMymtYYxu5kEWjN9bx Great, can you share how did you patch the chain? How the bad block could be attached to the chain?
I believe he just updated the code as outlined above and started mining using a version based on that code, no?
This is correct. The patch itself was: if (GetHash() == uint256("0x000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205"))
return error("CheckBlock() : hash == 000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205");
Basically it would just fail if you tried to add block 0x000000082f31f... to the main chain, allowing me to mine from the previous block and create an alternate chain which took precedence when it became longer. Then the rest of the network took over and there were like 200 blocks in 2 minutes (the difficulty was low because it recalcs for every block). JDDev and cosmoscoin, not sure if either or both of you are developing this, but your block target and retarget time are low enough that you might get problems. I'm not certain that is what allowed the 7886 block; the PoS aspect might have had quite a bit to do with it. In any case, there's evidently a bug that needs to be worked out. |
|
|
|
time stamp for block 7885 is weird, it is 2 hrs after the block 7886
Hmm. I've got an alternate chain now: 7885: 000000082148a6f66e17bab8d41af11171bc6f4d9416f983ddad0212a41775c0 7886: 000000061f7cee86da6458d5fbf02694db41c58e4d38aaea58606e3faefa3522 7887: 000000942feafab66ec53301532853634ccedecdc8b5fbc4fc5bebba75ba60a1 7888: 00000059bf77cf922474c474cceea4c006a58900625ac13781ede01d3aa77b34 I've mined the last 3.
Edit: fixed with this: Try the following, I can confirm you don't download block 7887 (height 7886). Patch main.cpp so the definition of CBlock::CheckBlock now reads: bool CBlock::CheckBlock(bool fCheckPOW, bool fCheckMerkleRoot) const
{
// These are checks that are independent of context
// that can be verified before saving an orphan block.
// --- patch start
// blacklist
if (GetHash() == uint256("0x000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205"))
return error("CheckBlock() : hash == 000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205");
// --- patch end
// Size limits
if (vtx.empty() || vtx.size() > MAX_BLOCK_SIZE || ::GetSerializeSize(*this, SER_NETWORK, PROTOCOL_VERSION) > MAX_BLOCK_SIZE)
return DoS(100, error("CheckBlock() : size limits failed"));
Only one miner will need to implement this, to blacklist block 0x000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205, then chains should reorganize once a longer chain is produced. No idea if this will help, but it might get you around the issue. From what I can tell you shouldn't have a difficulty adjustment at this point in time. Didn't get to post it before it was fixed.
Update: For posterity here is some info on the bad fork: xertrov@x-work:~/src/cosmoscoin/src$ ./cosmoscoind getblock 000000082148a6f66e17bab8d41af11171bc6f4d9416f983ddad0212a41775c0
{
"hash" : "000000082148a6f66e17bab8d41af11171bc6f4d9416f983ddad0212a41775c0",
"confirmations" : 21,
"size" : 266,
"height" : 7885,
"version" : 4,
"merkleroot" : "2d75ef37fe8228e06a78410e6bfc6ac98bbf8e41ecf72838e754299f26243a67",
"mint" : 3.50000000,
"time" : 1372834490,
"nonce" : 2004907776,
"bits" : "1d0827a9",
"difficulty" : 0.12262345,
"previousblockhash" : "00000004a11a5a3080247c1c1c795d96e7330179d185475eaee48ed698604040",
"nextblockhash" : "000000061f7cee86da6458d5fbf02694db41c58e4d38aaea58606e3faefa3522",
"flags" : "proof-of-work",
"proofhash" : "000000082148a6f66e17bab8d41af11171bc6f4d9416f983ddad0212a41775c0",
"entropybit" : 0,
"modifier" : "bdfd70fa8e720a8b",
"modifierchecksum" : "4e1d99b3",
"tx" : [
"2d75ef37fe8228e06a78410e6bfc6ac98bbf8e41ecf72838e754299f26243a67"
],
"signature" : "3046022100cc37a265784beb958ad0ec0fdce5aadc92c5350bf17b08569d7b1f91536feba80221008cae649f4aa08b1b78756d74dc75d6ee30633e6abaac08a32a5f7841298c22a8"
}
xertrov@x-work:~/src/cosmoscoin/src$ ./cosmoscoind getblock 000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205
{
"hash" : "000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205",
"confirmations" : 0,
"size" : 265,
"height" : 7886,
"version" : 4,
"merkleroot" : "e15d62ba8b4bdf80911c4725c7b1225d4fd981359a2ae431e50918420835ffeb",
"mint" : 0.00000000,
"time" : 1372827494,
"nonce" : 1900102656,
"bits" : "1d107075",
"difficulty" : 0.06082897,
"previousblockhash" : "000000082148a6f66e17bab8d41af11171bc6f4d9416f983ddad0212a41775c0",
"flags" : "proof-of-work stake-modifier",
"proofhash" : "000000082f31f8c70dd7f9a857f04fe14f7df2a57bb9bc1f54d336c70dea6205",
"entropybit" : 0,
"modifier" : "a814232a8e720a8b",
"modifierchecksum" : "f4fab8c5",
"tx" : [
"e15d62ba8b4bdf80911c4725c7b1225d4fd981359a2ae431e50918420835ffeb"
],
"signature" : "304502204629c8a3dadc0db98ed078b34dd8cba2156e42cd65abcd173db86483745fd2f4022100987e51ae95c839254c4f7e9fc4f2164cdb4269c59775b9e28d5be34c652d77b2"
}
Does anyone want to buy 14 Cosmoscoins? |
|
|
|
I mined the block twice, but both were rejected.
That's not the issue. The issue is that the block you're mining has the wrong nBits in the block header. |
|
|
|
|
Looks like your target reduced massively at block 7887, from 00000008359d00... to 000000004c847400...; ie 7 zeros to 8 zeros at the start.
Was a retarget intended for block 7887? And can you post the raw block for 7886; there might be something hiding there.
Edit:
nBits for the block you're trying to mine are nBits=1ccc8474
nBits for the previous blocks were nBits=1d08359d
Sure these are correct? This error message indicates they are not: ERROR: CheckProofOfWork() : nBits below minimum work
1ccc8474 < 1d08359d
Edit again:
Ignore most of the above, didn't realise CMC was based on PPC. There are retargets every block, so changing nBits is expected. The reason these are so drastically different is because of the algorithm used to calculate them and the leniency on block timestamps.
|
|
|
|
When I first heard about coins like curecoins where the proof of work is actually useful, the first thing that came to my mind is that the reason why hashing works is because hashing enforces that the block rewards goes to the person that found the hash. When the miner informs his peers of his block, his peers cannot steal his block. Whereas with a useful proof of work, the peers can just modify the block to make it seem like they found it. "Oh you found a prime that's this difficult and has these properties? Wait, I found the same exact one a minute earlier!" Granted I didn't spend too much time trying to figure out a way around it. Maybe there's a way to encode the the address of the person that found it in the prime. Looking forward to see what Sunny King came up with.
IE: the content of the hash is dependent on the content of the block header which (because of the merkle root) ensures the coinbase pays the miner. It could be that the proof of work algorithm is something like:
Generate a prime number in the form:
k * 256 ^ n + b
where k is the merkle root + nonce, etc.
EG: k = blockheader (presumably prefixed or something to ensure consistent number of digits; as this will have some effect on the difficulty) That would be one way because the prime found would depend on (or rather part of it is) the blockheader. Similar to SHA256 you don't know if there's a solution with the particular blockheader you're using (so you have to search the space - well, if things are done 'right'). I was going to say verifying the prime is difficult; but it's not. Verification of primes can be done in polynomial time, so it's not so bad. Factorizing is the hard bit. So we can have quick to verify, contains the blockheader. The difficulty is easy to integrate; but unfortunately will have a negative effect on verification time (the only way to make prime generation more difficult is to make the primes bigger, so they take longer to verify). Remember that verification is part of the mining process, so there has to be few enough solutions out there to make looking for them harder to ensure consistent verification times; not sure how this will interact with this PoW style. So, issues I can see: overcoming the relationship between the difficulty and verification time (if there is one) and ensuring that there are few enough primes out there to find. The first means the difficulty should shrink the size of the acceptable solution pool (as opposed to making bigger numbers), and the second means arbitrary conditions will need to be chosen by which to define the solution pool. Anyway, curious to see how the PoW works, and as to why there hasn't been any info made open about it yet. |
|
|
|
Was the refund processed by paypal or did you request through their new support ticket system?
Requested via their support ticket system, refunded via PayPal in about 6 minutes. Edit: I did not make the request through PayPal. I presume that's what you were asking about. |
|
|
|
|
Refund complete. That was fast.
|
|
|
|
|
I've requested a refund for order #1122. Order was via PayPal. Will let you all know how it goes.
|
|
|
|
I think the wiki page now clearly explains how to implement it.
We just need someone to pick up the glove...
I'm working on Marketcoin. It's rather similar, but more encompassing. I had some difficulty Googling for a clear explanation of atomic cross-chain trading, so I gathered my findings into this wiki page. I must admit I do not fully understand Mike Hearns' explanation as presented, I suggest we use the wiki page to develop and clarify the solution as needed. The chain-trade alg works in theory, but has two many practical 'misapplications', such as the race condition or mutually assured destruction. As an addendum, Marketcoin requires no change to any current altchain (Bitcoin included) in order to trade with it. As an addendum to the addendum, I started implementing the chaintrade script before Marketcoin fell into place. See https://github.com/XertroV/bitcoin/tree/chaintrade |
|
|
|
The signed/unsigned fork may have been longer. I'm not sure.
I think that the record for typical latency race fork is 2 deep.
Why was 100 blocks chosen for mining delay? There is a protocol rule which prohibits generated BTC from being spent until it has 100 confirmations. The Satoshi client has an additional safety margin: it won't let you spend generated BTC until it has 120 confirmations. The purpose of this rule is to prevent long chain splits from invalidating lots of transactions that spend newly-generated BTC. For example, this rule prevented non-coinbase transactions from being invalidated after the overflow incident invalidated 50+ blocks. http://bitcoin.stackexchange.com/questions/3464/why-do-mining-pools-require-120-confirms-for-a-solved-block-before-payout |
|
|
|
Very quick BOTE calculation with regards to this: Approx 25 chainforks (of depth 1) per 3000 blocks. http://blockchain.info/orphaned-blocksSo approx a 1/120 chance (or less) to have a chainfork when a block is produced. For two chianforks you need at least this chance twice. In reality it's less probable because simply squaring the chance would include a one of two second chainforks that would spring from one block, instead of one from each. Rough estimate of a two length chainfork < (1/120)^2 = 0.0000694... We've had ~240000 blocks, so we'd expect about 16 chainforks of length 2 thus far. If we look at chainforks of length 3, we see the expected amount is less than 0.14, which would line up with reality (excluding March this year)
Bytemaster, if you want I've got a python script I wrote a few days ago to simulate network propagation of blocks. |
|
|
|
Little help please: root@vps:~/0pticoin/src# gcc -o genesis_generator genesis_generator.c
/tmp/cchWzm3E.o: In function `main':
genesis_generator.c:(.text+0x95e): undefined reference to `SHA256'
genesis_generator.c:(.text+0x979): undefined reference to `SHA256'
genesis_generator.c:(.text+0xb73): undefined reference to `SHA256'
genesis_generator.c:(.text+0xb8e): undefined reference to `SHA256'
collect2: ld returned 1 exit status Thanks!!! For future reference, you need to include the libraries in the command: gcc genesis_generator.c -o genesis_generator -lcrypto |
|
|
|
|
Order 1122; 2xK64
Order 1121 was mine and was cancelled (paypal shenanigans)
Paid at time of order. Status: processing
|
|
|
|
I'll be referring to Marketcoin throughout this as many issues are very similar. Scaleability issues that must be addressed:
1) Every block must update the dividends per share of all bond types and this information must be tracked as far back as the oldest 'unspent' output. Dividend calculations are required for every input and must either query every prior block's divided table or there must be a lookup table based upon 'coinage'.
Current plan is for Marketcoin to have demurrage to help liquidity. This isn't too much of an issue because, like Bitcoin, it does not work against the purpose; to move value between currencies. It does, in fact incentivise this. Demurrage can be calculated formulaically; if you made the dividends only come from the mining generation you could get around needing to lookup all transaction fees and calculate what is owed. On the other hand, keeping a list of transaction fees paid in every block wouldn't be that difficult; my understanding is the Bitcoin client keeps some of these types of details in memory already (one entry per block style lists). You could also use some clever 'something' that was able to be used to calculate aggregate fees over a period of time. Not sure accumulators would be of use here, such as are proposed with merged mining. 2) The number of potential trades / exchanges grows with O(N^2) of the number of currency units thus for 8 units, there are 56 possible short/long combos each of which requires 16 bytes / block 'forever'.
Marketcoin avoids this by only supporting currency markets where one currency is Marketcoin. Nice and linear. Anything possible here in that regard? Have BitShares themselves play this role? 3) Even storing just the 'unspent' outputs at under 50 bytes each would result in TB of data in short order assuming transaction volume similar to Bitcoin, but exchanges will probably have several orders of magnitude more trades than bitcoin experiences and therefore unspent outputs must be managed better than Bitcoin.
What's your calculation for this? that's 50 bytes each block per dividend transaction? Even with a few thousand dividends you'd be using 100kb per block; which is a lot, granted. Since 17th July 2010 there have been 5,300,000 trades on mtgoxUSD/BTC. There have been 19 million transactions on the Bitcoin Network, and 242000 blocks. 242,000 * 100kb = 24 GB. Fair enough, I can see your point here, won't even both using the other stuff. Does the finite blockchain size idea help here? I mean you'd still need a bunch of those outputs but if they can somehow be rolled up as time passes it might make them easier to deal with. What about dividends once a day, ever 144th block, or something? Conclusion:
Transaction fees must be based more upon the net gain in unspent outputs rather than the total size of the transaction. We can 'forget' all of the inputs after enough proof of work, but the outputs we will pay for forever.
We want to motivate people to combine dust and this can be done in two ways, reduced trx fees *and* not paying dividends below a certain threshold.
We must recover old transactions and force people to keep all outputs 'current' to limit the amount of 'dividend history' that must be maintained. At the very least, any dividends that go unclaimed for more than 1 or 2 years could be 'forfeited' and thus all outputs must be spent every 2 years or they lose their dividends. Though a more 'pro-active' approach of 'taxing' 2+ year old outputs and paying them out as dividends would serve to keep all outputs current and recover value lost to lost private keys. This 'tax' can be thought of as an 'inactivity fee' that banks charge accounts and as a means of reimbursing the network for holding on to your unspent output for a very long time which has significant costs when you factor in the total number of nodes that must replicate and index that output.
That's really messy; I would think using them like TX fees would be nicer; allow someone to spend more than the outputs they list and dividends are calculated at verify-time. All you need is the last time the address was used and the numbers of the blocks between and a lookup table to the fees; then you can calculate the dividend easily I would think. The chain must support 'cross-chain' trading to allow parallel BitShare chains to develop that enable trading in a wider range of currencies, stocks, and commodities as well as higher volumes than could ever be supported by a single chain. Thus when the transaction fees get too high on one chain, the market can create a new parallel chain that complements the existing chain. Because every chain enables trading any asset type it is easy to synchronize value between the chains with only a subset of nodes performing arbitrage roles.
You could always just let Marketcoin do that for you... it will anyway if BitShares takes off. While BitShares is the only proposal that I know of to have a dividend component, the unspent output scalability issue as well as the O(N^2) trading pairs and higher transaction volumes will mean that any block-chain based approach will need to have an efficient mechanism to 'go-parallel'.
Addressing these scalability issues is a critical component.
Perhaps leverage Marketcoin or a fork of it to 'build in' interoperability between chains; chains which can fork to parallelise (as you'll only need the chains you're interested in) but do things like separating groups of markets later down the line, some on this chain, some on that chain. This can help control the overall size. You might also be able to link in finite blockchains to end up with little parallel blockchain worms crawling through time. But they can talk to each other. Almost like running SPV in the other chains and full in your chain. That would be enough. Merged mining them would be interesting, but with the accumulator thing you're aware of it might be feasible. |
|
|
|
It was brought to my attention that I didn't detail the deterministic trading algorithm:
Given the set of all unspent outputs as UnspentOut
Given a currency pair, say crypto-USD / BitShares.
Given the same pair, find all crypto-USD issuance (short positions) and sort by margin.
Find all bids and asks and sort them.
While the HighBid >= LowAsk
Average the HighBid and LowAsk to calculate the current Price
if the price > margin threshold of lowest margin position
match bid against margin call at Price
push any left-over short position or bid to the stack
else
match the bid and ask at price
push any left-over bid or ask to the stack.
The result of the above loop will be a single transaction of the following form:
1) all referenced bids, asks, and margin calls as inputs
2) the net result of all trades and margin calls as outputs.
* note a bid may be paritial matched against 100 different asks and there
would only be a single input from that bid and a single output of any
change. All of the intermediate steps would not enter the blockchain.
I'm going to try and walk through the alg below, but before that, what happens when a bunch of information is published (by say a rogue miner working in secret) which pushes someone past an acceptable margin position, and data continues to flow in making the situation worse? Is this possible? Ignoring the possibility of a position requiring liquidation, is this how your alg works? Each element is volume@price (chosen pretty much randomly) Bids = [1@100, 3@99, 10@98, 1@97, 1@96] Asks = [3@101, 20@100, 2@99, 3@98, 2@97] | Step No. | Action | | 1 | Highest Bid = 1@100, Lowest Ask = 2@97 | | 1.1 | As 100 >= 97, trade procedes | | 1.2 | Average: 98.5; 1 unit traded at 98.5 | | 2 | Highest Bid = 3@99, Lowest Ask = 1@97 (remainder from prev trade) | | 2.1 | 99 >= 97, check; average is 98, 1 unit traded at 98. | | 3 | Highest Bid = 2@99, Lowest Ask = 3@98 | | 3.1 | 99 >= 98; average 98.5, 2 units traded at 98.5 | | 4 | Highest Bid = 10@98, Lowest Ask = 1@98 | | 4.1 | 98 >= 98; average 98, 1 unit traded at 98 | | 5 | Highest Bid = 1@98, Lowest Ask = 2@99 | | 5.1 | 98 < 99; NO TRADE |
At the end the order-book-thing stands at: Bids = [9@98, 1@97, 1@96] Asks = [3@101, 20@100, 2@99] Total trades: 4, volume: 5 Edit: as an aside, the pattern I've worked through above is what is used in Marketcoin (currently) |
|
|
|
|
