Gold collapsing. Bitcoin UP.

[adamstgbit]

but there is not much conpect of "power nodes" or

Sometimes we have all tx other times 800 out of 3k are missing.

miners should include TX that are likely in everyone's mem-pool
or more to the point exclude the TX they think is likely others dont have.
a simply rule like " if the TX is only 10sec old don't include it "
it would be polite.
wouldn't have to be a hard rule and they could code in some exceptions like if the TX has HighFees.

if a node is not well connected its likely its mem pool will be far out of sync and missing 800 out of 3K
maybe these aren't miners maybe these are home users; these nodes simply do not care about getting a block as fast as possible. my guess is for the miners this improves their block propagation time by ~100X more often than not because they are well connected.

we should also have a way to distinguish a miner full node from a home user full node. that way some common sense rules could be applied to home users like "wait 1min after a block is announced to start trying to retrieve it", to not interfere with the miner nodes propagating the block as fast as possible amongst themselves.

i do believe there is a shit tone of optimizations that can be done. I flipped out when i heard peter todd say " bitcoin simply can't scale, we should just accept that and use a second layer now"

 

[solex]

@adamstgbit
This is one of the perverse effects of the 1MB constraining volumes. The more the blocks are choked up and confirmation times become unreliable, then the more that major Bitcoin businesses will find it necessary to approach miners directly for bulk tx handing. BTCC already offer this "service". So these business->miner direct flows are not seen by the rest of the network and seriously degrade Xthin, and even tech like IBLT is also degraded (because only a subset of a block can be hitherto unseen tx, or IBLT decoding fails).

 

[theZerg]

If fee pressure becomes great, a miner can fill header-only mined blocks with privately submitted txns... (removed section from my 1-txn paper)

 

[Justus Ranvier]

So these business->miner direct flows are not seen by the rest of the network and seriously degrade Xthin, and even tech like IBLT is also degraded (because only a subset of a block can be hitherto unseen tx, or IBLT decoding fails).

If the miners broadcast those transactions themselves as soon as they include them in a block, then they could enjoy faster propagation since those transactions are already validated and in the mempools of other nodes.

On the other hand, some other miner might include them and get the fee instead.

This seems like a self-regulating situation. Slower propagation times don't really harm nodes - they only harm the miners. Miners will only do things which cost them orphan risk if they are adequately compensated for it.

 

[adamstgbit]

@solex

good point. overflowing blocks is not good for so many reason.

altho again miner could be "polite" and broadcast all the TX they will want included in blocks as a batch ASAP. do they care if it there own block? maybe they do not want to pay a fee? fine, still, nothing is preventing them from being "polite" and broadcasting these 0 fee TXs they intent to include themselves as a batch.

i bet it wouldn't be hard to get miners to be polite...

 

[theZerg]

@adamstgbit yes, and that is weak blocks/subchains

 

[adamstgbit]

i would go further and define some reasons to orphan blocks

if miners being "impolite" and are do things that are technically legal but hurt other miners...

including an absurd TX that takes >1min to validate, "impolite", BOOM orphaned.
including a block full of TX other miners never heard about, "impolite", BOOM orphaned.

these rules might be EASY to get passed they can be softforked in

i bet miners would LOVE more reasons to orphan other miners blocks, they just need to coordinate as to what the rules are, and when the new rules come into effect.

as long as you do a 75% of miners agree to this softfork + 90% everyone will be happy to help define a few common sense rules to orphan blocks.
[doublepost=1458267917][/doublepost]@theZerg

Cool, is this again another update coded by BU?

 

[theZerg]

we haven't started on weak blocks yet. Miners need to make them and so far we have no miners... although I suppose providing this might encourage some of them over.

BU does/will follow the philosophy that miners should orphan certain blocks. I formalized the idea in my paper www.bitcoinunlimited.info/1txn. Basically, if the time to validate a block is > the expected time for the rest of the network to mine and validate a sibling then the "rational miner" chooses to mine a sibling. That way the miner is able to move from mining empty blocks to fee paying blocks sooner. Right now though, this is not implemented in BU in a fancy way -- we just implemented an "excessive block" size. If a block is > that amount, BU attempts to mine a sibling until other miners mine on top of the "excessive block", which shows that the "network" as a whole believes that that block size is ok.

 

[rocks]

@adamstgbit
This is one of the perverse effects of the 1MB constraining volumes. The more the blocks are choked up and confirmation times become unreliable, then the more that major Bitcoin businesses will find it necessary to approach miners directly for bulk tx handing. BTCC already offer this "service". So these business->miner direct flows are not seen by the rest of the network and seriously degrade Xthin, and even tech like IBLT is also degraded (because only a subset of a block can be hitherto unseen tx, or IBLT decoding fails).

Another way to say this is as demand for transactions reaches the supply limit, then instead of demand continuing to grow beyond that supply limit, demand simply stops growing to order to stay in balance with the artificial supply.

In other words, the market simply stops using Bitcoin as needed in order to keep demand aligned with supply.

Greg and team will then say "see we were right, we didn't need to raise the limit", but what will be missed is the massive unutilized potential of the block chain that exists by keeping the limit.

 

[theZerg]

you guys might appreciate this: 4 hops of an xthin block in .25 seconds. Each hop validates difficulty and then forwards.

(San Jose)
2016-03-18 02:40:38.092887 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to 169.55.99.89:41273.

( Washington DC)
2016-03-18 02:40:38.134474 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 169.45.95.196:8333 (5). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.134574 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to 159.8.161.36:8333.

(London)
2016-03-18 02:40:38.201305 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 169.55.99.89:35863 (5). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.201460 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to 159.122.78.214.

(Frankfurt)
2016-03-18 02:40:38.241775 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 159.8.161.36:45173 (19). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.241916 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to x.y.z.q:52623.

(Boston)
2016-03-18 02:40:38.345334 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 159.122.78.214 (38). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.416495 Reassembled thin block for 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 (522648 bytes). Message was 6844 bytes, compression ratio 76.37

 

[solex]

Greg and team will then say "see we were right, we didn't need to raise the limit", but what will be missed is the massive unutilized potential of the block chain that exists by keeping the limit.

Anyone who needs a waking nightmare can just imagine ETH (or another) with $7bn market cap, and BTC with $1bn, and 1MB blocks not even full anymore, and Greg's smiling face saying "Yeah. I was always right. Bitcoin was broken from the start."
[doublepost=1458269836][/doublepost]@theZerg Wow. That's amazing!

 

[cypherdoc]

Wait, what??

What's the purpose of Liquid over say a voting pool if it's going to be like this?

it should be very clear that when push came to shove, /u/nullc has chosen Blockstream over Bitcoin.
[doublepost=1458270957,1458270038][/doublepost]

you guys might appreciate this: 4 hops of an xthin block in .25 seconds. Each hop validates difficulty and then forwards.

(San Jose)
2016-03-18 02:40:38.092887 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to 169.55.99.89:41273.

( Washington DC)
2016-03-18 02:40:38.134474 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 169.45.95.196:8333 (5). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.134574 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to 159.8.161.36:8333.

(London)
2016-03-18 02:40:38.201305 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 169.55.99.89:35863 (5). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.201460 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to 159.122.78.214.

(Frankfurt)
2016-03-18 02:40:38.241775 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 159.8.161.36:45173 (19). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.241916 Sending expedited block 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 to x.y.z.q:52623.

(Boston)
2016-03-18 02:40:38.345334 Received new expedited thinblock 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 from peer 159.122.78.214 (38). Size 6844 bytes. (status 0,0x0)
2016-03-18 02:40:38.416495 Reassembled thin block for 000000000000000003b276adfbb4a70b7895283636fc0cff7db21a80e6f9bc42 (522648 bytes). Message was 6844 bytes, compression ratio 76.37

San Jose to Wash DC=2845

washington dc to london=3662

london to frankfurt =474.1

frankfurt to boston distance=3662

total= 10643.1mi

The circumference of Earth at the equator is about 24,902 miles

43% around the Earth in 0.25 sec. Not bad.

 

[Peter R]

That's only 23% of the speed of light. Blockstream's relay network is at least 10 times faster

But seriously, that is really fast. Is this representative of real world performance?

 

[rocks]

Anyone who needs a waking nightmare can just imagine ETH (or another) with $7bn market cap, and BTC with $1bn, and 1MB blocks not even full anymore, and Greg's smiling face saying "Yeah. I was always right. Bitcoin was broken from the start."

The real death knell will be when bitcoin only firms such as coinbase, changetip or bitpay start to offer their services for other alts.

The only thing propping up bitcoins price at these levels is the massive amount of "bitcoin only" infrastructure out there.

Infrastructure that is currently being denied service by bitcoin.

Infrastructure that already is designed to work with every altcoin's api, not LN's api.

 

[theZerg]

That's only 23% of the speed of light. Blockstream's relay network is at least 10 times faster

But seriously, that is really fast. Is this representative of real world performance?

Hmm i got 5%. 10000/186000. Anyway These numbers came from nodes running normally on the bitcoin network. NTP is used for time sync which could be a source of error larger than the measurements (IDK). However if that were true you'd expect to see some inverse times. It could also be that the nodes are not located where advertised. But on the other hand the signal IS light for almost all of its journey.

 

[solex]

Hmm i got 5%. 10000/186000.

for .25 sec don't forget
That IS fast, wonder how this looks with one of our CN nodes in the sequence?

 

[yrral86]

Hmm i got 5%. 10000/186000. Anyway These numbers came from nodes running normally on the bitcoin network. NTP is used for time sync which could be a source of error larger than the measurements (IDK). However if that were true you'd expect to see some inverse times. It could also be that the nodes are not located where advertised. But on the other hand the signal IS light for almost all of its journey.

When properly configured, NTP error should be tiny. NTP can also give you bounds on your current error.

 

[theZerg]

for .25 sec don't forget
That IS fast, wonder how this looks with one of our CN nodes in the sequence?

Looks like about a half second to cross from ShangHai to San Jose...

2016-03-18 12:21:16.385998 Sending expedited block 000000000000000003b523745ea417a232957bc73755b25871622f568678162b to 169.55.99.89:37507.

2016-03-18 12:21:17.024429 Received new expedited thinblock 000000000000000003b523745ea417a232957bc73755b25871622f568678162b from peer 120.25.194.218 (1472). Size 19188 bytes. (status 0,0x0)
2016-03-18 12:21:17.024536 Sending expedited block 000000000000000003b523745ea417a232957bc73755b25871622f568678162b to 159.8.161.36:8333.

2016-03-18 12:21:17.134204 Received new expedited thinblock 000000000000000003b523745ea417a232957bc73755b25871622f568678162b from peer 169.55.99.89:35863 (5). Size 19188 bytes. (status 0,0x0)
2016-03-18 12:21:17.134307 Sending expedited block 000000000000000003b523745ea417a232957bc73755b25871622f568678162b to 159.122.78.214.

2016-03-18 12:21:17.190236 Received new expedited thinblock 000000000000000003b523745ea417a232957bc73755b25871622f568678162b from peer 159.8.161.36:45173 (19). Size 19188 bytes. (status 0,0x0)
2016-03-18 12:21:17.190655 Sending expedited block 000000000000000003b523745ea417a232957bc73755b25871622f568678162b to a.b.c.d:52623.

2016-03-18 12:21:17.359390 Received new expedited thinblock 000000000000000003b523745ea417a232957bc73755b25871622f568678162b from peer 159.122.78.214 (38). Size 19188 bytes. (status 0,0x0)




2016-03-18 12:25:12.644083 Sending expedited block 0000000000000000021a1874f48b244f5d3f60e02800de50598fce29291f466c to 169.55.99.89:37507.

2016-03-18 12:25:12.966685 Reassembled thin block for 0000000000000000021a1874f48b244f5d3f60e02800de50598fce29291f466c (989194 bytes). Message was 10444 bytes, compression ratio 94.71
2016-03-18 12:25:12.966761 thin block stats: 59 thin blocks have saved 32.80MB of bandwidth

2016-03-18 12:25:12.921668 Received new expedited thinblock 0000000000000000021a1874f48b244f5d3f60e02800de50598fce29291f466c from peer 169.55.99.89:35863 (5). Size 10444 bytes. (status 0,0x0)
2016-03-18 12:25:12.921837 Sending expedited block 0000000000000000021a1874f48b244f5d3f60e02800de50598fce29291f466c to 159.122.78.214.


2016-03-18 12:25:12.979353 Received new expedited thinblock 0000000000000000021a1874f48b244f5d3f60e02800de50598fce29291f466c from peer 159.8.161.36:45173 (19). Size 10444 bytes. (status 0,0x0)
2016-03-18 12:25:12.979611 Sending expedited block 0000000000000000021a1874f48b244f5d3f60e02800de50598fce29291f466c to a.b.c.d:52623.

2016-03-18 12:25:13.033470 Received new expedited thinblock 0000000000000000021a1874f48b244f5d3f60e02800de50598fce29291f466c from peer 159.122.78.214 (38). Size 10444 bytes. (status 0,0x0)

 

[Christoph Bergmann]

I'm currently reloading my blocksize (after I lost it through experiments with pruning).

Today I found out how to give bitcoin-qt more cpu-priority. I also increased caches, the number of verification threads and made hdd writing faster.

Now it's faster, but it still needs a lot of time. At minimum 20 hours.

Bottleneck seems to be CPU validating transactions. Maybe as an idea for unlimited - is this really needed? Does the client really needs to validate every microtransaction since 2009, that carry so much proof of work?

Can't we e. G. do random probes, e. G. every 100th signature? Does the client need to get index-informations from other nodes to do so?

Just wondering. The time to set up a nodes seems for me the biggest problem in raising the blocksize. If we had now 4 mb blocks for 12 month, I think I would need one week more to validate everything. In the long run, if we don't change it, you'd need a month of cpu work to set up a node ...

 

[sickpig]

@Christoph Bergmann

I made an IBD (initial block download) 10 days ago for a BU 0.12.0 node on a vps with 6GB RAM, 2 Core (Xeon), no SSD.

The only parameter I tweaked was dbcache=3000.

It took ~12.5 hs for the node to download and validate the entire blockchain.

fwiw I think there's significant room for improvements if you're ok relaxing your level of trustless expectation.