Η πλακα ειναι δε χρειαζεται καν institutional money  http://www.businessinsider.com/countries-with-most-millionaires-2017-4"It remains a marker of immense wealth, but the club is growing ever more crowded, with nearly 33 million people across the globe now laying claim to fortunes in excess of $1 million, according to estimates by Credit Suisse in its most recent Global Wealth Databook."...με 33εκ εκατομμυριουχους, ουτε μισο bitcoin εκαστος δε παιρνει  Ακομα και αν οι μισοι μονο ηθελαν 1 bitcoin, και αυτο δε προκειται να συμβει... To scarcity απλα ειναι τεραστιο |
|
|
|
I may try this again in the future with a packed version on ymm/zmm registers. In a packed manner it might even trounce the 5x52 field. We'll see how it goes...
I did fe_mul_inner of 10x26 on avx-512 to check it out. Machine used was a google cloud skylake xeon @ 2ghz. Baseline performance for fe_mul in ./bench_internal is around ~30us for the asm shipped (5x52) ~27us with no asm used (5x52) and the compiler (gcc) issuing MULXs - which is more efficient than the embedded asm. (That's true only for fe_mul and fe_sqr, the scalar asm is still better.) ~51us for the 10x26 field written in C ~49us for the 10x26 field written in C but using SSE2 to pack the 100 muls into 50 muls. ~38us for the 10x26 field written in C except if I do all the multiplications in an AVX2 array, packed by 4. ~45us for the 10x26 field written in ASM, using all AVX-512. ~38us for the 10x26 field written in ASM, using AVX-512 for muls+adds and then doing the rest in the scalar part ( this is what is posted below) ~29us for the 10x26 field written in ASM, except a few lines in c (which don't change much - as 90%+ is in asm), but then doing a -fprofile-generate and -fprofile-use, which somehow gets it +35% faster  There's something definitely holding back AVX-512 from going faster than 27us which is the mulx standard, but I'll have to see how it goes in other architectures and non-VM machines also. There are 3 factors: -Whether VM performance and VM use in overbooked machines tends to create abnormal performance scenarios. I've seen instructions in the profiler stalling for 10-15% of the whole function time and I'm like wtf is this -Scalar code gets a CPU boost (2.1-2.7 GHz instead of baseline 2GHz) and AVX-512 code gets an underclock (1.8GHz). From 1.8GHz (AVX-512) to 2.7GHz (scalar code running in integer unit with turbo) that's a +50% clock difference. That kind of perf hit wasn't part of the plan when thinking about packing stuff together  -The presence of 1 or 2 AVX 512 units per core (??). From what I've read there are differences between i7/i9, xeon gold/platinum etc etc.. cat /proc/cpuinfo is a bit elusive). The following code (asm 10x26) is in the 38us range in the VM - which is slower than the ASM 5x52 (30us) or gcc-mulx version 5x52 (27us). I've left a lot of comments intact instead of clearing them out - as they were things which I was phasing out by replacing them with asm. I initially started with an array (aaa[10][10]) to store the results and then gradually replaced mem references to the registers themselves, then did the additions from the registers and eventually stored all the results in another array. It's not very clean written nor was it supposed to be as I haven't found the performance I expected. In total, 100 muls, 81 additions, loading everything from RAM, storing the results and exporting C + D initial values were managed in something like ...75 instructions (!), of which memory operations were very few. And the muls used are 20, instead of 13 (optimum) but the 13 scenario involves more packing and unpacking, so I left it as it is - seeing in the profiler that muls have low cost (2 issued per cycle). VALIGNs were slow, but they were better than writing everything on to memory and then loading from the right addresses. The 2 addition vectors were interleaved to do the additions in parallel (again it can take 2 adds per cycle). Readability suffers a bit on this part as a consequence. Interleaving can also be done with broadcasts and alignments but I left it as is. The code needs clobbering for xmm16-xmm31, but it played ok with gcc. Clang crashes (it already uses xmm16-xmm31 elsewhere and doesn't expect them to be rewritten). Clobbering requires special treatment for these, with IF definitions that indicate avx-512 presence in the preprocessor. I'm curious to see what it'll do in, say, a i9 running on a desktop, or some future avx512 machine which doesn't underclock avx-512 action / overclocks scalar action for a 30-50% diff. Anyway, I guess I had too much time on my hands  (I think I've written around 130 variations of this by now trying to find the elusive avx2 and avx512 performance, lol). SECP256K1_INLINE static void secp256k1_fe_mul_inner(uint32_t *r, const uint32_t *a, const uint32_t * SECP256K1_RESTRICT b) {
/* uint64_t c, d;*/
/* uint64_t u0;*/
/* uint32_t M, R0;*/
/* uint64_t aaa[10][10] __attribute__ ((aligned (64))); */ /*the initial "pass" was every mul result getting stored in the 10x10 array. It was replaced with the addition result array - keeping everything in registers*/
uint64_t aaa[18] __attribute__ ((aligned (64)));
/* int ii;*/
/* const uint32_t M = 0x3FFFFFFUL, R0 = 0x3D10UL, R1 = 0x400UL;*/
__asm__ (
"VPSHUFD $0b00010000, 32(%1), %%XMM5\n" /*b8 to b9 loaded*/
"VPMOVZXDQ 0(%1), %%ZMM1\n" /*b0 to b7 expanded to quadwords and placed accordingly*/
"VPBROADCASTD 0(%0), %%ZMM0\n" /*a0 loaded into zmm*/
"VPBROADCASTD 4(%0), %%ZMM2\n" /*a1 loaded into zmm*/
"VPBROADCASTD 8(%0), %%ZMM8\n" /*a2 loaded into zmm*/
"VPBROADCASTD 12(%0), %%ZMM9\n" /*a3 loaded into zmm*/
"VPBROADCASTD 16(%0), %%ZMM10\n" /*a4 loaded into zmm*/
"VPBROADCASTD 20(%0), %%ZMM20\n" /*a5 loaded into zmm*/
"VPBROADCASTD 24(%0), %%ZMM22\n" /*a6 loaded into zmm*/
"VPBROADCASTD 28(%0), %%ZMM28\n" /*a7 loaded into zmm*/
"VPBROADCASTD 32(%0), %%ZMM29\n" /*a8 loaded into zmm*/
"VPBROADCASTD 36(%0), %%ZMM30\n" /*a9 loaded into zmm*/
"VPMULUDQ %%ZMM0, %%ZMM1, %%ZMM3\n" /*a[0][0] to a[0][7]*/
"VPMULUDQ %%ZMM2, %%ZMM1, %%ZMM4\n" /*a[1][0] to a[1][7]*/
"VPMULUDQ %%ZMM8, %%ZMM1, %%ZMM11\n" /*a[2][0] to a[2][7]*/
"VPMULUDQ %%ZMM9, %%ZMM1, %%ZMM13\n" /*a[3][0] to a[3][7]*/
"VPMULUDQ %%ZMM10, %%ZMM1, %%ZMM15\n" /*a[4][0] to a[4][7]*/
"VPMULUDQ %%XMM0, %%XMM5, %%XMM6\n" /*a[0][8] to a[0][9]*/
"VPMULUDQ %%XMM2, %%XMM5, %%XMM7\n" /*a[1][8] to a[1][9]*/
"VPMULUDQ %%XMM8, %%XMM5, %%XMM12\n" /*a[2][8] to a[2][9]*/
"VPMULUDQ %%XMM9, %%XMM5, %%XMM14\n" /*a[3][8] to a[3][9]*/
"VPMULUDQ %%XMM10, %%XMM5, %%XMM16\n" /*a[4][8] to a[4][9]*/
"VPMULUDQ %%XMM20, %%XMM5, %%XMM24\n" /*a[5][8] to a[5][9]*/
"VPMULUDQ %%XMM22, %%XMM5, %%XMM25\n" /*a[6][8] to a[6][9]*/
"VPMULUDQ %%XMM28, %%XMM5, %%XMM26\n" /*a[7][8] to a[7][9]*/
"VPMULUDQ %%XMM29, %%XMM5, %%XMM27\n" /*a[8][8] to a[8][9]*/
"VPMULUDQ %%XMM30, %%XMM5, %%XMM31\n" /*a[9][8] to a[9][9]*/
"VPMULUDQ %%ZMM20, %%ZMM1, %%ZMM17\n" /*a[5][0] to a[5][7]*/
"VPMULUDQ %%ZMM22, %%ZMM1, %%ZMM18\n" /*a[6][0] to a[6][7]*/
"VPMULUDQ %%ZMM28, %%ZMM1, %%ZMM19\n" /*a[7][0] to a[7][7]*/
"VPMULUDQ %%ZMM29, %%ZMM1, %%ZMM21\n" /*a[8][0] to a[8][7]*/
"VPMULUDQ %%ZMM30, %%ZMM1, %%ZMM23\n" /*a[9][0] to a[9][7]*/
/* There are two main addition vector sequences.
The load is vertical (eg: Vector 1 loads aaa90 to aaa97, representing a[9]*b[0] to a[9]*b[7]) and the addition horizontal to the right. The horizontal adding requires
zeroes in the register for the elements that require no further adding, or a k mask in the register to limit the fields added. In this case we're pulling zeroes from zmm28).
90+81 72 63 54 45 36 27 18 9 (result stored in aaa[9][0] if using a mem matrix)
91+82 73 64 55 46 37 28 19 (result stored in aaa[9][1] if using a mem matrix)
92+83 74 65 56 47 38 29 (result stored in aaa[9][2] if using a mem matrix)
93+84 75 66 57 48 39 (result stored in aaa[9][3] if using a mem matrix)
94+85 76 67 58 49 (result stored in aaa[9][4] if using a mem matrix)
95+86 77 68 59 (result stored in aaa[9][5] if using a mem matrix)
96+87 78 69 (result stored in aaa[9][6] if using a mem matrix)
97+88 79 (result stored in aaa[9][7] if using a mem matrix)
Second sequence is of this form:
1+10 (result stored in aaa[0][1] if using a mem matrix)
2+11 20 (result stored in aaa[0][2] if using a mem matrix)
3+12 21 30 (result stored in aaa[0][3] if using a mem matrix)
4+13 22 31 40 (result stored in aaa[0][4] if using a mem matrix)
5+14 23 32 41 50 (result stored in aaa[0][5] if using a mem matrix)
6+15 24 33 42 51 60 (result stored in aaa[0][6] if using a mem matrix)
7+16 25 34 43 52 61 70 (result stored in aaa[0][7] if using a mem matrix)
8+17 26 35 44 53 62 71 80 (result stored in aaa[0][8] if using a mem matrix)
Again adding is to the right. The later results overwrite the 1st vertical vector (if they are non-zero-adds) - which keeps all the results.
The only result which is left out of the vector additions is the addition of 89+98 which has to be done unpacked.
00 and 99 wiil be used directly and aren't added.
In all there are
1) 44 adds in the first vector done as 9 vector adds.
2) 36 adds in the second vector done as 8 vector adds.
Total 80 additions with a packing rate of 4.7x. Plus an unpacked one (89+98), we end up with 18 adds for 81 additions (4.5x packing rate).*/
"VPSRLDQ $8, %%XMM27, %%XMM8\n"
"VPXORQ %%YMM28, %%YMM28, %%YMM28\n" /*zero in order to pull zeroes in the empty fields of the vector*/
"VALIGNQ $1, %%ZMM3, %%ZMM6, %%ZMM30\n" /*1 to 8*/
"VPADDQ %%XMM31, %%XMM8, %%XMM8\n" /*a[9][8] to a[9][9] with 98 being 98+89*/
"VALIGNQ $7, %%ZMM28, %%ZMM11, %%ZMM1\n" /*20 to 26 - want to add 20-21-22-23-24-25-26 from second element onwards*/
"VMOVDQA64 %%XMM8, 128(%2)\n" /*a[9][8] to a[9][9] with 98 being 98+89*/
"VALIGNQ $6, %%ZMM28, %%ZMM13, %%ZMM2\n" /*30 to 35 - want to add 30-31-32-33-34-35 from third element onwards*/
"VALIGNQ $5, %%ZMM28, %%ZMM15, %%ZMM0\n" /*40 to 44 - want to add 40-41-42-43-44 from fourth element onwards*/
"VALIGNQ $4, %%ZMM28, %%ZMM17, %%ZMM8\n" /*50 to 53 - want to add 50-51-52-53 from fifth element onwards*/
"VALIGNQ $3, %%ZMM28, %%ZMM18, %%ZMM10\n" /*60 to 62 - want to add 60-61-62 from sixth element onwards*/
"VALIGNQ $2, %%ZMM28, %%ZMM19, %%ZMM20\n" /*70 to 71 - want to add 70-71 from seventh element onwards*/
"VALIGNQ $1, %%ZMM28, %%ZMM21, %%ZMM22\n" /*80 - want to add 80 only on the eighth element*/
"VALIGNQ $1, %%ZMM21, %%ZMM27, %%ZMM27\n" /*81 to 88*/
"VALIGNQ $2, %%ZMM19, %%ZMM26, %%ZMM26\n" /*72 to 79*/
"VALIGNQ $3, %%ZMM18, %%ZMM25, %%ZMM25\n" /*63 to 69*/
"VALIGNQ $4, %%ZMM17, %%ZMM24, %%ZMM29\n" /*54 to 59*/
"VALIGNQ $5, %%ZMM15, %%ZMM16, %%ZMM16\n" /*45 to 49*/
"VALIGNQ $6, %%ZMM13, %%ZMM14, %%ZMM14\n" /*36 to 39*/
"VALIGNQ $7, %%ZMM11, %%ZMM12, %%ZMM12\n" /*27 to 29*/
/*18 and 19 left as is on zmm7*/
/*"VALIGNQ $1, %%ZMM6, %%ZMM6, %%ZMM24\n" */ /*9*/
"VPSRLDQ $8, %%YMM6, %%YMM24\n" /*9*/
"VPADDQ %%ZMM27, %%ZMM23, %%ZMM5\n" /*add on them aaa81 to aaa88*/
"VPADDQ %%ZMM26, %%ZMM25, %%ZMM25\n" /*add on them aaa72 to aaa79*/
"VPADDQ %%ZMM29, %%ZMM16, %%ZMM16\n" /*add on them aaa54 to aaa59*/
"VPADDQ %%ZMM25, %%ZMM5, %%ZMM5\n" /*add on them aaa63 to aaa69*/
"VPADDQ %%ZMM4, %%ZMM30, %%ZMM30\n" /*add on them aaa10 to aaa17*/
"VPADDQ %%ZMM16, %%ZMM5, %%ZMM5\n" /*add on them aaa45 to aaa49*/
"VPADDQ %%ZMM12, %%ZMM7, %%ZMM7\n" /*add on them aaa27 to aaa29*/
"VPADDQ %%ZMM1, %%ZMM30, %%ZMM30\n" /*add on them aaa20 to aaa26*/
"VPADDQ %%ZMM14, %%ZMM5, %%ZMM5\n" /*add on them aaa36 to aaa39*/
"VPADDQ %%ZMM2, %%ZMM30, %%ZMM30\n" /*add on them aaa30 to aaa35*/
"VPADDQ %%ZMM7, %%ZMM5, %%ZMM5\n" /*add on them aaa18 to aaa19*/
"VPADDQ %%ZMM0, %%ZMM8, %%ZMM8\n" /*add on them aaa40 to aaa44*/
"VPADDQ %%ZMM10, %%ZMM20, %%ZMM20\n" /*add on them aaa60 to aaa62*/
"VPADDQ %%ZMM24, %%ZMM5, %%ZMM5\n" /*add on them aaa9*/
"VPADDQ %%ZMM8, %%ZMM30, %%ZMM30\n" /*add on them aaa50 to aaa53*/
"VMOVDQA64 %%ZMM5, 64(%2)\n" /*aaa90 - aaa97 on aaa[8] to aaa[15] */
"VPADDQ %%ZMM22, %%ZMM20, %%ZMM20\n" /*add 22 on 20 instead, and then on 30, for less serial action */
"VPADDQ %%ZMM20, %%ZMM30, %%ZMM30\n"
"VMOVDQA64 %%ZMM30, 0(%2)\n"
"movq %%xmm5, %%rdx\n" /*d = (uint64_t)aaa[9][0]*/
"movq %%xmm3, %%rcx\n" /* c = (uint64_t)aaa[0][0]*/
"mov $0x3FFFFFF, %%r11d\n" /*M*/
"movq %%rdx, %%r9\n"
"xor %%ebx, %%ebx\n"
"shrq $26, %%rdx\n"
"and %%r11d, %%r9d\n" /*t9=d&M*/
"addq 72(%2), %%rdx\n" /* d=d+(uint64_t)aaa[9]; */
"loop_top_%=:\n"
"mov %%r11d, %%r10d\n" /*M*/
"add $4, %%ebx\n" /*used for loop counter and memory addresses as a multiplier*/
"and %%edx, %%r10d\n" /* u0 = d & M; */
"mov %%r10d, %%r8d\n" /* u0 = d & M; */
"imul $0x3D10, %%r10\n" /* u0 * R0*/
"mov %%r11d, %%eax\n" /*M*/
"shrq $26, %%rdx\n" /* d >>= 26 */
"shlq $10, %%r8\n" /* u0 * R1*/
"addq %%r10, %%rcx\n" /* c += u0 * R0; */
"and %%ecx, %%eax\n" /* c & M; */
"shrq $26, %%rcx\n" /*c >>= 26*/
"mov %%eax, -4(%3, %%rbx, 1)\n" /* r[ii] = c & M; */
"addq %%r8, %%rcx\n" /* c += u0 * R1 */
"cmp $36, %%ebx\n" /*from r[0] to [r7] there are some extra additions, while in r[8] there isn't - so when it reaches r[8] it skips them and ends*/
"je loop_end_%=\n"
"addq 72(%2, %%rbx, 2), %%rdx\n" /* d +=(uint64_t)aaa[1][ii+2]; */
"addq -8(%2, %%rbx, 2), %%rcx\n" /* c += (uint64_t)aaa[0][ii]; */
"jmp loop_top_%=\n"
"loop_end_%=:\n"
"imulq $0x3D10, %%rdx, %%r8\n"
"addq %%r9, %%rcx\n"
"mov $0x3FFFFF, %%r10d\n"
"addq %%r8, %%rcx\n" /* c += d * R0 + r[9];*/
"andq %%rcx, %%r10\n"
"shlq $14, %%rdx\n"
"mov %%r10d, 36(%3)\n" /* r[9] = c & (M >> 4); */
"shrq $22, %%rcx\n"
"addq %%rdx, %%rcx\n" /* c >>= 22; c += d * (R1 << 4); */
"imulq $0x3D1, %%rcx, %%rdx\n"
"mov 0(%3), %%r10d\n"
"mov %%r11d, %%r8d\n"
"addq %%r10, %%rdx\n" /* d = c * (R0 >> 4) + r[0];*/
"shlq $6, %%rcx\n"
"andq %%rdx, %%r8\n"
"mov 4(%3), %%r10d\n"
"mov %%r8d, 0(%3)\n" /* r[0] = d & M; */
"shrq $26, %%rdx\n" /*d >>= 26;*/
"addq %%r10, %%rcx\n"
"addq %%rcx, %%rdx\n" /* d += c * (R1 >> 4) + r[1];*/
"and %%edx, %%r11d\n"
"mov %%r11d, 4(%3)\n" /* r[1] = d & M;*/
"shrq $26, %%rdx\n" /* d >>= 26;*/
"add %%edx, 8(%3)\n" /* r[2] += d;*/
:
: "q"(a), "q"(b), "q"(aaa), "q"(r)
: "memory", "%rax", "%rbx", "%rcx", "%rdx", "%r8", "%r9", "%r10", "%r11","%xmm0", "%xmm1", "%xmm2", "%xmm3", "%xmm4", "%xmm5", "%xmm6", "%xmm7", "%xmm8", "%xmm9", "%xmm10", "%xmm11", "%xmm12", "%xmm13", "%xmm14", "%xmm15"
);
/* d = (uint64_t)aaa[0][9]*/
/* + (uint64_t)aaa[1][8]*/
/* + (uint64_t)aaa[2][7]*/
/* + (uint64_t)aaa[3][6]*/
/* + (uint64_t)aaa[4][5] */
/* + (uint64_t)aaa[5][4]*/
/* + (uint64_t)aaa[6][3]*/
/* + (uint64_t)aaa[7][2]*/
/* + (uint64_t)aaa[8][1]*/
/* + (uint64_t)aaa[9][0];*/
/* r[9] = d & M; */ /*d >>= 26; */
/* c = (uint64_t)aaa[0][0];*/
/* d += */ /*(uint64_t)aaa[1][9]*/
/* + (uint64_t)aaa[2][8]*/
/* + (uint64_t)aaa[3][7]*/
/* + (uint64_t)aaa[4][6] */
/* + (uint64_t)aaa[5][5]*/
/* + (uint64_t)aaa[6][4]*/
/* + (uint64_t)aaa[7][3]*/
/* + (uint64_t)aaa[8][2]*/
/* + */ /* (uint64_t)aaa[9]; */ /*aaa[9][1]=>aaa[1][1]=>aaa[9]*/
/* for( ii = 0; ii < 8; ii = ii + 1 )
{
u0 = d & M; d >>= 26; c += u0 * R0;
r[ii] = c & M; c >>= 26; c += u0 * R1;
c += (uint64_t)aaa[0][ii];
d +=(uint64_t)aaa[1][ii+2];
} */
/* u0 = d & M; d >>= 26; c += u0 * R0;
r[8] = c & M; c >>= 26; c += u0 * R1;*/
/* c += d * R0 + r[9];*/
/* r[9] = c & (M >> 4); c >>= 22; c += d * (R1 << 4); */
/* d = c * (R0 >> 4) + r[0];*/
/* r[0] = d & M; d >>= 26; */
/* d += c * (R1 >> 4) + r[1];*/
/* r[1] = d & M;*/ /*d >>= 26;*/
/* r[2] += d;*/
}
|
|
|
|
The European/Akhenashi jews have the highesr IQ of all ethnic groups in the world (app. 115).
The hypothesis is that they went through a evolutionary bottleneck during WW2, where only the very smartest survived.
<humor> There is another "hypothesis" that they just bribed the guy doing the IQ survey... They are jews. That's what they do </humor> |
|
|
|
I wish Satoshi would just suddenly buy an island and come out of hiding.
He could be the cool consultant to unite things.
I remember when Wright was said to be Satoshi and they sent ...the SWAT team to his house. Yeah, Satoshi better stay undercover. |
|
|
|
forks after forks,hacks after hacks , still ethereum is second most value in cryptoworld. thats not an easy feat to achieve.
The more centralized a coin is, the more it can draw institutional investors who feel safer compared to more anarchic, or chaotic, decentralized alternatives. However cryptocurrencies weren't invented (at least originally) with the intention to rival the investment in bank stocks and the likes. |
|
|
|
I expected this thread to be a lot busier, people more excited etc. During past rallies & ATH's etc it's been a lot more dramatic. Maybe that shows us that whilst $3000 is great we have much more scope for excitement at much higher prices.
Whether 2.8-2.9 or 3k, it doesn't matter. We've been already accustomed to these price levels. We need much bigger numbers to get excited |
|
|
|
@cashodler brings up some valid points. Coinbase changing their stance on BCC was important. It is still early days. John Stuart Millibit wrote an article that laid out a scenario where BCC could take over from BTC in a matter of days, possibly in November if the 2 MB hard fork in SegWit2X is not honoured. Segwit = ~3.5mb Segwit 2X = 7mb+ BCC = 8mb What will the BTC2X fork selling point be? "We have 7mb" vs BCC "we have 8 mb" ??  Yeah right. |
|
|
|
He was right, though. The fact that BCH has fast difficulty adjustment and bitcoin doesn't while the Chinese control most of the hash power is gonna be mega-problems for BTC.
A fast difficulty adjustment works both ways. Say a lot of SHA256 power goes into bch...it rapes mining for a few tens of blocks with low diff and then miners switch back to Bitcoin, while bch hangs there, waiting for miners, but nobody is mining it due to high difficulty. It'll take hours to get it unstuck. The effect on bitcoin is a few delayed blocks, while the fast-adjusting bch will have created an anomaly similar to how multi-pools rape altcoins - while getting raped itself and then left for hours to come down. The altcoin market has shown that the fast-adjusting coin is more exploitable and disrupted from multi-pools. The problem cannot be easily solved for bch because if you try a detection mechanism that checks whether the blocks aren't arriving to do a massive diff cut, then you are going into an uneven mining pattern, accelerating inflation. In other news: Difficulty [ million ] 860,222 Next difficulty prediction [ million ] 895,877 Difficulty increase prediction [ % ] 4.1%Next retarget [ in days ] 5.3 Network hash rate [ tera hashes / s ] 6,412,936 Last update [ UTC ] 8/4/2017 11:59:00 Diff in bitcoin is going up - mining power keeps increasing. |
|
|
|
3k per coin isn't very interesting. We need 5k+ per coin to get things mildly exciting |
|
|
|
That's just it though. If the cap would have been increased before it was regularly hit, it wouldn't have been a hard fork.
The cap can be hit as regularly as spammers want. It's even easier to do so when it's larger in size due to the lower associated fees (more space, less fee pressure, cheaper spam, easier to bloat it to the max-limit). |
|
|
|
ομως ακομα και τα κεντροποιημενα νομισματα ειναι πολυ καλυτερα απο τα παραδοσιακα λογω του οτι ακομα μπορουν να λειτουργουν ανωνυμα και ανεξαρτητα απο την κεντρικη ολιγαρχικη εξουσια (σαν ΚΚΕ φανηκα τωρα) ...μεχρι η κεντρικη ολιγαρχικη εξουσια να πεισει αυτον που "ελεγχει" ενα centralized coin να κανει αυτο που θελουν. Πχ να γυρισουν πισω συναλλαγες, να παγωσουν funds κτλ. |
|
|
|
That effectively translates to "coinbase will confiscate your BTC" (on one chain).
Only Bitcoin ABC. Does anyone but WU really want those? If you can dump them, you want them I wonder if my 1.8 Bitcoin ABC will even be dumpable. Most exchanges have a minimum transaction amount. IIRC, BCU options (bitcoin unlimited fork options) were like 300$ apiece - and it wasn't even a likely fork |
|
|
|
That effectively translates to "coinbase will confiscate your BTC" (on one chain).
Only Bitcoin ABC. Does anyone but WU really want those? If you can dump them, you want them |
|
|
|
Ο μ.ο των συναλλαγών του Ιουνίου 2017 ήταν αυξημένος σε σχέση με τον Ιούνιο του 2016 κατά +16%
Ο μ.ο των συναλλαγών του Ιουνίου 2016 ήταν αυξημένος σε σχέση με τον Ιούνιο του 2015 κατά +98%
Ο μ.ο των συναλλαγών του Ιουνίου 2015 ήταν αυξημένος σε σχέση με τον Ιούνιο του 2014 κατά +93%
Ο μ.ο των συναλλαγών του Ιουνίου 2014 ήταν αυξημένος σε σχέση με τον Ιούνιο του 2013 κατά +29%
Στο σύνολο του έτους, η αύξηση των συναλλαγών είναι πολύ προβληματική. Φέτος έχουμε τον χειρότερο ρυθμό αύξησης των συναλλαγών από το ξεκινημα του bitcoin.
Οκ, διαβαζοντας και το επομενο τωρα καταλαβα τι λες. Ναι αυτο δεν ειναι προβλημα γιατι στο Bitcoin οι συναλλαγες εμπεριεχουν πολυ spam. Αυτο που εχει πραγματικο νοημα ειναι το value transacted. Υπαρχουν 2 θεωρησεις: 1) Το δικτυο εχει αξια επειδη μπορει να κανει πολλα transactions 2) Το δικτυο εχει αξια επειδη μπορει να κανει transact πολυ value Εστω δικτυο 1, κανει 20 tx/sec των 10 δολαριων εκαστο on average. Εστω δικτυο 2, κανει 3 tx/sec των 500 δολαριων εκαστο on average. Το δικτυο 1 θα διακινει 200 δολαρια/sec x 86400sec/day = 17.28mn usd per day Το δικτυο 2 θα διακινει 1500 δολαρια/sec x 86400sec/day = 129.6mn usd per day Το δικτυο 2, με μειωμενα tx/sec ουσιαστικα διακινει πολυ περισσοτερο χρημα γιατι εχει πιο "σοβαρες" συναλλαγες. Και αυτος ο ογκος συναλλαγων αποτιμημενος σε value ειναι που δινει αξια στο bitcoin και οχι σε ενα altcoin που εχει dust transactions για microbetting πχ. Σχετικα με το 2, δες πως αυξανεται το value transacted per day στο bitcoin: https://blockchain.info/charts/estimated-transaction-volume-usd21/7/2015 = 58.4mn usd 21/7/2016 = 139.2mn usd 18/7/2017 = 620mn usd ( x4.45!) Ακομα και με 3tx/sec το scaling του bitcoin θα συνεχισει λογω της αυξησης στο value transacted per transaction - οπως εκανε και τα προηγουμενα 2 χρονια που τα "blocks are full" και ο ογκος συναλλαγων σε usd πηγε 10.6x επανω. Το paypal* ειχε για το 2016, $354 δις ογκο συναλλαγων. Το bitcoin ειναι περιπου στα $226 δις αν συνεχισει με 620εκ / μερα. Αν συνεχισει το trend ανοδου, του χρονου θα το εχει περασει το paypal με κανα 400αρι-500αρι δις συναλλαγες. Και αυτο με 3tx/sec *Τη western union ηδη την εχουμε αφησει πολυ πισω (80 δις το 2016). |
|
|
|
@AlexGR
Η πραγματικότητα των αριθμών δείχνει δύο πράγματα:
1ον. Η κεφαλαιοποίηση του bitcoin σε σχέση με το σύνολο των κρύπτος έχει μειωθεί.
2ον. Ο μέχρι τώρα ρυθμός αύξησης των επιβεβαιωμένων συναλλαγών, σε σχέση με πέρυσι, είναι εξαιρετικά εξασθενημένος εν αντιθέσει με ότι συνέβαινε τους πρώτους μήνες.
Γενικά κατανοώ την ανθρώπινη ανάγκη για επικοινωνία, αλλά αν δεν αναγνωρίζουμε την πραγματικότητα και τους αριθμούς δεν έχει νόημα καμία συζήτηση.
Το (1) δεν εχει καμμια σχεση με το scaling. Εχει να κανει με το οτι ripple + eth ειναι πιο centralized και ως τετοια ειναι και πιο προτιμητεα για θεσμικους επενδυτες. Οταν εισαι θεσμικος επενδυτης και θες να ριξεις δις, και εχεις "καποιον" να απευθυνθεις για να γυρισει πισω το blockchain (βλεπε τι εγινε στο eth) ή για να κανει κατι που του ζητησεις, αυτο ειναι μακραν πιο "ασφαλες" απο ενα χαοτικο και αναρχικο coin στο οποιο δεν υπαρχει ελεγχος και "ασφαλεια". Τα δεκαδες δις που εχουν πεσει στο eth+ripple γι'αυτο πεσανε. Γιατι ειναι centralized, οχι λογω "scaling". Το (2) δε καταλαβαινω τι εννοεις. Αν εννοεις transactions confirmed vs transactions broadcasted, αυτο δε λεει κατι. Μπορω να κανω broadcast εκατομμυρια συναλλαγες γνωριζοντας απολυτα οτι δε θα μπουν ποτε στο blockchain. Και ακομα και αν αυριο παει 10mb το blockchain μπορω να κανω broadcast 100x και να ξερω οτι το ratio θα μειωθει κι'αλλο. |
|
|
|
In addition to the announcements from nineteen global bitcoin exchanges on July 19, the firm Coinbase announced it would not support the user-activated hard fork and its associated token."[/i]  That effectively translates to "coinbase will confiscate your BTC" (on one chain). |
|
|
|
By the end of August we shall have new ATH.
If you've been buying since June that's a totally understandable position. I think maybe you bought this account to talk horse shit. But what do I know. You sold? If everyone dumps at the same time, we can all rebuy at $200 and start over again? Quick, someone call up the Winklevoss. A couple hundred million dollars have moved into usd tether. Currently ranked #10 in coinmarketcap. These are not funds that are out of the system, these are funds waiting to rebuy at lower prices... at 200$ these 300 million usd tether would buy 1.5mn btc |
|
|
|
Μακαρι να ειχα 100% accuracy, θα χα γινει τρισεκατομμυριουχος Παντως γενικα το τελευταιο διαστημα δε γραφω πολυ, δεν ειναι μονο το συγκεκριμενο θρεντ που "απεχω"... |
|
|
|
Ας μην δραματοποιούμε την κατάσταση. Το Bitcoin έχει φτάσει σε σημείο που επιβάλλεται να γίνει το επόμενο βήμα. Είδαμε ότι όσο μέναμε κολλημένοι, τα ανταγωνιστικά νομίσματα κέρδιζαν μερίδια αγοράς. Όλοι καταλαβαίνουν ότι δεν μπορεί η χωρητικότητα να μείνει στα σημερινά επίπεδα, ούτε μπορεί μονομερώς να αλλάξουν οι κανόνες.
Δε τιθεται θεμα αν θα αυξηθει, αλλα το πως. Γιατι στο "πως" κρυβεται το ποιος θελει να ελεγξει το bitcoin. Τα μεριδια αγορας ανταγωνιστικων νομισματων, που ουσιαστικα στο bulk τους το marketcap το εχει το eth, δεν μπορουν να κανουν scale. Και bloated ειναι, και προβληματικο scaling εχουν. Ολα τους - η μονη τους διαφορα ειναι οτι φαινονται καλυτερα επειδη εχουν πολυ μικρη χρηση. Το pump τους δε σχετιζεται με το τι μπορει ή δε μπορει να κανει το bitcoin. Ο χρυσος μπορει να κανει ακριβως 0 online συναλλαγες ανα δευτερολεπτο και εχει κεφαλαιοποιηση 7 τρις δολαρια. Γιατι? Γιατι εχει χαρακτηριστικα store of value. Το bitcoin ακομα και με 3 tx/s παραμενει store of value αλλα αυτο δεν ισχυει απαραιτητα αμα το πιασουν και το ξεσκισουν στα forks. Αντιθέτως, αν η αλλαγή πετύχει, η μείωση του κόστους συναλλαγών και η επιδιόρθωση του προβλήματος της χωρητικότητας θα δώσουν νέα ώθηση.
Η χωρητικοτητα θα ειναι παντα maxed out, ακομα και με 10mb ή 100mb blocks γιατι το μονο που χρειαζεται για να τα γεμισεις ειναι ενα σκριπτ που κανει broadcast txs και περιμενει καποιον miner να τα κανει include, ακομα και με minimum ή zero fee. Απαξ και καποιος θελει να σπαμαρει το blockchain, αυτο θα γινεται. Οσο το blocksize μεγαλωνει, τοσο μειωνεται η πιεση στα fee και αυτο συνεπαγεται ακομα φθηνοτερο spamming και bloating που με τη σειρα του κανει τη χρηση bandwidth + storage πολυ ακριβοτερη για τα nodes, που με τη σειρα του μετατρεπει το συστημα απο x βαθμο αποκεντρωσης σε 1/x. |
|
|
|
|
Show Posts
