But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.
The average user no longer has a fighting chance and has given up generating blocks altogether.
It's always been the plan for block generation to not be profitable for most people. It's supposed to be done mainly by dedicated "backbone" entities. What's stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network's integrity, or five businesses producing the same Gh/s that will fail if they or someone else destabilizes the network? I'm not saying that GPU code shouldn't be made, but it's not fair to say that GPU generators are "taking without giving back". People dedicated to generating deserve a head-start on new technologies. |
|
|
|
Maybe we can scale the block limit, like we scale the difficulty?
Compute average block size over past two weeks, and don't accept blocks over AVG_SIZE*100 ?
That would force large block sizes on people who can't handle them. MAX_BLOCK_SIZE can be carefully increased if it's ever actually limiting. 0.3.13 won't even create blocks over 500kB, so it's not a problem right now. |
|
|
|
I did a quick Google search on the topic, and discovered an old Visa press release that stated that during the peak hour for the year of 2005 (Dec 23rd) Visa processed an average of 6,363 transactions per second, or just shy of 3.82 million transactions within a ten minute span.
That's a lot. Bitcoin won't allow blocks over 1MB, so assuming a (rather small) average transaction size of 216 bytes, Bitcoin can only handle 4,629 transactions per 10 minutes. |
|
|
|
|
No one's going to figure out -paytxfee without reading the forums anyway, so we might as well just use -expectedBlockSize and rely on forum members to explain reasonable values if it actually becomes necessary.
|
|
|
|
|
That's cost per kilobyte, though, and a kilobyte can only hold ~9 TxIns, so 0.01 is not guaranteed to meet the requirement.
|
|
|
|
Also, make a note that I posted that same address on these forums on July 13th so unless those transfers were before then, it's safe to say that I'm actually the owner of that address. So, can you verify the time frame that the transfers were sent?
Two transfers: block 80339 (12 days ago) and 82659 (1 day ago). |
|
|
|
|
70,000 BTC has been sent to the address that bitcoin2cash posted. I don't have tools to see spends from an address, so I can't say what the current balance is.
|
|
|
|
|
As far as I can tell, transactions are not prioritized according to fee size. Paytxfee just ensures that you will meet the fee requirements (and it isn't guaranteed to do that). This does seem to be contrary to what Satoshi and sirius-m have implied, but I can't find any prioritization in the code.
|
|
|
|
|
The best option might be four passes at 120, 6, 1, and 0, to somewhat prioritize based on depth.
|
|
|
|
At (roughly) line 3191 in main.cpp (SelectCoins), change the if statement to this: if (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1) Your client will then no longer consider coins with 0 confirmations when choosing coins. |
|
|
|
|
You could just send the 50,000 BTC to yourself and the transaction will be visible in the block chain.
|
|
|
|
Do you know if there is a plan to fix this bug. I don't know. It'll probably be fixed eventually. On Linux you can do "bitcoind ; sleep 1" and you'll get the shell back. Maybe something like that will work on Windows, too. |
|
|
|
I checked the code. It seems that the transactions will be relayed, since they pass AcceptToMemoryPool. The network will tend to forget these transactions because the memory pool is cleared when Bitcoin shuts down, and as far as I can tell nodes never relay transactions that they already have in their memory pool. I don't know if there is any protection in the protocol from this kind of attacks There is. The more transactions waiting to be included in a block, the higher the transaction fee has to be for one to get in. |
|
|
|
Huh? Clients don't propagate what they consider invalid? I thought that they just didn't include it in their blocks...
Hmm; I'm not sure about this case. They're not working on your new transaction because the previous transaction wasn't in a previous block and isn't in their memory pool. I don't know if they'd relay it. |
|
|
|
Because the change leftover was also then never confirmed, yet my client treats it as if it was so includes those amounts in the amounts it sends out. This seems likely. Try sending a ton of 0.01 transactions -- most of these transactions will work if this is the case. Or wait until someone else with a custom client includes your transactions in his block.
For this you'll want to use the -maxconnections switch with a high number of connections, because propagation of your invalid transaction will be very poor. You could also "double-spend" your pre-experiment coins by acting as though the unconfirmed transactions never happened. A wallet backup would roll things back, for example. |
|
|
|
|
Bitcoin doesn't correctly return the prompt after that message. Are you sure bitcoind is not running after you Ctrl+C?
|
|
|
|
|
I don't think the difficulty will affect the exchange rate.
7200 BTC will be created daily (on average) no matter what. Whoever gets this is generating, which means they find the current difficulty to be profitable for them. They might bet that the value of BTC will increase in the future, but they can't force an increased rate on the market right now -- no one would accept their offer.
|
|
|
|
|
Non-generating nodes only need the Merkle tree and block headers, which is not very much data. (Use of the abbreviated block chain isn't implemented yet, though.) Maybe someday generators will need a strong Internet connection, but since the average size of a transaction is 214 bytes and the average number of transactions per block is 2, this will not be any time soon.
Generators will eventually become the network's backbone. They will connect to each other with strong connections, and clients will connect to only a few generators. Like ultrapeers in Gnutella, but normal people will not typically run generators.
If it ever becomes difficult for even members of the backbone to download the entire block chain, most of the transactions can be forgotten. Only transaction end-points need to be kept.
Segmentation is not a serious problem unless it lasts for longer than 100 blocks (the network-enforced maturation time for generations). The network will heal itself perfectly for any shorter segmentations.
|
|
|
|
|
Show Posts
