I think this is very important for cryptocurrencies.
Maybe I develop freicoin one day, after all.
I've read a target block to start using it. To what ordinary date does it correspond?
Does it require changes in the bitcoin client?
Topic: Design notes for sharing work between multiple independent chains (Read 15138 times)
July 17, 2011, 03:55:46 PM
I'm happy to see Vince came through on his promise, and that the document I wrote proved helpful.
July 16, 2011, 10:56:16 AM
vinced, the namecoin developer, has added merged mining capability, allowing shared work for the bitcoin and namecoin chains. The design notes are here.
June 20, 2011, 06:04:45 AM
32 bits are supplied by the final miner. 2^32 =~ 4 billion.
Besides, no one but us cares that their hashes start with a bunch of zeros.
Besides, no one but us cares that their hashes start with a bunch of zeros.
June 20, 2011, 03:28:29 AM
Is it feasible for the hash power of the bitcoin network to be hijacked for code cracking?
If the code cracking problem solution was a mapping to the block solution space it could be as simple as inserting a 'magic' transaction into the block that maps the two solutions together.
Probably easier performed by a large pool operator that distributes work and controls the included transactions in the sought after block solution, for example ... or if all diff. 1 solutions are collected then other auxiliary problems that lie in the same mapping space can be solved simultaneously also.
No.
Even if an attacker really did want to find a bunch of double hashes of specific 680 bit blocks, each result he got back would have a 1 in 4 billion chance of being the one he wanted.
Your reply was prompt and quite emphatic so I'll take that you must have done all the math to back that "no" up previously somewhere. Care to share?
Particularly be interested to see how you discounted mappings into other problem spaces so easily.
June 20, 2011, 03:03:06 AM
Is it feasible for the hash power of the bitcoin network to be hijacked for code cracking?
If the code cracking problem solution was a mapping to the block solution space it could be as simple as inserting a 'magic' transaction into the block that maps the two solutions together.
Probably easier performed by a large pool operator that distributes work and controls the included transactions in the sought after block solution, for example ... or if all diff. 1 solutions are collected then other auxiliary problems that lie in the same mapping space can be solved simultaneously also.
No.
Even if an attacker really did want to find a bunch of double hashes of specific 680 bit blocks, each result he got back would have a 1 in 4 billion chance of being the one he wanted.
June 20, 2011, 02:50:54 AM
Is it feasible for the hash power of the bitcoin network to be hijacked for code cracking?
If the code cracking problem solution was a mapping to the block solution space it could be as simple as inserting a 'magic' transaction into the block that maps the two solutions together.
Probably easier performed by a large pool operator that distributes work and controls the included transactions in the sought after block solution, for example ... or if all diff. 1 solutions are collected then other auxiliary problems that lie in the same mapping space can be solved simultaneously also.
June 04, 2011, 05:44:25 AM
So, choosing the block rate of an alternate chain utilising the same hashing network, is tantamount to choosing it's difficulty ratio with the man BTC chain.
And I propose that this maybe "fix" its relative security, desirability and thus price relative to BTC. E.g. The alternate block chain could have a block rate of 1 per minute (faster confirms) but it's network difficulty would be 1/6th that of BTC and thus it would trade at approx. 1:6 ratio with BTC.
No. The price of bitcoin does not depend on difficulty but on demand and supply. Although security increases demand, demand is not directly proportional to security. If otherCoin were just like like bitcoin but with a monetary base of 300 M instead of 21 M (and a block per minute instead of each 10 minutes), they wouldn't trade at a 1:10. If otherCoin had different properties (rules) than bitcoin, the demand would be different too.
June 03, 2011, 07:21:48 PM
Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised
This reasoning is correct, but you're assuming that the block rate in the alternate network is the same as in btc (10 min per block).
That's not necessarily true.
Good point, thanks for that.
So, choosing the block rate of an alternate chain utilising the same hashing network, is tantamount to choosing it's difficulty ratio with the main BTC chain.
And I propose that this maybe "fix" its relative security, desirability and thus price relative to BTC. E.g. The alternate block chain could have a block rate of 1 per minute (faster confirms) but it's network difficulty would be 1/6th that of BTC and thus it would trade at approx. 1:6 ratio with BTC.
June 03, 2011, 07:16:30 PM
(Added to watchlist)
June 03, 2011, 04:16:30 AM
Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised
This reasoning is correct, but you're assuming that the block rate in the alternate network is the same as in btc (10 min per block).
That's not necessarily true.
June 03, 2011, 02:51:33 AM
Ok, yeah, that clicked. I think you're right. The goal is to maximally secure the most block chains with the least effort.
June 03, 2011, 01:26:15 AM
a) Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?
b) Is that the desired outcome?
b) Is that the desired outcome?
I don't think so.
"You don't think so" to part a) or part b)?
Neither part a nor b.
I think the desired outcome is that with just a single hash computation, a miner could potentially generate a valid block on any chain connected in this way.
Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised
June 03, 2011, 01:13:03 AM
a) Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?
b) Is that the desired outcome?
b) Is that the desired outcome?
I don't think so.
"You don't think so" to part a) or part b)?
Neither part a nor b.
I think the desired outcome is that with just a single hash computation, a miner could potentially generate a valid block on any chain connected in this way.
June 03, 2011, 01:08:56 AM
a) Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?
b) Is that the desired outcome?
b) Is that the desired outcome?
I don't think so.
"You don't think so" to part a) or part b)?
June 03, 2011, 01:02:05 AM
Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?
Is that the desired outcome?
Is that the desired outcome?
I don't think so.
Quote
perhaps BitCoin can just do what Slushs pool already does and vend work of min(bitcoin difficulty, extra difficulty) then ignore found blocks that don't match BitCoins own difficulty
The only thing that I know I don't understand is how you are able to compute only one hash but have the solution be valid for either block chain.
June 02, 2011, 11:46:14 PM
Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?
Is that the desired outcome?
Is that the desired outcome?
June 02, 2011, 10:58:36 PM
The problems you outline presuppose that the miner is trying to include as many transactions as possible.
No. In my posts in this topic, I have always assumed that the miner will never include the transaction in his own blocks. I am only concerned here with what the miner will do with other blocks with transactions he can't verify.
June 02, 2011, 09:14:24 AM
More than 50% of the miners need to agree before actually forgetting transactions, though. Otherwise you'll get the problems that I've described.
The problems you outline presuppose that the miner is trying to include as many transactions as possible. The miner can just shun transactions that use inputs it has forgotten. Unless these transactions contain substantial fees then the miner is not losing out significantly. The underlying problem is that the incentives for miners to include transactions are currently weak.
Taking the "miners forgetting transactions" to its logical conclusion, you could probably run a miner in the current bitcoin environment that neither verifies signature nor stores the block chain. It would assume that all incoming transactions are correct as they have probably been verified by someone else. To prevent an obvious poisoning attack, it could maintain more than one separate anonymous connection to the network and only accept transactions that appear on both.
ByteCoin
June 02, 2011, 08:31:58 AM
Then I don't understand why people said in the demurrage fee thread that miners will forget transactions.
If storage ends up being really expensive (which I doubt), miners might use demurrage. I think it's a good solution for that (unlikely) case, in fact.
More than 50% of the miners need to agree before actually forgetting transactions, though. Otherwise you'll get the problems that I've described.
Jump to: