Bitcoin Forum
December 10, 2016, 06:46:19 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 »  All
  Print  
Author Topic: High orphan rate and long confirmation time discussion  (Read 8772 times)
Schleicher
Hero Member
*****
Offline Offline

Activity: 630



View Profile
June 18, 2012, 01:42:47 PM
 #21

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

Bitcoin donations: 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
1481395579
Hero Member
*
Offline Offline

Posts: 1481395579

View Profile Personal Message (Offline)

Ignore
1481395579
Reply with quote  #2

1481395579
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481395579
Hero Member
*
Offline Offline

Posts: 1481395579

View Profile Personal Message (Offline)

Ignore
1481395579
Reply with quote  #2

1481395579
Report to moderator
1481395579
Hero Member
*
Offline Offline

Posts: 1481395579

View Profile Personal Message (Offline)

Ignore
1481395579
Reply with quote  #2

1481395579
Report to moderator
1481395579
Hero Member
*
Offline Offline

Posts: 1481395579

View Profile Personal Message (Offline)

Ignore
1481395579
Reply with quote  #2

1481395579
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 18, 2012, 01:48:07 PM
 #22

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. Smiley
gmaxwell
Moderator
Legendary
*
Offline Offline

Activity: 2030



View Profile
June 18, 2012, 01:53:39 PM
 #23

This can be seen here:

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.
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526


View Profile
June 18, 2012, 01:54:13 PM
 #24

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.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
June 18, 2012, 01:58:45 PM
 #25

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 Smiley


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 ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
gmaxwell
Moderator
Legendary
*
Offline Offline

Activity: 2030



View Profile
June 18, 2012, 02:02:06 PM
 #26

Some say that bitcoin was never meant to be a system for micro-transactions but that actually appears completely wrong to me if we're to assume widespread acceptance of btc.

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. Smiley
guruvan
Hero Member
*****
Offline Offline

Activity: 518

ShastaFarEye Prospectors mazaclub & mazacha.in


View Profile WWW
June 18, 2012, 02:02:39 PM
 #27

Just to make it clear what we're talking about:

... [images]

In case anyone can think of anything that occurred in conjunction with the increase in tx conf times, the start of the current tx conf times is 2012-02-26, with previous spikes on 2012-02-06 and 2012-02-15 to 2012-02-16.

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.

Mine at the Maza Club! with ShastaFarEye Prospectors! Mazacoin PPS & P2pool mining, and more services coming soon!
Maza Means Money! Check yours at the mazacha.in!

Please contact me  on my  OTC registered GPG (A54E87F2) Key's email address or guruvan@shastafareye.net  and encrypt all correspondence.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
June 18, 2012, 02:04:32 PM
 #28

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.
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.

Schleicher
Hero Member
*****
Offline Offline

Activity: 630



View Profile
June 18, 2012, 02:45:02 PM
 #29

In case anyone can think of anything that occurred in conjunction with the increase in tx conf times, the start of the current tx conf times is 2012-02-26, with previous spikes on 2012-02-06 and 2012-02-15 to 2012-02-16.
The 0.6.0 RC2 client was released around that time, I think.

Bitcoin donations: 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 18, 2012, 02:50:42 PM
 #30

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.

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.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
June 18, 2012, 02:57:15 PM
 #31

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.

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.
And in the meantime, all the miners are working on an invalid blockchain...

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
June 18, 2012, 02:58:13 PM
 #32

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.

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.
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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
June 18, 2012, 02:59:49 PM
 #33

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.

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.
And in the meantime, all the miners are working on an invalid blockchain...
Only when there's an orphan issue ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
June 18, 2012, 03:04:50 PM
 #34

This can be seen here:

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.

Done.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 18, 2012, 03:05:08 PM
 #35

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

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.
Realpra
Hero Member
*****
Offline Offline

Activity: 819


View Profile
June 18, 2012, 03:13:55 PM
 #36

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.

Cheap and sexy Bitcoin card/hardware wallet, buy here:
http://BlochsTech.com
imsaguy
General failure and former
VIP
Hero Member
*
Offline Offline

Activity: 574

Don't send me a pm unless you gpg encrypt it.


View Profile WWW
June 18, 2012, 04:49:58 PM
 #37

subbb

Coming Soon!™ © imsaguy 2011-2013, All rights reserved.

EIEIO:
https://bitcointalk.org/index.php?topic=60117.0

Shades Minoco Collection Thread: https://bitcointalk.org/index.php?topic=65989
Payment Address: http://btc.to/5r6
Gladamas
Sr. Member
****
Offline Offline

Activity: 294


Bitcoin today is what the internet was in 1998.


View Profile
June 18, 2012, 04:58:42 PM
 #38

subbb

1GLADMZ5tL4HkS6BAWPfJLeZJCDHAd9Fr3 - LQ6Zx8v7fHVBiDX5Lmhbp6oEDB7dUFjANu
GPG 0xF219D5BB3C467E12 - Litecoin Forum
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1442



View Profile
June 18, 2012, 05:17:46 PM
 #39

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.

Gladamas
Sr. Member
****
Offline Offline

Activity: 294


Bitcoin today is what the internet was in 1998.


View Profile
June 18, 2012, 05:20:52 PM
 #40

It seems like part of the problem with blocks not including transactions is the maximum block size of 500kB. Doesn't this pose a scalability problem?

There are also some odd rules mentioned in the Wiki that increase fees when the queue of transactions gets too deep. I haven't reviewed the Bitcoin code to comment further how these are enforced by miners and when sending in the client:
"If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB."


The size of the queue of unconfirmed transactions waiting for inclusion is known by your client but can't be viewed. It can be seen here: http://bitcoincharts.com/bitcoin/txlist/. At this immediate moment, there are 2763 unconfirmed transactions (1454847 bytes). That would seem to me to be larger than the maximum blocksize indicated above, so the above rule about higher transaction fees may be kicking in on the miner's side for inclusion of transactions (but the client isn't prompting).

1GLADMZ5tL4HkS6BAWPfJLeZJCDHAd9Fr3 - LQ6Zx8v7fHVBiDX5Lmhbp6oEDB7dUFjANu
GPG 0xF219D5BB3C467E12 - Litecoin Forum
Pages: « 1 [2] 3 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!