Gold collapsing. Bitcoin UP.

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,998
a look to the past:

 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,998
fiat folks still interested:

 

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
@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

Well-Known Member
Aug 26, 2015
5,257
12,998
  • Like
Reactions: majamalu

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,998
[doublepost=1455736377][/doublepost][doublepost=1455737014,1455735820][/doublepost][doublepost=1455737961][/doublepost]
 

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
Antpool is not exclusively mining Classic blocks. Miners should probably be moving to pools that do if they want to support it.
 

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,694
@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

Active Member
Aug 28, 2015
926
2,541
@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.
 
  • Like
Reactions: bluemoon

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
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
 
Last edited:

sickpig

Active Member
Aug 28, 2015
926
2,541
more xthinblock goodies (crossposted BU dev section)

sent blocks stats:

# thinblocks sent: 112

Distribution of size(block) / size (thinblock)
Code:
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)
Code:
Min.    :  1.119
1st Qu. :  4.886
Median  : 14.585
Mean    : 20.116
3rd Qu. : 31.442
Max.    :138.694
freq distribution

 
Last edited:

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
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

Active Member
Sep 24, 2015
586
2,284
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

Moderator
Staff member
Aug 22, 2015
1,558
4,694
@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

Moderator
Staff member
Aug 28, 2015
517
1,679
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

Active Member
Dec 18, 2015
176
258
Tuusula
yarkol.github.io
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

Moderator
Staff member
Aug 28, 2015
1,012
2,327
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...
 
  • Like
Reactions: bluemoon

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
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.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,998
 
  • Like
Reactions: bluemoon