|
So a couple points of clarification. The idea of including tx hashes in the block MESSAGE wouldn't change the size of the actual block. It would simply be a new message type. Remember bootstraping nodes also require older blocks and they won't have the txs either so the existing block message would be useful in cases like that.
Simplified version:
on newest block when latency is important = use header + tx hash message.
on older blocks when latency isn't an issue = use header + full tx message.
As for the block limit well that is another more complex issue. Honestly I don't see it very important right now. The number of full blocks since the genesis block is exactly 0.0%. Even today with a backlog of txs the average block size is ~200KB and the largest block is ~600KB. Raising the limit doesn't change the "orphan economics".
|
|
|
|
|
There isn't magical about a super computer. It can't hash faster than its hashrate. All that matters is the hashrate and today many ASIC farms are magnitudes faster than supercomputer at performing SHA-256 hashes.
There is no known shortcut to finding hashes. If there was that would mean SHA-256 is broken and most forms of cryptography not just Bitcoin rely on it. Everything from protecting nuclear launch codes, to making sure ATM are "talking" to the real bank and not an attackers computer.
|
|
|
|
It's more like placing each criminal in it's own cell. Currently if one wall is blown up many thousands of criminals can escape.
By placing more walls around the criminals less criminals can escape if one wall were to be broken.
More like moving each cell to their own universe so if they escape they have nowhere to go. I think you vastly misunderstand the odds we are talking about. |
|
|
|
Well larger blocks are never going to be faster or as fast as smaller blocks. The goal is to reduce the latency time per kB. The faster a block can be broadcast the lower the "orphan cost" per tx. Still larger blocks will always have a higher orphan rate but they also have higher gross revenue. The good news is the current method is about the slowest, most bloated method possible for broadcasting a block. Any change is an improvement. One proposal is to only include tx hashes in the block message. Currently a block message consists of a block header and a list of all tx in the block. Most nodes know of most or all of these tx, hell they already have verified them and included them in the memory pool. This simply makes the block larger than it needs to be. Instead the block message can consist of the block header and a list of tx hashes. The average tx is ~ 400 bytes and a SHA-256 hash is 32 bytes so we are talking a 90%+ reduction in block message size and thus propagation time and thus orphan costs. For example lets look at this recent block: https://blockchain.info/block-index/443364/0000000000000003b90c99433d07078d5498910442489383f18e250db0a843e2301 tx and 480 KB. If the block message was changed to be just tx hashes the block message would drop from 480 KB to ~10 KB or a 98% reduction in size. Another client side change would be removing the double verification of txs. This may have already been completed I haven't looked at that code since before v 0.7. Improving the efficiency of mining benefits all users not just miners as orphaned blocks are simply wasted energy. They lower the effective security of the network. Further size reduction is possible but requires some more significant changes to the protocol. |
|
|
|
Is there a general rule for how much I should make my transaction fees to ensure speedy insertion in blockchain and thus speedy confirmation?
the min fee for low priority tx is a good place to start. That is 0.1 mBTC per kB. |
|
|
|
|
No miners aren't going to switch to a new block until they receive and verify the existing block so pre-announcement or not the faster block will be received and verified and miners will switch to that. Doing anything else would be subsidizing the owner of the slower block at the expense of their own revenue.
There are real solutions which can reduce the broadcast time by 90%+ or more.
|
|
|
|
I am lost ? Is he talking about mining it ? Yes and Yes. |
|
|
|
note: DSV refers to the program grue mentioned above. For whatever reason, DSV is castrated by the developer (it only searches for addresses beginning with 1DSV). This assumes there is a non-castrated, optimized DSV which may include botnets or NSA super computers (really, super-duper theoretical computers from the land of Oz). Assuming 500K addresses which either have funds or will have funds within next three months,
0.0000000000000000000000000000000000000000034211388289180104270598866779539% chance per check (or address creation).
Assuming average computer can do 250 optimized DSV-like checks per second,
0.00000000000000000000000000000000000000085528470722950260676497166948848% chance per second.
Assuming a "theft pool" is formed, and 500 of these computers averaging the above click/s,
0.00000000000000000000000000000000000042764235361475130338248583474424% chance per second.
Assuming each theft pool is one botnet, and 20 botnets, exactly the same, exist in these theft pools,
0.0000000000000000000000000000000000085528470722950260676497166948848% chance per second.
Per minute,
0.00000000000000000000000000000000051317082433770156405898300169309%
Per hour,
0.000000000000000000000000000000030790249460262093843538980101585%
Per day,
0.00000000000000000000000000000073896598704629025224493552243804%
Per month (30D),
0.000000000000000000000000000022168979611388707567348065673141%
Per year,
0.00000000000000000000000000026972258527189594206940146568988%
Assume worst-case scenario, DSV-like software can check 5000 addresses (10M of which are funded or will be funded within 6 months) per second, and 100 botnets of 50,000 computers each...
Per day,
0.000000000000000000000000014779319740925805044898710448761%
Per month,
0.00000000000000000000000044337959222777415134696131346283%
Per year,
0.0000000000000000000000053944517054379188413880293137978%
Per century,
0.00000000000000000000053944517054379188413880293137978%
ETA: Worse-than-worst case scenario. NSA can check 1T addresses per second, 1T addresses are funded.
Per century,
0.0000000000000021577806821751675365552117255191%
Per billion centuries,
0.0000021577806821751675365552117255191%
 |
|
|
|
I'm sure you have at least one online account with money, yes? what is its defence that someone be it a bot or a person can type your exact user id and your exact password and if you have it your exact two-factor dongle code, and then transfer your funds somewhere? This too is a possibility. And many many many magnitudes more likely then generate a key which matches a funded addresses. |
|
|
|
What if you're trying to solve a block and someone else solves at first, was all your time wasted?
Effectively, yes. Mining is a race, winner (of the block) takes all. Fascinating discussion. I was not aware of this. Now, I feel like I'm at the racetrack.  It is incorrect (and a common misconception). Nothing is wasted when someone else solves a block because there is no "progress" towards a block. Each hash is like a lottery ticket. It either wins or it loses. Nothing more. Having a thousand losing tickets means they are still losers regardless of if someone else wins or not. If you mine a quadrillion hashes that fail to meet the difficulty target, you are no "closer" to solving a block then when you first started. Each hash is an independent roll of the dice. It either solves the block or it doesn't. |
|
|
|
Once replace-with-fee is deployed, I could rip off that coffee shop with near 100% reliability, every time until they stop serving me coffee. Don't accept zero-conf transactions.
The proposed replace with fee requires the same outputs. Of course you could also rip off a coffee shop with counterfeit bills or a stolen credit card. Would be kinda stupid to go to jail for stolen coffee though. |
|
|
|
Nope. The miners would still get to work on the first one they received. Then, if they get the announced block within 15 seconds, they'll switch to the first block they heard about. But if they don't get the announced block (and if it's a fakeout message they won't) then they don't change what they're doing at all. Even if that includes *FINDING* a new block before the announced block arrives, in which case the announced block *will* become an orphan.
Then you haven't sold anything. The "critical window" for computing orphan losses is the time between when a miners finds a block AND the entire network is building the next block on top of that. That includes the time to relay and verify the node, and all miners to switch to the next block. During the "critical window" if another miner finds and broadcasts a competing block the network will be split. Announcing an announcement of a block would solve absolutely nothing. There are solution to significantly reduce the block broadcast latency but that isn't it. |
|
|
|
|
Measuring a return in dollars is silly. You could have simply bought Bitcoins instead and made even more profit with lower risk.
|
|
|
|
This account will be used to handle customer service for BitSimple.
Confirmed. This is authentic. |
|
|
|
|
Thanks for all the help beta testers. Testing is closed (those with open invoices are still valid). We probably will do another test run on Monday. System should be live in December. To the trolls in the thread, the service is being operated by North American Cryptographics, LLC and is registered with FinCEN.
|
|
|
|
|
No it is correct. See I actually know how Bitcoin works.
Invalid blocks are never part of the longest chain. Never. Not once, not ever. All nodes independently verify data received by other nodes. That is the basic cornerstone of Bitcoin's security model. If you can't get that right then why should anyone listen to any on the nonsense you are spouting.
As for your rebutal that is also nonsense. Invalid blocks aren't included in the difficulty adjustment calculation. They are simply dropped. What part of dropped don't you understand? The remaining valid miners would find blocks at ~10 minute interval.
So if in the time 2016 blocks should be found miners produce 2016 valid blocks and the attacker produces 489748971983472982372189 invalid blocks the 489748971983472982372189 invalid blocks are simply dropped. They just cease to exist as far as every node on the network is concerned. 2016 valid blocks were found in the difficulty adjustment period so difficulty remains "low". Now the bad actor WAS mining valid blocks are started mining invalid blocks it would be no different than simply stop mining. Blocks would be found slower, difficulty would go down, blocks would be found faster again.
|
|
|
|
Is anybody losing in this scenario?  Obviously not. Everyone wins and it just keep going up billions of % in the OP scenario. |
|
|
|
<snipped>
STILL WRONG. ALLL NODES AS IN ALL 100,000+ ON THE NETWORK REGARDLESS OF IF THEY ARE MINING OR NOT VALIDATE ALL TX AND ALL BLOCKS. That is the security model of Bitcoin. No node trusts the output of any other node. So miner makes a block giving him a single extra Satoshi and relays it to his peers. Guess what? Those peers validate the block and the block is invalid. It is simply dropped. It never becomes part of any chain. A BLOCK WITH MORE COINS THAN ALLOWED BY THE PROTOCOL IS INVALID. PERIOD. 1+1 = 3 is still invalid even if it is the longest chain. Nodes (once again ALL NODE not just miners) use the longest (most work) VALID chain. A chain which contains blocks which mint extra coins is ALWAYS invalid and thus will NEVER be picked by any node. |
|
|
|
Yes very worried because it means they can control the network and even modify the protocol to make it a fiat, create a zillion coins, etc.. Some argue that they can't do that because the Bitcoiners will fork to a new chain. But these Bitards forget that the masses don't care about Bitcoiner idealism. They just want to buy their pizza. See my Transactions Withholding Attack thread for more explanation on that. Once the masses are already using one fork, they won't switch. The controller could run the fork well enough that the masses are happy, even while creating more coins, etc. Exactly like fiat. We go right back where we started. That is nonsense. It isn't that other nodes would fork it is that 100% of the nodes would simply reject a chain which violates the rules like create a zillion coins. It doesn't matter if a single miner does it or someone with 99.999999999999999999999999999999999% of the hashpower. An invalid block is invalid regardless of how much hahpower created it. Miners simply force a consensus when the network is split on the status of transactions. All node (as in every single full node on the network regardless of if they are mining or not) independently verifies all transactions and blocks. An invalid block is simply invalid. Your claim is simply false and shows a lack of basic understanding of the system you are trying to "fix". https://en.bitcoin.it/wiki/Weaknesses#Attacking_all_users |
|
|
|
|
All miners are working on unique work this applies both in a pool and across the planet. The only exception would be an error in pool setup/design.
|
|
|
|
|
Show Posts
