Topic: High orphan rate and long confirmation time discussion - page 4. (Read 9894 times)

Maybe they should fix the uPnP not working on at least Ubuntu(can't talk about other OS's as I have no experience with them).
I have uPnP enabled on the client, uPnP enabled on my router, yet, if I don't forward the port on the router I never get more than 8 connections.
Maybe an increase in better connected nodes will solve the block propagation time?
Transactions get propagated fairly quick even with 8 connections but maybe full blocks don't as they are bigger in size.

I developed a theoretical concept for a swarm client, that would likely solve this issue.

Basically blocks are split up into branches so that no clients have to propagate, store nor confirm a full block.

It's over in the development discussions.

Really that is the security risk?

Propogation should take at most a few seconds so miners would be wasting work on a bad block for a few seconds and only on the few time (<1% ?) that a bad block w/ valid header is propagated.  Current miners are wasting hashing power on every block from the time it is found until the time it is propagated to them.

Remember the header can't be faked a valid hash on a block with a random nonce as the merkle root hash requires the same amount of work as a valid hash on block header with a merkle root hash which corresponds to an actual set of valid txs.    Not much attack there (attack would by definition needs to waste 100x to 300x as much resources as he causes good miners to waste).  Maybe in very isolate incidences a miner may produce an invalid block and that error isn't detected for a few seconds but miners that do that aren't getting compensated so they have a vested interest in fixing that flaw.

Done.

Only when there's an orphan issue ...

In fact as I told Luke-jr in IRC over a day ago - most bitcoind's already have every txn except the coinbase txn in their mempool.

And in the meantime, all the miners are working on an invalid blockchain...

What security risk?  The proof of work can't be faked.  From the Pow point of view the tx in the block are immaterial.  The merkle root hash is merely a 256bit input.  Also i didn't mean download tx one at a time.  

More like:
broadcast block header -> node verifies and relays -> node verifies and relays -> node verifies and relays

Then nodes request the "block body" from peers and propagate.  If there is no valid matching merkle tree for the header the block is discarded as invalid and network revert to the prior longest chain.

The 0.6.0 RC2 client was released around that time, I think.

No; since you now don't have the block until you've requested every txn you're missing, it would probably take longer. And you can't accept the block until you have all its transactions, or you create a security risk. That being said, it might still help to cut down on bandwidth use; my suggestion in this area is a compromise: send blocks as header+txnlist initially, but keep track of which transactions you didn't have when you received it, and automatically send those to peers you relay the block to before they ask for them. This way, nodes only have to explicitly ask for transactions they didn't have, but the peer relaying the block to them did have.

To address the block propagation problem itself, however, my first recommendation is to relay the block before checking transactions (but after checking proof-of-work and other fixed-cost checks, so DoS attacks are still impractical). The blocks with more transactions still have the cost of transaction verification delay (that cannot be fixed without changes to the Bitcoin system itself), but that delay shouldn't affect orphaning of the block itself.

In all my years of network management, this kind of chart clearly has indicated that I've made a change to my system that's resulted in the unanticipated increased use of a resource.

I'm certainly not an expert on bitcoin or it's code, but this definitely suggests that a change in the code has caused increased confirmation times.

You should probably avoid the use of the word microtransaction: Commonly used meanings span at least four orders of magnitude in value.

Is bitcoin a system suitable for $1 scale value transactions.  Perhaps.  Is it a system for sub-cent transactions, very very likely not.  At the end of the day bitcoin is a worldwide broadcast medium. The broadcastness provides very high confidence that it can't be artificially inflated and that old txn can't be reversed. But the fact that no information is hidden does ultimately limit the scaling— though I don't think that its much of a problem. You don't need that kind of security for very tiny transactions. So you can use something that isn't broadcast based to trade small values and frequently settle against bitcoin. ::shrugs::

Of course, none of this has anything to do with improving the performance for what we have today, of course that has to be done.   But the solution to that is "shut up and code" and "shut up and test", not more navel gazing on the forums.

An increase in the number of transactions on the network is of course what EVERYONE wants.

What everyone may or may not want is how that happens.

But seriously, the BTC network is a tiny ant in the monetary world and certainly needs to be able to deal with something a LOT more than it can (without people complaining about it) today.

Attempting to reduce the transactions (as I've seen some suggest) is, IMO, completely against the BTC ideal.

IMO, anyone thinking that anything but a few rules should be encoded into the basic bitcoind spec and base code is missing the point.

Slowing down or ignoring txns/addresses/fee levels is up to pools and solo miners.
As long as pools aren't lying about what they do (or hiding the facts) there is no technical issue there, since people should mine at pools they are happy with the way the pool handles transactions.
The base client should not have much if any of this at all.

The problem that comes with this is, however, reality.
Some pool OPs may lie or hide what they are doing.
A lot of miners don't really care if their pool is fucking up the network.

Still, it's a BTC free market, not a BTC dev fascist state (even if some don't see it that way


Definitely the software needs improving, not more rules and restrictions added to it, to stunt the growth of BTC.


OT: Just a point about block times - yes if you look through the block-chain you will regularly find blocks that have a timestamp before the previous block.
If you look at the previous block you will often see that it is Eligius (at there, a 2000% E: is considered possible and reasonable)
That's life ...

That solution is indeed possible and already being worked on.

There are some other things being looked at as well, for improving block propagation times.

Confirmations can't take zero minutes on average, that graphic is broken. Presumably the data doesn't start until the point where it first ticks above zero.

Can you update your post to reflect this? The implication that delays started so early is causing people down thread to jump to erroneous conclusions.

Well I am less concerned about block prop times as doesn't the new (0.7) of bitcoin eliminate the double verification of block txs.  That should dramatically help with prop times.

Also correct me if i am wrong but could block prop be spit into a two step process.

1) Broadcast block header.  Nodes can verify the validity of the pow w/ just header.
2) Nodes request block txs from headers they have confirmed are valid.

This would result in full block taking no longer to verify and propogate than a 0 tx bock.  It would also provide other useful benefits.


I am more concerned with some unexplained factor causing a rise in avg confirmation time.  The again if I was running a major pool I might not feel that way.

Now it would be interesting to see if the orphaned blocks have more transactions included than the blocks in the main chain.

The avg confirmation time isn't the (immediate) problem. The problem is block propagation time. If that isn't solved, you will likely see another sharp rise in avg confirmation time soon.