|
Offering 0.1BTC for 3goxBTC until their next announcement or major piece of information comes out about them.
|
|
|
|
If you send an invalid transaction to all your peers, they will see that it's invalid and no forward it to all their peers. The only way your recipient would see it is if he/she was one of your peers. Edit: I should mention that there is a project that uses a network with the same network topology as Bitcoin to broadcast messages called Bitmessage. https://bitmessage.org |
|
|
|
Good point. The attacker could do that, however transactions that are older than 1 hour could never be reversed! And isn't that the whole point of an 51% attack?
The only thing an attacker could do is now
* prevent any transactions from happening
* reverse or double spend transactions that are younger than 1 hour.
which is very expensive and not that dangerous imo.
If a Merchant receives a big transaction he could just wait 6 confirmations (maybe double check transaction on blockchain.info and blockexplorer.com) and even if the attacker is in full control for the whole time this transaction could not be reversed!
No, if they make a concurrent fork then they could distribute the block to many nodes in the network after they have confirmed that they node they want to attack has received the transaction they wish to reverse. |
|
|
|
|
If someone has 51% of network power, what prevents them from creating a fork of the mainchain as the mainchain is being produced? They could release a block every time the mainchain block produces one. This would cause two different clients to see two different forks and have no consensus.
|
|
|
|
This doesn't eliminate spam, it just makes it much slower. It uses hashcash, which means someone can flood the network fairly easily. Anyways, here's my idea based on your idea OP. 1) I want to send a message. I sign an email with a key that has control of a certain number of satoshis, then I encrypt the email with your public key. 2) I make a transaction spending to a script. The script gives me a refund if either 48 hours have passed, or 2 of 3 signatures sign it. Otherwise, if another set of 2 of 3 signatures sign it (these keys are used solely to indicate that it is spam) it spends to a charity address. The mediator address is chosen from either a web of trust or a mutually recognized authority. 3) I send you the signed encrypted email along with the script. 4) Before opening the email, your client automatically verifies that it has been signed by the signature of someone who just spent the threshold number of coins to the script that your received. 5) If it is spam, you can prove it using their signed message and you and the mediator will both sign it and give money to charity. Otherwise, you can click "not spam" and give him a refund, or just wait 48 hours. |
|
|
|
You aren't giving anyone an advantage by letting them mine on your blocks because it's either your blocks or someone elses blocks they're going to be mining on.
Certainly they gain something. By building upon your block rather than beside it the probability of their next block becoming an orphan is reduced. Question: What does this obscure example of a network with terrible rules have to do with anything?
I don't know about you but I'm talking about Bitcoin with it's current rules. If there are 10 blocks per second they could easily be mining on someone elses block. They benefit you by mining on it. You aren't talking about Bitcoins rules. If we were talking about bitcoins rules we would be talking about blocks that are propogated in 1/500th of the block generation time, not 10 times the block time. |
|
|
|
This was not a strawman. I have not mis-represented your argument. If you have a block and wait instead of broadcasting, someone else could broadcast their block in that time, which would mean the network would start mining on their block instead of yours and you would be left with a stale block instead of 25btc rewards.
very clearly suggests that the first to broadcast will receive the attention of the network as a whole, guaranteeing that a later broadcast rival block will become an orphan. You've merely changed your argument to: If you broadcast sooner, it is more likely that more of the network will recognize your block over another.
Unfortunately, while true, this is insufficient to support your earlier claim: Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...
You misrepresented my argument saying I thought the propagation was instantaneous. I didn't suggest the first to broadcast that the network would immediately recognize theirs, I only implied that it could be propagated in that time "someone else could broadcast their block in that time". Certainly, a pool wants to reduce the probability of its blocks becoming orphans. To this end, the broadcast strategy: "broadcast as soon as possible" is optimal. However, a pool will also want to reduce difficulty so that it is able to find more blocks. To this end, the broadcast strategy: "broadcast a block only once a rival block has been seen" is (roughly) optimal. It is not clear that the first concern always outweighs the second (for pools controlling no more than 50% of the network by hashrate), especially in light of the fact that some nodes are better connected than others.
If you broadcast block-you-found 1 and that is chosen as the winning block by the network, then you have 1 block. If you keep mining on that block, you will keep having the same chance of having your block winning. If you wait until you have 10, you will only win if 10 haven't been mined in that time. You aren't giving anyone an advantage by letting them mine on your blocks because it's either your blocks or someone elses blocks they're going to be mining on. Question: What does this obscure example of a network with terrible rules have to do with anything? |
|
|
|
|
There is no guaranteed way to have proof of need, especially not a decentralized way.
Imagine I found a pounds of gold in my back yard. If I had a run down ghetto house and didn't let anyone know I found a lot of gold I could fool this centralized system into thinking I needed money based on living situation.
|
|
|
|
This is only true if they have 51% of the network power. Otherwise broadcasting (even if the odds of stale are high) increases your odds of making money from 0% to something%.
No, but it depends on a breakdown of a the core assumption about network conditions. Imagine that you have a miner with 20% of the network power and the other 80% are lots of small miners. It takes 5 seconds for blocks to propagate over the network. However, the network produces 10 blocks per second. The 20% miner gets 2 blocks per second. This means that he can create a chain of 10 blocks during the network propagation time. The other 80% can't coordinate. They produce 8 blocks per second. What should they set as previous block? The can't coordinate, so they all set it to point at some block from the last 5 seconds which is 40 possible blocks. They all spread their mining power over 40 possible previous blocks. This means that their chain grows 40X slower. If the 20% miner released his chain, it would help them coordinate, so he doesn't. They produce 8 blocks a second but their chain only grows by 1 block every 5 seconds. The 20% miner grows his chain at 2 blocks a second, which is faster than any of them. His advantage is that he gets 100% efficiency from his mining power and directs it at one chain. That example doesn't illustrate that producing a 10 block chain before broadcasting is advantageous. If you wait to broadcast until you have a 10 block chain you will only succeed when you have a 10 block chain faster than the rest of the network. Broadcasting the blocks individually and building on top of those makes you win both in the case that your 10 block chain is the tallest and the case where some of the first are part of the tallest. What your example does demonstrate (and I think this is where the confusion is coming from) is that it is an advantage to be in a pool when you have ridiculous block generation speed. |
|
|
|
I am not assuming that it is instantaneous. If you broadcast sooner, it is more likely that more of the network will recognize your block over another. Your strawman is irrelevant anyways because whether or not the broadcast to the entire network is instantaneous, it is beneficial to broadcast as soon as possible.
It turned out that holding back your blocks was the best strategy for the miner with the most hashing power. This is only true if they have 51% of the network power. Otherwise broadcasting (even if the odds of stale are high) increases your odds of making money from 0% to something%. |
|
|
|
Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...
I don't think this is correct. Why not? If you have a block and wait instead of broadcasting, someone else could broadcast their block in that time, which would mean the network would start mining on their block instead of yours and you would be left with a stale block instead of 25btc rewards. You seem to be assuming that broadcasting a block is an instantaneous process. This would make things far easier but, alas, it is not the case. Notice also how it's possible to have one fraction of the network building on one block while another fraction builds on its brother. This is not a fleeting state but one that will likely endure until someone finds a block to settle the issue. I am not assuming that it is instantaneous. If you broadcast sooner, it is more likely that more of the network will recognize your block over another. Your strawman is irrelevant anyways because whether or not the broadcast to the entire network is instantaneous, it is beneficial to broadcast as soon as possible. |
|
|
|
Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...
I don't think this is correct. Why not? If you have a block and wait instead of broadcasting, someone else could broadcast their block in that time, which would mean the network would start mining on their block instead of yours and you would be left with a stale block instead of 25btc rewards. |
|
|
|
There is no way to prove that, but when a miner generates a block they will immediately broadcast it so they *don't* get orphaned.
Well not if they're "selfish" right.... That's why I am interested in this metric. It could be to useful infer statistically if pools are delaying broadcasts. I want to understand your 75% figure but I can't get past the lack of a clear definition for orphan. You must mean something like 75% of blocks broadcast by major pools which were seen by many nodes and are not part of the main chain today, if we measure the longest chain right now. Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast because delaying that broadcast could mean losing the block. It isn't selfless to broadcast your blocks. I mean 75% of the blocks on blockchain.info aren't in the unknown category meaning 75% of them were relayed directly from the miner. If 75% of the blocks are relayed by known miners, then 75% of the orphans are going to be directly relayed to them. Orphans that aren't released fast enough and not directly may not make it to them (this is the 50% you were talking about). |
|
|
|
Right, well I made serious remarks about the shortcomings of that definition - it doesn't refer to a measurable quantity. It refers to nothing in fact - there is no way to prove that there aren't infinity of those every day.
There is no way to prove that, but when a miner generates a block they will immediately broadcast it so they *don't* get orphaned. Blockchain.info is connected to most of the major pool nodes (75% of the network hashrate is identifiable to them). 75% is more than half, therefore blockchain.info probabilistically should see more than half of all orphaned blocks. You can't prove that there aren't infinity, but if unknown miners were producing a ton of orphans on top of the main chain then they would also be producing a ton of blocks on top of the mainchain. |
|
|
|
|
0hzEDASM25bAu2HM2JRdeMWq8JsJQnZojv
Thanks.
|
|
|
|
Blockchain.info is connected to every major pool, so they will see much more than half of all orphans.
I can say with considerable confidence that you are not in possession of data supporting that claim. Well right here it says who the block was relayed by. It either was sent to them originally by an unknown node, or it was sent to them by a known node which is owned by the pool. https://blockchain.info/pools |
|
|
|
Does anyone know a web page which shows a live statistic of the number of orphans created in a day ?
Is there any paper that presents this information?
Have anyone computed the average orphan rate during last year and previous years?
Best regards,
Sergio.
There is not, and such a thing is not possible. The concept of orphanhood is purely local. Some sites have lists of orphans as seen by their node. Blockchain.info has already been mentioned, block explorer has another. There are probably others too. A while back I estimated the global race/fork rate to be in the neighborhood of 1 in 300. My method was not very special, merely counting the orphans seen by a node and dividing by the number of blocks over the same span and multiplying by two (because I figure on average a given node will land on the winning side first about half the time). I have vague memories of other people arriving at similar figures, but I doubt that I could find any references. Blockchain.info is connected to every major pool, so they will see much more than half of all orphans. |
|
|
|
|
Show Posts
