Bitcoin Forum
December 16, 2017, 01:47:32 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 [1389] 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2022643 times)
plasticAiredale
Full Member
***
Offline Offline

Activity: 171



View Profile
June 30, 2015, 11:13:26 AM
 #27761

I am struggling making a comparaison chart of Bitcoin's vs Euro's volatility, anyone knows a tool to do so please?

A while back I put something on this thread which touches both on how to obtain data from someone else's Google spreadsheet (using it as a quasi-database) and also feeding data into gnuplot.  Sometimes I get carried away trying to do one-liners on the command line (though I'm losing my edge for lack of practice over the last few years.)  Probably won't do you much good, but here it is:

  https://bitcointalk.org/index.php?topic=68655.msg925384#msg925384



erf i'm having this excel issue, where i have on one cell multiple data

for ex: 2015-06-14,233.8536,5.454695278537045,0.004716184177479654,0.011187287496159574

how do i separate and reaffect each to single cell?

Text to Columns command in Excel:
https://support.microsoft.com/en-us/kb/214261
1513432052
Hero Member
*
Offline Offline

Posts: 1513432052

View Profile Personal Message (Offline)

Ignore
1513432052
Reply with quote  #2

1513432052
Report to moderator
1513432052
Hero Member
*
Offline Offline

Posts: 1513432052

View Profile Personal Message (Offline)

Ignore
1513432052
Reply with quote  #2

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

Posts: 1513432052

View Profile Personal Message (Offline)

Ignore
1513432052
Reply with quote  #2

1513432052
Report to moderator
1513432052
Hero Member
*
Offline Offline

Posts: 1513432052

View Profile Personal Message (Offline)

Ignore
1513432052
Reply with quote  #2

1513432052
Report to moderator
1513432052
Hero Member
*
Offline Offline

Posts: 1513432052

View Profile Personal Message (Offline)

Ignore
1513432052
Reply with quote  #2

1513432052
Report to moderator
hdbuck
Legendary
*
Offline Offline

Activity: 1274



View Profile
June 30, 2015, 01:07:39 PM
 #27762


hum i dont get it, doesnt the EVZ index represent EUR's volatility? or where can i get the eur/usd volatility data?
sickpig
Legendary
*
Offline Offline

Activity: 1232


View Profile
June 30, 2015, 02:16:52 PM
 #27763

"this Rusty guy" is https://en.m.wikipedia.org/wiki/Rusty_Russell

to make a long story short he wrote Linux kernel packets filtering system ipchains/iptables (aka Linux firewall), lguest virtualization system (ancestor of docker/lxc) and contribute to samba/cifs  (a way to let Linux and ms win talk together), just to name a few.

edit: fix misattribution about samba/cifs projecf

no, i know who he is.  i like his independent spirit.

just want to be sure Tongue

he's even still maintaining some linux's kernel subsystems:

Code:
LGUEST
M: Rusty Russell <rusty@rustcorp.com.au>
L: lguest@lists.ozlabs.org
W: http://lguest.ozlabs.org/
S: Odd Fixes
...

MODULE SUPPORT
M: Rusty Russell <rusty@rustcorp.com.au>
S: Maintained

...

PARAVIRT_OPS INTERFACE
...
M: Rusty Russell <rusty@rustcorp.com.au>
L: virtualization@lists.linux-foundation.org
S: Supported

maybe the above lists is a little bit out of date (as quite frequently happens with
doc and meta info files contained in the linux's kernel tree), but this pull request
regard another subsystem (pinctrl) and it is as recent as today:

http://www.spinics.net/lists/kernel/msg2022752.html

impressive.

 

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 02:41:27 PM
 #27764

GBTC coming off the bottom on it's highest volume ever yesterday:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 02:42:44 PM
 #27765

trusty SLW going down the chute:

_mr_e
Legendary
*
Offline Offline

Activity: 817



View Profile
June 30, 2015, 02:48:35 PM
 #27766

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:



Why do you call this "defensive" action?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 02:52:38 PM
 #27767

curious.  i haven't heard any news of Greeks fleeing to gold.  of course, my news feed is biased towards Bitcoin.  nonetheless, i do read traditional sources and haven't heard a peep about that while Bitcoin buying articles seem to be abound.

that should tell you something.  and that is, with a standard internet connection, even in the presence of a Great Firewall of China which Greece doesn't have, ordinary citizens can easily find their way to Bitcoin buying sources.  the articles from yesterday were quoting business up 10x.  even Greeks are somehow buying gold in the background, i doubt it would be to that magnitude due to the increased ease, storage, transportation, safety, & speed of buying Bitcoin.

that shows us one other thing.  if blocks continue to get filled and inaccessible, then ordinary citizens at far ends of the Earth will not be able to buy Bitcoin when they need to.  sure, Greece isn't technically a 3rd world country but it's more towards that end of the spectrum nowadays than a developed country.

i spent all day watching blocks sizes and degree of fullness.  there was filling going on all day long with TPS bursting to 30TPS many times throughout the day as well as unconf tx's doubling even tripling.  2.3 TPS is the threshold for when the network starts having problems.

bottomline is, there will be much more demand coming from all over the world in quite near times to come.  Bitcoin has to be ready to scale.  Any forward looking person who understands business knows to look forward and prepare.  the fastest, simplest, most predictable, most easily understood way to do that is to increase the block size now.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 02:55:12 PM
 #27768

dammit.  here we go again upon just checking.  unconf tx's over 7000:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 02:57:52 PM
 #27769

trusty 'ol Goldcorp gone off the cliff:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 02:58:25 PM
 #27770

Gold collapsing.  Bitcoin UP.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 03:06:19 PM
 #27771

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:



Why do you call this "defensive" action?

when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block.  this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing  the next block with only the  "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.
sickpig
Legendary
*
Offline Offline

Activity: 1232


View Profile
June 30, 2015, 03:14:14 PM
 #27772

dammit.  here we go again upon just checking.  unconf tx's over 7000:



any chances of an on going stress test ?

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 03:16:18 PM
 #27773

what's interesting to me is that all these full blocks that have been coming more frequently and consecutively have not caused any block delays.  that is good news b/c there are some who thought that as we filled the 1MB limit, there might be delays and have pointed to just this mechanism in the past when we've had such delays.  so we know 1MB blocks don't slow down the network.  so just how high can we push this limit w/o breaking it?
_mr_e
Legendary
*
Offline Offline

Activity: 817



View Profile
June 30, 2015, 03:18:05 PM
 #27774

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:



Why do you call this "defensive" action?

when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block.  this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing  the next block with only the  "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.

So they switch back to working on a full block if they aren't able to solve the block header in the time it takes to fully process everything?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 03:21:33 PM
 #27775

dammit.  here we go again upon just checking.  unconf tx's over 7000:



any chances of an on going stress test ?

i doubt it as yesterday's scheduled test didn't conform to it's stated plan.  

and really, does it matter?  how can you tell in most circumstances unless spam tx's are coming from a single address?  and if the tx's are paying the regular fees, which they are, who cares?  the miners will make hay and be more profitable.  actually, i do care b/c that means ordinary users that might square the network effect (Metcalfe) wanting in from places like Greece might not be able to get in.  yes, the 1MB'ers will say that they're just coming in thru places like Coinbase, which they are, but i'd counter argue that in the medium to long run Coinbase has to buy supply from the mainchain to keep their reserves high.  so it does feed through.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 03:22:59 PM
 #27776

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:



Why do you call this "defensive" action?

when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block.  this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing  the next block with only the  "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.

So they switch back to working on a full block if they aren't able to solve the block header in the time it takes to fully process everything?

yep.  and that makes sense b/c they want not only the reward but the fees if they can get them.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 03:26:50 PM
 #27777

what's interesting to me is that all these full blocks that have been coming more frequently and consecutively have not caused any block delays.  that is good news b/c there are some who thought that as we filled the 1MB limit, there might be delays and have pointed to just this mechanism in the past when we've had such delays.  so we know 1MB blocks don't slow down the network.  so just how high can we push this limit w/o breaking it?

what's also really interesting is that currently, i'm not seeing any 0 tx defensive blocks being mined.  maybe the Chinese miners are figuring out that it's not necessary.  that's more good news b/c we want them munching as many tx's as possible in a consistent manner. 

and that's good news b/c they are probably figuring out that a block size increase can't hurt them if done in a "safe" way, whatever that means.
_mr_e
Legendary
*
Offline Offline

Activity: 817



View Profile
June 30, 2015, 03:36:52 PM
 #27778

what's interesting to me is that all these full blocks that have been coming more frequently and consecutively have not caused any block delays.  that is good news b/c there are some who thought that as we filled the 1MB limit, there might be delays and have pointed to just this mechanism in the past when we've had such delays.  so we know 1MB blocks don't slow down the network.  so just how high can we push this limit w/o breaking it?

what's also really interesting is that currently, i'm not seeing any 0 tx defensive blocks being mined.  maybe the Chinese miners are figuring out that it's not necessary.  that's more good news b/c we want them munching as many tx's as possible in a consistent manner. 

and that's good news b/c they are probably figuring out that a block size increase can't hurt them if done in a "safe" way, whatever that means.

I think that if we see blocks fill up and the network starts functioning poorly, we are going to see a change pushed out far quicker then any of us ever imagined.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 03:46:02 PM
 #27779

what's interesting to me is that all these full blocks that have been coming more frequently and consecutively have not caused any block delays.  that is good news b/c there are some who thought that as we filled the 1MB limit, there might be delays and have pointed to just this mechanism in the past when we've had such delays.  so we know 1MB blocks don't slow down the network.  so just how high can we push this limit w/o breaking it?

what's also really interesting is that currently, i'm not seeing any 0 tx defensive blocks being mined.  maybe the Chinese miners are figuring out that it's not necessary.  that's more good news b/c we want them munching as many tx's as possible in a consistent manner. 

and that's good news b/c they are probably figuring out that a block size increase can't hurt them if done in a "safe" way, whatever that means.

I think that if we see blocks fill up and the network starts functioning poorly, we are going to see a change pushed out far quicker then any of us ever imagined.

well, let's hope so.

i believe the confliction runs deep with those guys.  i mean, their careers are on the line if they ever want any more investment money.  that's just the way these things work.
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 30, 2015, 03:46:42 PM
 #27780

I think that if we see blocks fill up and the network starts functioning poorly, we are going to see a change pushed out far quicker then any of us ever imagined.

Indeed. Theory is theory, lips will flap endlessly while they can. First sign of pain, opinion will go way lopsided.
Pages: « 1 ... 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 [1389] 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 ... 1558 »
  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!