Bitcoin Forum
December 10, 2016, 08:44:07 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 »  All
  Print  
Author Topic: Handle much larger MH/s rigs : simply increase the nonce size  (Read 9105 times)
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 06, 2012, 11:54:40 AM
 #61

Although I thought it was obvious - I added the quote to my post above for the reason for my post above ...

However, slush, even your post directly implies working around the problem rather than fixing it.

... and it won't be long before each of the software workarounds will not be sufficient and then a workaround will be necessary in the silicon also.


... or ........ just fix the actual problem in the first place (yeah 3 months have already been wasted)

It is clearly a problem and there is a clear fix - a LONG term fix - increase the nonce size to 128 bits.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jevon
Jr. Member
*
Offline Offline

Activity: 36


View Profile
October 06, 2012, 11:57:08 AM
 #62

Any change to the block header is a hard fork upgrade, and should be avoided at all costs.

His point is stealing 2 bytes from version shouldn't be a hard fork or any fork. (unless 0.7.0 panics when it sees a new version number, I haven't read that code yet...  nVersion is a signed int, so you could stipulate the high bit set so it makes a negative version number for <=0.7.0)

The version bytes were put there for extensibility. We need some now. We could use them now, or save them for some future need for bytes.

OTOH, Stratum seems to solve this nicely. The CPU has to do about 10 hashes and send 32 bytes of merkle root for every 4 billion hashes the ASIC does. ASIC is fast but is it anywhere near 400,000,000 times faster than CPU? I think CPU is like ~4 Mhash, so ASIC would have to be 100 petahash to outrun CPU's part of the job.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 06, 2012, 12:06:10 PM
 #63

Repeating and explaining ... since it seems to be necessary ...

If the time to talk to the device is of the same order of magnitude as how long the device takes to process the work, then there is a problem.

I deal with this stuff in e.g. the cgminer Icarus and BFL drivers.
The issue of how much time is wasted talking to the device.
It is already noticeable in the last digit of the miner performance display.
With a 10x performance increase (ASIC) it will be noticeable even more.

What x performance will we get from a device this year ... next year ... after that ... ?

Nothing to do with CPU speed.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
October 06, 2012, 12:17:39 PM
 #64

Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

I think you're missing something here. 0.7.0 was most certainly not forced on anyone. It does implement BIP34 (a fully backward-compatible change), which only takes effect as soon as a majority of mining power participates in it. Therefore it's indeed preferrable for miners and other infrastructure to upgrade to 0.7.0. But the key word in here is backward compatible. Every change that has ever been done, either had no protocol impact (like removing getmemorypool) or only a backward-compatible one (like BIP16 and BIP30).

What you are proposing is a completely incompatible upgrade. Blocks created by a new miner would simply be ignored by every single old node (not just old miners, everyone). The moment such a block gets created, and a majority of mining power is behind the change, there will instantly appear a fork in the block chain. One side maintained by the new nodes, one side by the old nodes. Every existing non-spent transaction output before the split would get to be spent once in each side. This would be a disaster. The only way such a "hard fork" as it is called (essentially a non-backward compatible change to the validity rules for blocks) is possible, is when it is very carefully planned in advance (let's say 1-2 years) and everyone agrees (not just a majority, there must be exceedingly high consensus about this).

I'm sorry, but no, a performance problem for miners is not worth a hard fork. Miners make money, I'm sure they'll find solutions on their own (like Stratum) which don't require the rest of the network to upgrade. If the hardware or the software can't deal with such high performance, switch to other hardware or software. Let the device do ntime rolling or calculate its own merkle root. Yes, I fully agree a 64-bit nonce would have made things easier, but there is simply no way of changing
that right now. I don't mean hard - it's just impossible. Some people would refuse to have a protocol change forced on them, and that's enough to ruin Bitcoin in the face of a hard fork.


aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
October 06, 2012, 12:19:30 PM
 #65

However, slush, even your post directly implies working around the problem rather than fixing it.

Sure. My post was about that I prefer "work around" in miners that breaking compatibility of whole bitcoin network.

Quote
I deal with this stuff in e.g. the cgminer Icarus and BFL drivers.

USB 2.0 has teoretical speed 480 Mbit/s. Block header has ~200 bytes. I know I'm over-simplifying it now, but teoretically it is possible to transfer up to 300000 block headers per second to the miner even with prehistoric USB 2.0.

Maybe we should focus to fixing protocols in these devices than fix protocol in bitcoin network? Why should device for $30k USD use serial port communication designed in the middle of 20th century?

jevon
Jr. Member
*
Offline Offline

Activity: 36


View Profile
October 06, 2012, 12:22:27 PM
 #66

If the time to talk to the device is of the same order of magnitude as how long the device takes to process the work, then there is a problem.

Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. You don't need to send the whole header, only the merkle root changes. That's 12.5 * 32 = 402 bytes per second.

It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash.

Edit:
Also it only needs a enough merkle roots to last for 1 second. After 1 second it can update nTime and cycle through its supply of merkle roots again. If you sent it the block header and 13 merkle roots, it would have all it needs.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 06, 2012, 12:26:43 PM
 #67

Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

I think you're missing something here. 0.7.0 was most certainly not forced on anyone. It does implement BIP34 (a fully backward-compatible change), which only takes effect as soon as a majority of mining power participates in it. Therefore it's indeed preferrable for miners and other infrastructure to upgrade to 0.7.0. But the key word in here is backward compatible. Every change that has ever been done, either had no protocol impact (like removing getmemorypool) or only a backward-compatible one (like BIP16 and BIP30).

What you are proposing is a completely incompatible upgrade. Blocks created by a new miner would simply be ignored by every single old node (not just old miners, everyone). The moment such a block gets created, and a majority of mining power is behind the change, there will instantly appear a fork in the block chain. One side maintained by the new nodes, one side by the old nodes. Every existing non-spent transaction output before the split would get to be spent once in each side. This would be a disaster. The only way such a "hard fork" as it is called (essentially a non-backward compatible change to the validity rules for blocks) is possible, is when it is very carefully planned in advance (let's say 1-2 years) and everyone agrees (not just a majority, there must be exceedingly high consensus about this).

I'm sorry, but no, a performance problem for miners is not worth a hard fork. Miners make money, I'm sure they'll find solutions on their own (like Stratum) which don't require the rest of the network to upgrade. If the hardware or the software can't deal with such high performance, switch to other hardware or software. Let the device do ntime rolling or calculate its own merkle root. Yes, I fully agree a 64-bit nonce would have made things easier, but there is simply no way of changing
that right now. I don't mean hard - it's just impossible. Some people would refuse to have a protocol change forced on them, and that's enough to ruin Bitcoin in the face of a hard fork.


So you've plotted out the timeline for the death of BTC yet?

Either of these will do:
1) When the number of transactions on the network is beyond what the current design can support
2) When sha2 IS broken (not an IF, a WHEN) and we have to move on to sha3

According to your argument, when either of these happen, BTC will die since a hard fork isn't possible.

Yes I know the soft fork in April was done badly, but just because it was fucked up then, doesn't mean soft or hard forks can't be done.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 06, 2012, 12:29:29 PM
 #68

GBT was necessary even before ASIC, because the real problem isn't the nonce range being too small, it's that pooled mining today tends to centralize control too much. The primary key feature of GBT is decentralization; that it happens to also solve the ASIC problem came as a nice side-effect.

Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
October 06, 2012, 12:30:15 PM
 #69

I'm sure that when the alternative is Bitcoin becoming useless (either by scaling issues or broken cryptography), getting a consensus about the necessity for upgrade won't be a problem (most likely still very hard, but doable).

Good luck getting the Bitcoin community convinced that it's necessary because of a performance problem for miners, who are already making money.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 06, 2012, 12:35:04 PM
 #70

If the time to talk to the device is of the same order of magnitude as how long the device takes to process the work, then there is a problem.

Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. That's 12.5 * 32 = 402 bytes per second.

It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash.

No, I'm talking about the current silicon without implementing a merkle processor + coinbase generator in silicon.
The work arounds.

Go ahead and tell everyone that the millions they are throwing at ASIC at the moment will be worthless soon Smiley

As I have already said, no company would be silly enough to do Stratum or the other thing in silicon since there is the issue of meeting the random requirements of the 'next' hack solution to this problem and thus no idea how long any device using this silicon could be used.
ROI ..........

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 06, 2012, 12:37:47 PM
 #71

GBT was necessary even before ASIC, because the real problem isn't the nonce range being too small, it's that pooled mining today tends to centralize control too much. The primary key feature of GBT is decentralization; that it happens to also solve the ASIC problem came as a nice side-effect.
A perceived problem that even MOST of the network disagrees with you on.

MOST of the network mines on pools - count the % of network using P2Pool or solomining and you will see your argument that GBT solves some control problem holds no water at all.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
jevon
Jr. Member
*
Offline Offline

Activity: 36


View Profile
October 06, 2012, 12:51:51 PM
 #72

If the time to talk to the device is of the same order of magnitude as how long the device takes to process the work, then there is a problem.

Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. That's 12.5 * 32 = 402 bytes per second.

It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash.

No, I'm talking about the current silicon without implementing a merkle processor + coinbase generator in silicon.
So was I.

I'm sorry, maybe I'm missing something. The CPU increments the coinbase extra nonce and recalculates the merkle branch to make new merkle roots to send to the ASIC. Only the merkle roots need to go over the wire.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 06, 2012, 12:52:31 PM
 #73

GBT was necessary even before ASIC, because the real problem isn't the nonce range being too small, it's that pooled mining today tends to centralize control too much. The primary key feature of GBT is decentralization; that it happens to also solve the ASIC problem came as a nice side-effect.
A perceived problem that even MOST of the network disagrees with you on.

MOST of the network mines on pools - count the % of network using P2Pool or solomining and you will see your argument that GBT solves some control problem holds no water at all.
p2pool and solo, while they do require decentralization, are not unique in supporting it, and both come with their own problems.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
October 06, 2012, 01:17:17 PM
 #74

It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash.

+1

As I have already said, no company would be silly enough to do Stratum or the other thing in silicon

Stop spreading FUD. Nobody is talking about implementing Stratum/GBT directly in chip.

How about that huge possible optimizations on wire protocol between computer and device? Why not to optimize this at first time? You told that current wire protocols has problems with handling few block headers per second. If that's true, then you can get many orders of magnitude in performance just by optimizing it, without breaking anything in bitcoin.

Oh, I forgot, it is because you need drama :-P.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
October 06, 2012, 02:33:31 PM
 #75

So if nonce size isn't too small - why are we changing bitcoin at all to support ASIC?

We are not and have not.

Quote
Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

Wtf are you talking about.

Quote
Why have people called sticking more junk in the coinbase an 'extra' nonce? What? They gave it the wrong name?
The current nonce is big enough? It's not necessary?

Extranonce has been part of the design since day one. It was the only way to make your coinbase transactions have unique IDs other than constantly changing to a new public key whenever you update the candidate block. It's fundamental and is required for things independent of the nonce size.

Quote
Coz when you get a block header to hash, you can only hash 2^32 times before needing to change it.
Why does that restriction exist?

A _4 billion to 1_ work factor is pretty reasonable. There are a couple tradeoffs here. Header size is utterly critical for SPV nodes of various kinds, and even adding a single byte to the header increases the size by 1.25%. Having too much workfactor ratio between header only work and block update work encourages miners to build devices which never process transactions: Cheaper to just build a constant root with no transactions and increment the header until you solve a block. On a fresh design I may have given a bit more space to nonce, sure. But there is no need to change it now.

Quote
It's gonna work fine without any changes right?
Oh ... no, that's not correct Tongue

Yes, in fact it will.

Quote
Yes I know the soft fork in April was done badly, but just because it was fucked up then, doesn't mean soft or hard forks can't be done.

Huh? The P2SH deployment went pretty smoothly.  About the only bad thing that came out of it was that we discovered Bitcoin had a bug in handling large reorgs with lots of transactions.  Timed less well— with large miners unable to reorg because of it— this could have been pretty fatal for the network. But since it only really impacted non-mining nodes (plus the tiny minority of non-updated miners) due to fork being invalid P2SH it was harmless. It's very fortunate, because I'm not sure we would have discovered that BDB issue even by now wthout it.

Quote
Where IS the restriction at the moment?

That we're not permitted to throw you into a volcano.

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 06, 2012, 02:41:19 PM
 #76

It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash.

+1
-2, keep reading

Quote
As I have already said, no company would be silly enough to do Stratum or the other thing in silicon

Stop spreading FUD. Nobody is talking about implementing Stratum/GBT directly in chip.

How about that huge possible optimizations on wire protocol between computer and device? Why not to optimize this at first time? You told that current wire protocols has problems with handling few block headers per second. If that's true, then you can get many orders of magnitude in performance just by optimizing it, without breaking anything in bitcoin.

Oh, I forgot, it is because you need drama :-P.
At least make sure you know what you are talking about before hitting reply Tongue

Firstly - show me where I said "few block headers per second" - at least quote correctly ...

If you are dealing with work at a nonce range level, then for each nonce range you are passing work to the device.
If the transfer of the ~60-80bytes of hash data to the device is even within an order of magnitude of the device in processing that data, then you have a problem.

FPGA's that use serial over USB have the beginnings of this issue - as per: BFL, Icarus, ModMiner, Cainsmore.
... and the 2 companies that will be releasing their ASIC first are 2 of those, BFL and ModMiner, with Icarus not far behind.

The work arounds suggested imply implementing merlke root processing and coinbase generation processing in silicon ... as I have already explained ... but since it was a little difficult for you to understand I've repeated it. Maybe you are at the top of the first curve Tongue

Anyway, yet again, a work around to resolve the problem that the nonce size is too small.
However, how generic is that work around if it was implemented in silicon?
Would it 'always' work or would it only work with current implementations and need changing in the not too distant future?
Quote me: "ROI"

All these problems and questions are actually resolved by simply increasing the size of the nonce field.
The cause of the problem, and the correct and simplest solution to the problem.
The only argument against it is a hard-fork - which can be planned as a future change to resolve the problem before it becomes a problem.
Yeah a little forward thinking goes a long way.

All this melodrama about hard-forks being impossible - well when the first one comes along that is required 'now', then clearly that will be the end of BTC since everyone's argument is that it is impossible do a hard-fork ... ... which in this case is to fix the problem at the root cause - that then solves all related issues with one change - and a simple implementation everywhere.

As I'll repeat as I've implied before, this really is a good example of people failing to learn from the past.
In this case, a well know one, MSDOS and the early x86 architecture, where the design was based on an assumption that turned out to be an obvious underestimate not far down the track, and for years hacks were used to work around the problem because it was considered too difficult to fix it properly ... until it was fixed properly by removing the original constraints.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 06, 2012, 03:02:05 PM
 #77

So if nonce size isn't too small - why are we changing bitcoin at all to support ASIC?

We are not and have not.
Oh that's right, GBT related changes didn't happen in bitcoind - I forgot.
Quote
Quote
Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

Wtf are you talking about.
What?
There were that many BIPs added in 0.7.0 that you couldn't work out which one I was referring to?
Oh well.
Quote
Quote
Why have people called sticking more junk in the coinbase an 'extra' nonce? What? They gave it the wrong name?
The current nonce is big enough? It's not necessary?

Extranonce has been part of the design since day one. It is the only way to make your coinbase transactions have unique IDs other than constantly changing to a new public key whenever you update the candidate block. It's fundamental and is required for things independent of the nonce size.
Ah glad you agree, yes the nonce field is too small, the solutions using Stratum and GBT have had to extend it to the coinbase Smiley
So ... where is extra nonce referred to in the original Bitcoin document by Satoshi? Oh it isn't.
I'd guess you like the Roll ntime hack also?
Quote
Quote
Coz when you get a block header to hash, you can only hash 2^32 times before needing to change it.
Why does that restriction exist?

A _4 billion to 1_ work factor is pretty reasonable. There are a couple tradeoffs here. Header size is utterly critical for SPV nodes of various kinds, and even adding a single byte to the header increases the size by 1.25%. Having too much workfactor ratio between header only work and block update work encourages miners to build devices which never process transactions: Cheaper to just build a constant root with no transactions and increment the header until you solve a block. On a fresh design I may have given a bit more space to nonce, sure. But there is no need to change it now.
"you may have" Cheesy
Read previous post Tongue
Quote
Quote
It's gonna work fine without any changes right?
Oh ... no, that's not correct Tongue

Yes, in fact it will
Ah, OK, none of these Stratum or GBT changes were needed. OK.
Since they are hacks anyway, just throw them away then.
Quote
Quote
Where IS the restriction at the moment?

That we're not permitted to throw you in a volcano.

But you are permitted to run back to Luke's lap ... wan wan

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
October 06, 2012, 03:06:48 PM
 #78

Kano, you're confused because you're only in Bitcoin for "free money". Someday, you'll need to realize "free money" is not really a goal for Bitcoin as a whole.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
October 06, 2012, 03:18:28 PM
 #79

Quote from: slush
How about that huge possible optimizations on wire protocol between computer and device? Why not to optimize this at first time? You told that current wire protocols has problems with handling few block headers per second. If that's true, then you can get many orders of magnitude in performance just by optimizing it, without breaking anything in bitcoin.

Quote from: slush
USB 2.0 has teoretical speed 480 Mbit/s. Block header has ~200 bytes. I know I'm over-simplifying it now, but teoretically it is possible to transfer up to 300000 block headers per second to the miner even with prehistoric USB 2.0.

Maybe we should focus to fixing protocols in these devices than fix protocol in bitcoin network? Why should device for $30k USD use serial port communication designed in the middle of 20th century?

Once again, bolded especially for kano. Please respond to this.

Quote
If you are dealing with work at a nonce range level, then for each nonce range you are passing work to the device.

How many iterations is possible for one nonce range? 2^32? So 80 bytes per 2^32 hashes? Is that around 230 low-level "jobs" (nonce ranges) per one terahash per second? Isn't there teoretical wire limit 300000 nonce ranges per second for USB 2.0?

Quote
FPGA's that use serial over USB have the beginnings of this issue - as per: BFL, Icarus, ModMiner, Cainsmore.
... and the 2 companies that will be releasing their ASIC first are 2 of those, BFL and ModMiner, with Icarus not far behind.

Serial over USB is that obsolete technology which I was refering in my previous post. Looks like *there* is a space for improvements, *not* in bitcoin protocol.

Quote
The work arounds suggested imply implementing merlke root processing and coinbase generation processing in silicon ...

Nobody is proposing this.

Quote
Would it 'always' work or would it only work with current implementations and need changing in the not too distant future?

Yes. There're already technologies for feeding Petahashes per second to ASIC device. However device manufacturers will probably need to drop obsolete wire protocols and use something faster than Serial over USB.

Quote
All these problems and questions are actually resolved by simply increasing the size of the nonce field.
The cause of the problem, and the correct and simplesthardest solution to the problem.

Let me fix it for you.

Quote
The only argument against it is a hard-fork

It looks to me that you live in some alternate universe. Hard fork is definitely possible and there can be scenarios when it become necessary, but ASIC miners are not that case.

*headdesk*

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
October 06, 2012, 04:16:00 PM
 #80

Oh that's right, GBT related changes didn't happen in bitcoind - I forgot.
HUH? GBT is a rename of the poorly named getmemorypool which we've had for a long time— much longer than anyone was talking about 1TH/s mining devices— it's used by pool daemons and p2pool. Mostly for dynamic coinbase creation (e.g. to do fancy payouts) and because bitcoind coinbase creation is somewhat slow (it's synchronous, single threaded, and basically completely unoptimized).  The changes made in 0.7 beyond the rename were some extra fields to remove a potential DOS attack where some of the limits couldn't be properly enforced when the caller does dynamic transaction selection, support for the height in the coinbase, and some general cleanups to make it more 'designed' than accreted. BIP 22 makes no mention of 'asic', nor do the pull requests for the changes, and I don't believe asics _ever_ came up in discussion related to it around the reference client's development.

To the extent that GBT is useful for higher speed miners getmemorypool was absolutely as useful.

Quote
So ... where is extra nonce referred to in the original Bitcoin document by Satoshi? Oh it isn't.
The same place scripts are referenced as well as locktime and nbits.

Quote
There were that many BIPs added in 0.7.0 that you couldn't work out which one I was referring to?
It's awfully hard to work out what you're talking about when you haven't the foggiest clue about what you're talking about yourself.
Pages: « 1 2 3 [4] 5 6 »  All
  Print  
 
Jump to:  

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