Only small improvements can be made like segwit, schnorr sigs, compact blocks etc... those are ultimately optimizations and ways to "compress" and deal with the available blocksize faster. Once we run out of that, we need to increase the blocksize too, but it is stupid that segwit is getting blocked, we need both.
And ultimately, no amount of those will allow us to compete against VISA and other centralized payment networks without lightning network anyway. We need Everything.
Yes, this especially. Private payment networks run by Visa and Mastercard blow bitcoin out of the water in terms of speed and cost. The more I see how bitcoin is developing, the less I see it ever achieving anywhere close to parity on either of these issues. Which means bitcoin is likely, taken on a wider view, is a novelty or fad that is likely to flame out eventually. I don't predict that to happen necessarily, but that idea is not foreign to me any longer. I see it having merit and wouldn't be surprised if people become disillusioned with the unfulfilled promise of bitcoin and abandon it slowly over time. I'm getting on in years, retired now. When I first found Bitcoin the quality of its limited total quantity seemed extremely attractive. I mean that inflation isn't quite like hearing my grandmother in the late 1970's talking about NYC rent in the '20's but I have watched the money supply increase over the years, credit cards allowing us to spend tomorrow's income today, and dollars getting much less valuable. How many countries have impossible inflation? Venezuela, Argentina. And what's going to happen if Italy decides to get out of the EU or even just go back to the lira? Or if a terrorist sets off a kiloton nuclear weapon in some major city? I don't see spending btc on a cup of coffee but as a hedge against inflation. That shouldn't change. |
|
|
|
And second, what is the goal of a spam attack? What is gained by the attacker?
My favourite conspiracy theory is that it's some miner(s) who flood the network with transactions, forcing legitimate users to increase their fees in their normal transactions. This works because the miner can just collect his own fees back. (of course only on the blocks they mine) It also explains the hold up on scaling solutions. Scaling solutions break their scam. No proof, just fun speculation. Follow the money does make sense. Reminds me of a national chain that sells a lot of nice Rhode Island Red chicks every year. They lay eggs for 2 or a little more years. While French Black Copper Marans will sometimes lay eggs for 5 years but you won't find those in the store. |
|
|
|
If the solo miner (or pool) receives a valid solved block from a peer, then they add it to their blockchain, remove all the confirmed transactions from their memory pool and start the whole process over again from the beginning building a new list of unconfirmed transactions to confirm.
Making a list of unconfirmed transactions - are the same unconfirmed transactions transmitted to every full node? Since different pools will pick different unconfirmed transactions for the list which they will crunch, it would seem like that would dictate all partially solved blocks be dumped lest an unconfirmed transaction will be in multiple blocks or else that's acceptable. Or since once a block is solved then all inputs are dumped by everyone and restarted with new unconfirmed transactions. Those unconfirmed transactions in the solved block are now considered confirmed? Then subsequent confirmations are due to the solved block passing checks. So, what's to prevent a pool from ignoring solved blocks except for its solution. Wouldn't that increase their take of solved blocks? |
|
|
|
Yes. Any version of Bitcoin Core is a full node.
They aren't calculating a formula, or doing anything efficient (mining is a very inefficient operation). Basically miners are trying to find the right inputs to a specific formula (called sha256d) which result in an output that is less than the current target. The target is recalculated every 2016 blocks and done so in a way that everyone who is following the same chain calculates the same target.
Thanks. So, rebuilding a blockchain with Bitcoin-QT does some crunching of every block download or reindexed. How does that crunch differ from a dedicated miner's crunch? An Antminer or a Mercury doesn't maintain a blockchain of course. I can see that a large pool is in a race with other pools to discover blocks. If the target is changed every 2016 blocks then dumping previous calculations would seem to be inefficient except at the 2016 point. Calculation inputs would seem to need be saved so as to not repeat work. One would think this would be approached in an other than random fashion. Or is the hunt required to have random input tests? And subsequent unique finds of the block's inputs might have a history of the random attempts to prove it isn't just copying but a unique confirmation? Is this anywhere near what's happening? soy I wonder because the slow confirmation rate and the debate about what to do about it is the reason Bitcoin lost a couple of billion dollars the last few days. And nobody is happy about that except pump and dumpers. Or are the inputs so complex in themselves, long and random, that rerunning the same data is so unlikely that it's not a serious consideration? |
|
|
|
Yes. Accounts and addresses are separate from each other. The account system is deprecated and should not be used. It really is more like a labeling system now. The account that an address is in is based upon the label that you set on it.
Okay, so I went with Eligius a few years back and rebuilding the blockchain I see transactions of an address I labeled Eligius. I thought that was a private label only applicable to my wallet. So, that label would appear to Slush if I tried to use that address again? |
|
|
|
|
Yes, Bitcoin Core version v0.13.0 (64-bit)
|
|
|
|
Yes. Any version of Bitcoin Core is a full node.
They aren't calculating a formula, or doing anything efficient (mining is a very inefficient operation). Basically miners are trying to find the right inputs to a specific formula (called sha256d) which result in an output that is less than the current target. The target is recalculated every 2016 blocks and done so in a way that everyone who is following the same chain calculates the same target.
Thanks. So, rebuilding a blockchain with Bitcoin-QT does some crunching of every block download or reindexed. How does that crunch differ from a dedicated miner's crunch? An Antminer or a Mercury doesn't maintain a blockchain of course. I can see that a large pool is in a race with other pools to discover blocks. If the target is changed every 2016 blocks then dumping previous calculations would seem to be inefficient except at the 2016 point. Calculation inputs would seem to need be saved so as to not repeat work. One would think this would be approached in an other than random fashion. Or is the hunt required to have random input tests? And subsequent unique finds of the block's inputs might have a history of the random attempts to prove it isn't just copying but a unique confirmation? Is this anywhere near what's happening? soy I wonder because the slow confirmation rate and the debate about what to do about it is the reason Bitcoin lost a couple of billion dollars the last few days. And nobody is happy about that except pump and dumpers. |
|
|
|
|
Please correct me if I'm wrong in my understanding here.
Miners have a standard, the last block, that they must best by calculating a more efficient formula for content. When a more efficient formula is found, discovered, miners dump what they have been working on and work on the next. Miners in a pool get to share the reward for a discovered block and get some of the transaction fees.
Why not have programs that simply confirm that the block is good, better than the last, and get a cut? Or would that reward, if calculated to be a little less than that for a new block search, cut into the pools' take making it unpopular regardless if it would speed up the process?
I understand miners don't run Bitcoin-QT. I understand that Bitcoin-QT can run a mining operation.
|
|
|
|
|
I rebooted and chkdsk did find some irregularities.
I will try some of the suggestions.
Is Bitcoin-QT Bitcoin Core v0.13.0 (64-bit) a full node?
|
|
|
|
|
Rebuilding for some time now a Bitcoin-QT I had let lapse.
I see transactions from 2015 into the wallet that indicate mined and show a particular address.
In the debug window I run 'getaccountaddress "" ' and get a single address. I run 'getaddressesbyaccount "" ' and still get the one address and it isn't the address showing up corresponding to that in mined.
So, is the address used for mined btc in still capable of receiving payouts from any pool?
|
|
|
|
But more full nodes would be better or not? Do installations of Bitcoin-QT contribute to the confirmation process or not?
Just to be clear, is this Bitcoin Core? Assuming this is Bitcoin Core, what version are you running? Bitcoin Core nodes, do help and are better, in general. Aren't all installations of Bitcoin-QT full nodes? My Bitcoin-QT is using QT version 5.6.1. |
|
|
|
How does Bitcoin Core fail? What do you do that causes it to fail? I upgraded to 64-bit firefox and the BSOD that resulted caused an immediate shutdown of Bitcoin-QT. But more full nodes would be better or not? Do installations of Bitcoin-QT contribute to the confirmation process or not?
More full nodes are better, but they do not contribute to the creation of blocks (aka confirmations). More full nodes will not help confirmations be faster.
Unless the full node is solo mining I suppose but I'm not sure if Bitcoin-QT even does that anymore and the rarity of solo mining finding a block makes its effect negligible? So, Bitcoin-QT checks each block of the blockchain but doesn't discover new blocks unless mining and therefore doesn't contribute to block confirmation rate. Reward only goes to the discover of the block or the pool. I discovered a block for Slush soon after getting a KNC miner early on, the block worth $5k. Would it be possible to program devices to only run confirmation on new blocks for a cut of the reward? |
|
|
|
|
But more full nodes would be better or not? Do installations of Bitcoin-QT contribute to the confirmation process or not?
|
|
|
|
|
I've been running Bitcoin-QT at night for months trying to build a blockchain. I changed to 24/7 days ago and was up to July of last year. Cold nights I started with Slush again after 2 years. Running an S5, with a return of 45% of electric cost which makes it cheaper than propane. I had an old address on Slush and tried to change it. I use Firefox. Repeatedly for days with email exchanges with Slush the problem, mash the cancel the address change button (because it wouldn't change) and it would return to a login screen that doesn't work. A Slush rep told me it might be my browser. I upgraded Firefox to 64-bit from 32. I soon got a BSOD on the Win7 machine. Now after reverting to 32-bit Firefox, Bitcoin-QT won't run. Rescan fails and am reindexing now. And the Slush problem is unresolved.
Was this BSOD intentional by Mozilla? BSOD seems to kill a blockchain with its abrupt termination making reindexing necessary. Do they feel killing a blockchain is politically correct? No wonder there's such a backlog of confirmations and long delays. Nobody in their right mind is going to run Bitcoin-QT and contribute to the chain upkeep.
What's the solution?
soy
|
|
|
|
The wallet is not syncing
|
|
|
|
|
Anyone have anything new on repayment or how much his wife took to Canada?
|
|
|
|
PoS is nice on nixon  |
|
|
|
|
Show Posts
