Gold collapsing. Bitcoin UP.

[cypherdoc]

a look to the past:

 

[cypherdoc]

fiat folks still interested:

 

[Bagatell]

 

[theZerg]

@cypherdoc that graph didn't really capture it. There was a pop on the 26th from 420 to 460 which I think we jokingly attributed to BU which was released just before christmas.

 

[cypherdoc]

i'd forgotten about this tidbit. major bullish:

Two bitcoin exchanges, itBit and Gemini, have exempted themselves from the regulations by securing trust charters, allowing them to operate as licensed financial institutions in all 50 states.

http://www.financemagnates.com/cryptocurrency/exchange/special-report-winklevoss-twins-help-bitcoin-exchanges-enter-the-big-leagues/
[doublepost=1455734897][/doublepost]

 

[cypherdoc]

[doublepost=1455736377][/doublepost][doublepost=1455737014,1455735820][/doublepost][doublepost=1455737961][/doublepost]

 

[Richy_T]

Antpool is not exclusively mining Classic blocks. Miners should probably be moving to pools that do if they want to support it.

 

[solex]

@Richy_T
I think Antpool will wait for the latest 3-week stalling period (which must be 1/2 over already), before they migrate further from Core.

I am wondering about 21 Co. They are smart people and were voting for 8MB with their scriptsig for a while. But now that they are developing a LN-type solution, are they also going to embrace Classic or follow the BS force-volume-off-chain model?

 

[sickpig]

@Richy_T antpool is very far from mining classic blocks only, in fact they mined just one classic block. It was a test, a warning if you will more than anything else.

 

[theZerg]

extreme thin blocks is really working!!

2016-02-17 21:00:14 Reassembled thin block for 00000000000000000103fbd5825a1ef895303c9791115a25974acebdeb797cb1 (949180 bytes). Message was 16580 bytes, compression ratio 57.248493

(that's the highest compression of a near 1MB block I got in a few hours)

Couple of monster txns in this one:

2016-02-17 21:41:03 Reassembled thin block for 00000000000000000236b1c505e8bc8b8b8991a9d01d5f5a51c01f8504a87f5f (291671 bytes). Message was 3093 bytes, compression ratio 94.300354

 

[sickpig]

more xthinblock goodies (crossposted BU dev section)

sent blocks stats:

# thinblocks sent: 112

Distribution of size(block) / size (thinblock)

Min.    :  1.009
1st Qu. :  7.036
Median  : 35.006
Mean    : 35.018
3rd Qu. : 49.258
Max.    : 154.684

received blocks stats:

# received thinblocks: 174

Distribution of size(block) / size (thinblock)

Min.    :  1.119
1st Qu. :  4.886
Median  : 14.585
Mean    : 20.116
3rd Qu. : 31.442
Max.    :138.694

freq distribution

 

[cypherdoc]

Back in 2011, this was just a dream:

http://mashable.com/2016/02/17/world-cheapest-phone-freedom251/#5kN2rjOufOqp

 

[lunar]

I am wondering about 21 Co. They are smart people and were voting for 8MB with their scriptsig for a while. But now that they are developing a LN-type solution

I had the same thought. Everything they publish points to Bitcoin.core and they've not made any recent statements (almost suspicious by their absence).
If you were in charge of 21.co what would you do? So I assume they are just hedging their bets? If blockstreamCore are successful in their attempt to siphon fees from the miners to their proprietary payment channels at the expense of future mining profits and hence network security, i'd think 21 would want in on that action too.

I suspect they will remain neutral until push comes to shove?
[doublepost=1455746884][/doublepost]@cypherdoc

now that's my kind of deflationary economy.

 

[rocks]

extreme thin blocks is really working!!

2016-02-17 21:00:14 Reassembled thin block for 00000000000000000103fbd5825a1ef895303c9791115a25974acebdeb797cb1 (949180 bytes). Message was 16580 bytes, compression ratio 57.248493

(that's the highest compression of a near 1MB block I got in a few hours)

Couple of monster txns in this one:

2016-02-17 21:41:03 Reassembled thin block for 00000000000000000236b1c505e8bc8b8b8991a9d01d5f5a51c01f8504a87f5f (291671 bytes). Message was 3093 bytes, compression ratio 94.300354

I am wondering what is the advantage for thin blocks over IBLT and why not just implement IBLT first.

Thin blocks work if the receiving node already has all the transactions in their mempool. But if any are missing then the receiver has to make a request for the missing transactions. This slows down propagation since there is a series of events of initial data transfer, processing, new requests, new data transfer and further processing.

IBLT however let's the receiver reassemble missing transactions from the data already sent. This saves network requests which is the main source of delays.

 

[solex]

@rocks
Normally its not about the best idea, its about the best idea that actually gets done.
IBLT is great, and Rusty and Kalle did some prototyping, but their work seems stalled. Blocktorrent is great, but Jonathan has since focussed on Classic.

Kudos to @Peter Tschipper for staying the course and putting in many hours to work out every detail for thin blocks. @theZerg and @sickpig are helping immensely by resolving edge cases and degenerate scenarios.

Thinblocks alone has the potential to allow real-time block propagation to be as efficient at 32MB as standard blocks are at 1MB. @YarkoL may look at phase two with dynamic hash sizes for further improvement. Mempools were more in sync before the 1MB approached and different tx discarding changes were done by Core & XT. We need to get back to mempools being in sync as an ideal.

I was thinking that blocktorrent could supplement thinblocks for efficient delivery of old historical blocks.

IBLT is not needed yet but might be best in the 100MB block size region.
[doublepost=1455749541,1455748875][/doublepost]

If you were in charge of 21.co what would you do? So I assume they are just hedging their bets?

Yes. 21.co could be hedging bets on a block size limited Bitcoin. They also might want off-chain for all their IoT traffic, so will use that for device-to-device payments, but not deliberately forcing normal user traffic off-chain like BS seems to want.

 

[Inca]

Back in 2011, this was just a dream:

http://mashable.com/2016/02/17/world-cheapest-phone-freedom251/#5kN2rjOufOqp

The rise of ubiquitous and ultra cheap web connected smart phones is an irreversible force sweeping the globe.

That single fact will bring in billions of new users to the internet and eventually bitcoin or another cryptocurrency like it will take off like wild fire. I still fervently believe bitcoin simply has to exist a little longer and build up a larger capital / user base and it will become the de facto digital currency for the world.

Exciting times, especially when the vast majority of the world still have never heard of bitcoin at all or even just in passing.

 

[YarkoL]

Thin blocks work if the receiving node already has all the transactions in their mempool. But if any are missing then the receiver has to make a request for the missing transactions. This slows down propagation since there is a series of events of initial data transfer, processing, new requests, new data transfer and further processing.

In practice the requesting of missing tx's is quite rare occurence, due to fast propagation of transactions versus the block interval. Also the relative simplicity of xthins is a big plus.
I admit I was skeptical also at first, but got convinced pretty fast after seeing the stats.

 

[theZerg]

Also IBLT is another (smaller) way to communicate the txns in a block. But if you are missing a txn you still need to get it from somewhere...

 

[Peter R]

I am wondering what is the advantage for thin blocks over IBLT and why not just implement IBLT first.

Thin blocks work if the receiving node already has all the transactions in their mempool. But if any are missing then the receiver has to make a request for the missing transactions. This slows down propagation since there is a series of events of initial data transfer, processing, new requests, new data transfer and further processing.

IBLT however let's the receiver reassemble missing transactions from the data already sent. This saves network requests which is the main source of delays.

Xthin blocks "work" if the receiving node does NOT have all the transactions in its mempool too [1]. When the receiving node makes its get-block request, it attaches a bloom filter that describes the contents of its mempool. The transmitting node then sends the Xthin block + any missing transactions in full as inferred from the bloom filter. This is fast and efficient.

Personally, I think Xthin + your mini-blockchain idea (what I called subchains) will allow us to scale on chain by at least two orders of magnitude. This combination is my preferred solution since Xthin and subchains are both dead simple. Furthermore, this solution does not require mempool homogeneity but naturally incentivizes it instead (nodes with highly-synchronized mempools will receive and transmit blocks faster but the solution works regardless).

[1] Except for false positives which should occur approximately 0.1% of the time.

 

[cypherdoc]