I wonder who may have an incentive to code up an alternative implementation? Maybe somebody who already has millions of dollars tied up in capital equipment - someone whose continued profitability requires making any optimization allowed by the protocol...
I'd be happy to write a new client with emphasis purely on performance and scalability from scratch... if someone wanted to throw large sums of money at me to do so and keep sending me more indefinitely to maintain and update it. |
|
|
|
By the way, as far as I can understand the bitcoind code as I read it (and no doubt I will be corrected if I'm wrong which is fine), this is an attack vector that "choosing between them" is the least of your problems because it cannot process them both concurrently and then decide that (2) has finished long before it has finished processing (1). This means that if a (1) block hits even 1us before the (2), bitcoind will sit there processing it until it has finished before it can process (2). While this is purely a limitation of the software as it currently stands that it cannot process multiple blocks concurrently in a multithreaded fashion due to the coarse grained locking in the software, it doesn't change the fact there is no way to deal with this at present. It would require a drastic rewrite of the existing code to make the locking fine grained enough to do this, or a new piece of software written from the ground up; both of which carry their own risks.
Couldn't this issue be worked around by pre-filtering the traffic coming into the bitcoin daemon? "Bad" transaction detection would need to be at the protocol level. The simplest fix would be rejecting transactions over a certain size. Of course that's imperfect, but the filtering could become more fine-grained and accurate over time. It might even be possible to do this with firewall rules? This is a block and the transactions it contains we're talking about, not a simply broadcast transaction, and we don't want to start filtering possibly valid blocks... No filtering required. When a potentially solved block arrives, spawn a thread to start validating it. When another potentially solved block arrives, spawn another thread to start validating it. First one to validate is the one you build your candidate for the next round atop. You missed the point of my original response entirely then - you CAN'T spawn a thread to validate it because of the locking I said before. If you spawn a thread to validate the block, nothing else can do anything in the meantime anyway - you can't process transactions, you can't validate other blocks. This is, again, a limitation of the code rather than a protocol problem but it would take a massive rewrite to get around this. |
|
|
|
By the way, as far as I can understand the bitcoind code as I read it (and no doubt I will be corrected if I'm wrong which is fine), this is an attack vector that "choosing between them" is the least of your problems because it cannot process them both concurrently and then decide that (2) has finished long before it has finished processing (1). This means that if a (1) block hits even 1us before the (2), bitcoind will sit there processing it until it has finished before it can process (2). While this is purely a limitation of the software as it currently stands that it cannot process multiple blocks concurrently in a multithreaded fashion due to the coarse grained locking in the software, it doesn't change the fact there is no way to deal with this at present. It would require a drastic rewrite of the existing code to make the locking fine grained enough to do this, or a new piece of software written from the ground up; both of which carry their own risks.
Couldn't this issue be worked around by pre-filtering the traffic coming into the bitcoin daemon? "Bad" transaction detection would need to be at the protocol level. The simplest fix would be rejecting transactions over a certain size. Of course that's imperfect, but the filtering could become more fine-grained and accurate over time. It might even be possible to do this with firewall rules? This is a block and the transactions it contains we're talking about, not a simply broadcast transaction, and we don't want to start filtering possibly valid blocks... |
|
|
|
|
Nice to see the preciousblock feature. I assume you submit your block and then send the preciousblock message?
|
|
|
|
I guess the bitcoind devs have never worked with multithreading then*? Such a pity. And such a cutting-edge 1990's technology. If inordinately large signature transactions ever become A Thing, miners employing bitcoind will be bankrupted by smarter miners.
C'est la guerre. To the wiser go the spoils.
*Yes, unnecessarily provocative. But it certainly points out just one more instance where devs are working on the wrong things.
It is a bit too harsh. While I'm continually frustrated by some of the limitations of the bitcoind client and the lack of emphasis on things that I am concerned about (since mining with it is my personal interest), it does not pay credence to how such code realistically evolves and the difficulties of keeping massive rewrites safely in check while evolving the client in multiple directions. I'm not much of a c++ coder myself so I can't do anything much to help but at least I do understand what's involved in maintaining such a massive project. It is impossible to know what issues will become problematic in the future when first starting a project; they only become apparent as it evolves and need to be tackled in a methodical manner. Emphasis has only been placed on speed of block processing, propagation, and work template generation in recent times and the improvement is already substantial but has a very long way to go. If the client was written from the ground up now with emphasis in those areas, knowing what we already do now know, it would no doubt look very different. Some things, though, are protocol limitations and not the client. Things like the quadratic scaling issue are in the current bitcoin protocol design and no amount of client rewrites without a protocol change will get around that. I'm not arguing for one only. Both need to be addressed. |
|
|
|
Riddle me this: built off a parent of the same block height, a miner is presented -- at roughly the same time:
1) an aberrant block that takes an inordinate amount of time (e.g., 10 minutes) to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and
By the way, as far as I can understand the bitcoind code as I read it (and no doubt I will be corrected if I'm wrong which is fine), this is an attack vector that "choosing between them" is the least of your problems because it cannot process them both concurrently and then decide that (2) has finished long before it has finished processing (1). This means that if a (1) block hits even 1us before the (2), bitcoind will sit there processing it until it has finished before it can process (2). While this is purely a limitation of the software as it currently stands that it cannot process multiple blocks concurrently in a multithreaded fashion due to the coarse grained locking in the software, it doesn't change the fact there is no way to deal with this at present. It would require a drastic rewrite of the existing code to make the locking fine grained enough to do this, or a new piece of software written from the ground up; both of which carry their own risks. |
|
|
|
Very lucky guy, 2 blocks in the same day!!! [2017-02-18 01:48:11.748] Possible block solve diff 761664290226.260620 !
[2017-02-18 01:48:11.970] BLOCK ACCEPTED!
[2017-02-18 01:48:12.068] Solved and confirmed block 453586 by 176sh81PQupUsFyX6hNL2PTYydSuL7Wu73.jeffcolo
[2017-02-18 01:48:12.068] User 176sh81PQupUsFyX6hNL2PTYydSuL7Wu73:{"hashrate1m": "495T", "hashrate5m": "487T", "hashrate1hr": "484T", "hashrate1d": "482T", "hashrate7d": "305T"}
[2017-02-18 01:48:12.068] Worker 176sh81PQupUsFyX6hNL2PTYydSuL7Wu73.jeffcolo:{"hashrate1m": "495T", "hashrate5m": "487T", "hashrate1hr": "484T", "hashrate1d": "482T", "hashrate7d": "305T"}
[2017-02-18 01:48:12.068] Block solved after 41886555938 shares at 9.9% diff
I even captured this on my cgminer [2017-02-18 18:48:06.854] Pool 0 message: Block 453586 solved by 176sh81PQupUsFyX6hNL2PTYydSuL7Wu73.jeffcolo @ solo.ckpool.org!
Congratulations wetsuite! Looks like you've recouped all the mining rewards missed out on at shared pooled mining, though you have been extremely lucky. |
|
|
|
[2017-02-17 08:58:10.584] Possible block solve diff 621904402614.558228 !
[2017-02-17 08:58:10.762] BLOCK ACCEPTED!
[2017-02-17 08:58:10.935] Solved and confirmed block 453478 by 176sh81PQupUsFyX6hNL2PTYydSuL7Wu73.jeffcolo
[2017-02-17 08:58:10.935] User 176sh81PQupUsFyX6hNL2PTYydSuL7Wu73:{"hashrate1m": "466T", "hashrate5m": "484T", "hashrate1hr": "487T", "hashrate1d": "479T", "hashrate7d": "286T"}
[2017-02-17 08:58:10.935] Worker 176sh81PQupUsFyX6hNL2PTYydSuL7Wu73.jeffcolo:{"hashrate1m": "466T", "hashrate5m": "484T", "hashrate1hr": "487T", "hashrate1d": "479T", "hashrate7d": "286T"}
With over 1.2BTC in fees. woo my lucky s9's hit a block in less than a week with ~ 500 TH!
I had these pointed at Kano before with ~ 560 TH and they found 5 blocks there in 2.5 months but my actual earnings from the pool was about half that, so I decided to try solo-mining and glad that I did!
Congratulations! The number of shares finally got reset but again the best share counter still didn't reset. I need to kick it in the balls. |
|
|
|
|
sudo is not required for git clone, autogen and make. However since you ran git clone sudo you made it owned by root so everything after that would then need it.
|
|
|
|
|
It's true. It's easy to spoof a node.
|
|
|
|
Would it be possible for miners to set an email address to get notified if they hit upon a block? Maybe they could add it via the website using a signed message from the address they are mining to? It would be helpful for miners who mine long-term without them needing to check their wallet everyday.
Solo has no database whatsoever so there is nothing to store such information and act upon it. I believe lots of web blockchain viewing services provide something for that. On the other hand expected block solves are rare at only about 1 every 2 weeks and I post every single one of them here so if you are subscribed to get email notification of new posts here and see the block count increase in the message topic, you know a block has been solved and can then check here or your wallet. |
|
|
|
Additionally touting the slim block submission as some technical advantage when all it leads to is every single miner starting to mine empty unverified blocks on every block change is a significant step backwards.
If you are going to (try to) rebut the article, how about you actually rebut what it contains? There are exactly zero mentions of 'slim block submission' in the article. Do try to keep up - I don't think you have any idea what Xthin is. Apologies for not being explicit then: The combination of "Xthin" "Expedited Relay" and "Optimistic mining" that BU explicitly is pushing since you want to be pedantic about terminology, and he links the articles that describe it himself, so I'm rebutting not only what's in the article, but his own linked articles within it. |
|
|
|
I certainly don't think so. The fact he's been out of bitcoin for many years shows and he is no longer passing informed judgement. While he tries very hard to make it sound like "it's simple, just increase the blocksize and all will be better" he doesn't remotely seem to understand what a pure blocksize increase brings to the table in terms of quadratic scaling slowdowns and attack vectors. Additionally touting the slim block submission as some technical advantage when all it leads to is every single miner starting to mine empty unverified blocks on every block change is a significant step backwards. Segwit brings linear scaling transactions and core already has compact block propagation where possible without the backward step of encouraging unverified block propagation and mining on them. Scaling the block size alone brings problems with it beyond just the data transfer / storage issues while segwit actually brings added solutions to tackle the extra issues that come with block size increases, increasing both transactions allowed per block now but allowing safer block size increases in the future. |
|
|
|
|
Discussion is pointless and not going anywhere and starting to attract sigspammers so I'm locking it.
|
|
|
|
Could CK do something like that as a stopgap measure?
I have no affiliation with this pool so I can't do anything for it. Perhaps you mis-phrased the question and meant to ask "Could you so something like CK does as a stopgap measure?" |
|
|
|
I'm so confused about this. If this is solo, does that mean if you solve a block, you get all of the block - the 1% fee? When was the last time a block was found?
That is correct. The last blocks solved can be seen here: https://www.blocktrail.com/BTC/pool/solockpoolYou'll see the last block was 17 days ago. |
|
|
|
When was that roughly?
Maybe 18 months ago now... |
|
|
|
|
Hah the network had the last laugh and processed the transaction after about 3 days anyway.
|
|
|
|
|
Will you sigspammers shut the fuck up? You're not saying anything intelligible.
|
|
|
|
Well it is in the mempool and it's 0.13.2 and restarting it doesn't remove it from the mempool... Hmm it could be because I getblocktemplates regularly from the bitcoind... or not :s
Oh, duh, of course its in the mempool, restarting will have the wallet put the transactions back into the mempool on start. You need to set the -walletbroadcast=false command line option when you start it up again in order to prevent that from happening. That did it. The abandon transaction option was no longer greyed out and now the transaction still appears in the interface but is marked in red and the details say not in mempool, even after restarting. I guess this is enough since theoretically it could still be bouncing around somewhere in the network at large. Thanks! |
|
|
|
|
Show Posts
