hdbuck
Legendary
Offline
Activity: 1260
Merit: 1002
|
|
June 30, 2015, 09:09:29 AM Last edit: June 30, 2015, 09:26:16 AM by hdbuck |
|
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#msg925384erf 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? Don't know much about excel (have not used it for several decades) but you might try making sure you import the data as 'csv' (comma separated values.) It looks like it is such but excel is not interpreting it that way. It is also sometimes the case that the input data can have something which excel interpreted as 'escapes'. That is, it might be being inadvertently instructed to be treating the commas as literal values. yea no i have managed it thx, in the end i have this: so bitcoin is more stable than euro! Édit: any feed-back tho? Im having doubts as to if i have done it right..
|
|
|
|
|
plasticAiredale
|
|
June 30, 2015, 11:13:26 AM |
|
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#msg925384erf 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
|
|
|
|
hdbuck
Legendary
Offline
Activity: 1260
Merit: 1002
|
|
June 30, 2015, 01:07:39 PM Last edit: June 30, 2015, 01:19:36 PM by hdbuck |
|
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
Activity: 1260
Merit: 1008
|
|
June 30, 2015, 02:16:52 PM |
|
"this Rusty guy" is https://en.m.wikipedia.org/wiki/Rusty_Russellto 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 he's even still maintaining some linux's kernel subsystems: 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.htmlimpressive.
|
Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 02:41:27 PM |
|
GBTC coming off the bottom on it's highest volume ever yesterday:
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 02:42:44 PM |
|
trusty SLW going down the chute:
|
|
|
|
_mr_e
Legendary
Offline
Activity: 817
Merit: 1000
|
|
June 30, 2015, 02:48:35 PM |
|
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 (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 02:52:38 PM |
|
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 (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 02:55:12 PM |
|
dammit. here we go again upon just checking. unconf tx's over 7000:
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 02:57:52 PM |
|
trusty 'ol Goldcorp gone off the cliff:
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 02:58:25 PM |
|
Gold collapsing. Bitcoin UP.
|
|
|
|
cypherdoc (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 03:06:19 PM |
|
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
Activity: 1260
Merit: 1008
|
|
June 30, 2015, 03:14:14 PM |
|
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 (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 03:16:18 PM |
|
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
Activity: 817
Merit: 1000
|
|
June 30, 2015, 03:18:05 PM |
|
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 (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 03:21:33 PM |
|
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 (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 03:22:59 PM |
|
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 (OP)
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
June 30, 2015, 03:26:50 PM |
|
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
Activity: 817
Merit: 1000
|
|
June 30, 2015, 03:36:52 PM |
|
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.
|
|
|
|
|