Anyone know the low and high price for 2014, 2015 and 2016?
OK, this is what I got off of coin market cap 2014 Low Feb. 10, 2014 0.00041330 BTC 2014 Low Feb. 10, 2014 $0.265834 2014 High May 19, 2014 0.01889618 BTC 2014 High June 2, 2014 $12.22 2015 Low December 14 2015 0.00579146 BTC 2015 Low December 29 $1.86 2015 High March 23, 2015 0.01988543 BTC 2015 High March 23, 2015 $5.03 2016 Low January 4, 2016 0.00741509 BTC 2016 Low January 12, 2016 $1.31 2016 High January 18, 2016 0.01146713 BTC 2016 High January 18, 2015 $4.52 Coinmarketcap chart is unreliable because it lacks granularity. Low was much lower and high was much higher for 2014. Case in point (old post, commenting on CCEX prices): DRK should be worth 0.01 BTC !!!
give it time :-) its slowly going up on the exchange... it started really low 0.0000101, but just now they started to sell for 0.00005 ...and as for high, it wasn't 0.018 in spring/summer '14. |
|
|
|
blocks are completely full
every single one
my 1cent fee tx has yet to be mined
CB's maths are wrong.
I had to wait the whole night for my tx to go through. First time I need to wait so long :-/ Anything from 0.02$+ confirms fast, as proved, and even 0.01$ confirms in a few hours. Again: This is ridiculously low fees. The fact that transactions are even included at these rates is a market failure of shorts. Question of point of view. 1 cent for a 1$ tx is 1%. Not a ridiculous amount. You can have 250.000 txs per day moving around 1 dollar on avg (daily volume = 250k$), or you could be moving 1000$ (daily volume = 250mn $). It's a choice. And scaling can't go 1000x - I mean Gavin can't come up with 1GB blocks to produce 250mn transactions per day of avg 1 dollar. I see your point. But BTC is not used for massive tx. In fact its reputation is rather the contrary: being able to send small amounts to people. This comes from all the faucets and ponzi shits. Massive is like millions, not hundreds or thousands. But then again, these are relative terms, so... |
|
|
|
blocks are completely full
every single one
my 1cent fee tx has yet to be mined
CB's maths are wrong.
I had to wait the whole night for my tx to go through. First time I need to wait so long :-/ Anything from 0.02$+ confirms fast, as proved, and even 0.01$ confirms in a few hours. Again: This is ridiculously low fees. The fact that transactions are even included at these rates is a market failure of shorts. Question of point of view. 1 cent for a 1$ tx is 1%. Not a ridiculous amount. You can have 250.000 txs per day moving around 1 dollar on avg (daily volume = 250k$), or you could be moving 1000$ (daily volume = 250mn $). It's a choice. And scaling can't go 1000x - I mean Gavin can't come up with 1GB blocks to produce 250mn transactions per day of avg 1 dollar. |
|
|
|
3) Amount sent $1.00 (.00236 BTC) I Manually added Fee .00001 BTC ($.004) (.00001 BTC per kilobyte) (fee % = 0.4%)
- Was never viewable on receiving end until after completely received / available for use (3 confirmations) after 9 hours / 21 minutes.
0.004$. Not even a cent. 4 tenths of 1 cent. Confirmed. Under "full blocks". I mean wtf. |
|
|
|
blocks are completely full
every single one
my 1cent fee tx has yet to be mined
CB's maths are wrong.
I had to wait the whole night for my tx to go through. First time I need to wait so long :-/ Anything from 0.02$+ confirms fast, as proved, and even 0.01$ confirms in a few hours. Again: This is ridiculously low fees. The fact that transactions are even included at these rates is a market failure of shorts. |
|
|
|
Took a while but: Included In Blocks 399923 Even with near-zero fees at 0.01$ you got in, with lower priority, despite "blocks are full". Because the time to worry about the rising costs are after they become a problem or before? The time to worry about lifeboat capacity is after the iceberg has been hit? We've seen what the network looks like in even more congested situations due to the stress tests. Fees remained low still. The reason is that legit txs are way below 1mb and what is left of the 1mb is "topped off" with very cheap/spam/dust/dice etc txs. So the legit txs can always get confirmed fast with 3-4-5cents, while the spammers try to get included (and do get included) by trying fees like 0 and 1 cent. If the network can process both legit use, spam, stress test that artificially bloats txs, and do all that while fees are consistently at near-zero cost, then fuck me man... what more do you want? And this SHOULDN'T BE LIKE THAT. It's not healthy. It's not what it's supposed to be based on Bitcoin's design to replace diminishing subsidy with rising fees - and we have already distributed ~75% of the monetary base. |
|
|
|
Took a while but: Included In Blocks 399923 Even with near-zero fees at 0.01$ you got in, with lower priority, despite "blocks are full". |
|
|
|
blocks are completely full
every single one
my 1cent fee tx has yet to be mined
They are full precisely because almost all near-zero fee transactions are currently included. Are all zero fee transactions included in Litecoin, Dash, monero, etherium? Bitcoin is losing market share because competitors are underpricing us. Just open a block explorer and you'll see LTC and DASH has like 4-5-6 tx/block, monero is at 0-1. BTC does like 2000 txs/block. |
|
|
|
blocks are completely full
every single one
my 1cent fee tx has yet to be mined
They are full precisely because almost all near-zero fee transactions are currently included. |
|
|
|
Broadcast after 399882 (so that we can have a measurement when it gets in). Included In Blocks 399890 |
|
|
|
Broadcast after 399882 (so that we can have a measurement when it gets in). |
|
|
|
it's OK tho, when LN comes out fee will go right back to 1cent, because it will relieve a lot of pressure from the blockchain
LN is designed to improve scaling. Fee reductions are just a consequence of being able to conduct more transactions. |
|
|
|
LOL, just withdrew some BTC from an exchange, they are paying 0.00015936 XBT = $0.0924195 CAD per tx. just got 2 confirmations in like 2 minus.
Blocks are only full if your are not paying almost $0.10 per transaction.
We don't need to guesstimate: From cointape.com, based on what is happening: 1-10 satoshi per byte = from 7 blocks to infinity. 11-20 satoshi per byte = from 2 blocks to 28 21-30 satoshi per byte = from 0 to 5 blocks 31-40 satoshi per byte = from 0 to 2 blocks 41-50 satoshi per byte = from 0 to 1 blocks 10 satoshi per byte = 0.011$ per 258byte tx 20 satoshi per byte = 0.022$ per 258byte tx 30 satoshi per byte = 0.033$ per 258byte tx 40 satoshi per byte = 0.044$ per 258byte tx 50 satoshi per byte = 0.055$ per 258byte tx |
|
|
|
Damn, 1 cent fee is 1% it's far too much already! I usually pay a 0.1% fee and it goes in the first blocks! Fees go per kilobytes used in the blockchain, not per amount sent. The blockchain doesn't care if you send 0.01 btc or 10 btc - only about how much space is used by the transaction. Well. Logical I suppose. But how do you know the size of your transaction? If it's not a collection of dust, or from multiple inputs, it should be near 0.25kb. side note, my TX is the min size ~256bytes
block height 399870
0 confirmations
Side note: You sent it out while there was a 40m gap to the last block found (that's not related to "blocks are full", rather mining variance). |
|
|
|
Damn, 1 cent fee is 1% it's far too much already! I usually pay a 0.1% fee and it goes in the first blocks! Fees go per kilobytes used in the blockchain, not per amount sent. The blockchain doesn't care if you send 0.01 btc or 10 btc - only about how much space is used by the transaction. |
|
|
|
...
FUDing all day long about "full blocks"?
As in ChartBuddy posting how full the blocks are? As in bigblockers pretending the fullblockalypse is coming when you can get a tx included in <10 blocks for 1 cent, and in one block with 5 cents. We've had more transactions in the last month than at anytime in history. Yes, blocks are full. Maybe not to the point that nothing can move (yet) but to the point where it is becoming impractical and cost-prohibitive to mix coins and maintain anonymity.
1c to 5c fees are by no means cost-prohibitive (they are near zero cost) and also very practical. |
|
|
|
i feel as tho i'm being manipulated from one side to another over and over and over.
What have bigblockers done to manipulate anyone? FUDing all day long about "full blocks"? |
|
|
|
Perhaps the benchmark methodology could be like
a) online (measuring network transfers as well)
b) offline (measuring validation of disks in the data)
further broken down to
a) real-time (getting RL metrics of blocks as they are added in terms of network speeds, cpu time required, I/O time required), including "catchup mode" where you open the -qt client, you are 1 day behind, and you can measure that as well in terms of how much cpu or I/O is used per mb of block data etc - although that is not 100% accurate due to differences in the way txs are included in blocks.
b) non-real time where you could have something like --bench=height 350000-351000 where you'd measure I/O and CPU speeds for validating a pre-selected range of 1000 blocks that are already stored in your hard disk.
...Any alterations on metrics that are useful could also be included.
I made a custom build with march=native flags and I don't really have any serious tool to measure whether my binary is faster than the official one, or my distribution's binary. I also want to experiment with various GCC versions, Intel and AMD C compilers, clang etc etc to see which gets the best performance, but I'm lacking benchmarking tools.
Using -O2 seems to get pretty close to the best variant with most things, but maybe some specific vector optimizations could make a noticeable difference. And without a benchmark we'll never know  From what I have seen RAM, DB slowness and serialization issues are the main bottlenecks now.
+
The serial nature creates a lot of dropouts from the saturated bandwidth ideal, so definitely parallel sync is needed for fastest performance.
RAM can be traded with CPU with something like ZRAM where you increase the data that can fit into it, by compressing them in real time. It's pretty handy. With LZ4 I'm getting 2.5-3x RAM compression ratios and can easily avoid swapping to disk which is very expensive in terms of I/O times. In theory Bitcoin could use its own ram compression scheme with an off the shelf algorithm for things like its caching system or other subsystems. Same with disk compression which is an I/O tradeoff with CPU. I tried installing the blockchain in a BTRFS compressed partition, it was slightly faster in terms of throughput and also saved 10gb+ in size. From what I remember Windows 7 also have compressed folders support, so it should be doable in windows too. Serialization is indeed an issue but if you can get a serial process to get on with it 10-20% faster due to custom compilation, then it's worth it - until these things are fixed in the code. For sync, I make sure network bandwidth is as saturated as possible for as long as possible. This is a shortcut, but practical. If the code cant process the data at full speed, then it can be optimized. Well at least there is a chance to.
Makes sense. squashfs cut the size of the "DB" files from 25GB to ~15GB so that automatically takes advantage of disk compression without slowing down high bandwidth disk usage where the HDD is the bottleneck. When streaming at 100MB/sec, there is no time for a compression stage. There isnt even time for mallocs. The compression needs to be after all the final files are created and it takes about the same half hour it takes to do the sync James It depends on the algorithm. LZ4 can do GBytes/s... edit: https://github.com/Cyan4973/lz4scroll down to "Benchmarks"... quoted numbers are for single thread @ 1.9 GHz. So a modern system with 4 cores, better architecture, higher mem throughput and higher clockspeeds could probably do 5-8x. |
|
|
|
Perhaps the benchmark methodology could be like
a) online (measuring network transfers as well)
b) offline (measuring validation of disks in the data)
further broken down to
a) real-time (getting RL metrics of blocks as they are added in terms of network speeds, cpu time required, I/O time required), including "catchup mode" where you open the -qt client, you are 1 day behind, and you can measure that as well in terms of how much cpu or I/O is used per mb of block data etc - although that is not 100% accurate due to differences in the way txs are included in blocks.
b) non-real time where you could have something like --bench=height 350000-351000 where you'd measure I/O and CPU speeds for validating a pre-selected range of 1000 blocks that are already stored in your hard disk.
...Any alterations on metrics that are useful could also be included.
I made a custom build with march=native flags and I don't really have any serious tool to measure whether my binary is faster than the official one, or my distribution's binary. I also want to experiment with various GCC versions, Intel and AMD C compilers, clang etc etc to see which gets the best performance, but I'm lacking benchmarking tools.
Using -O2 seems to get pretty close to the best variant with most things, but maybe some specific vector optimizations could make a noticeable difference. And without a benchmark we'll never know From what I have seen RAM, DB slowness and serialization issues are the main bottlenecks now.
+
The serial nature creates a lot of dropouts from the saturated bandwidth ideal, so definitely parallel sync is needed for fastest performance.
RAM can be traded with CPU with something like ZRAM where you increase the data that can fit into it, by compressing them in real time. It's pretty handy. With LZ4 I'm getting 2.5-3x RAM compression ratios and can easily avoid swapping to disk which is very expensive in terms of I/O times. In theory Bitcoin could use its own ram compression scheme with an off the shelf algorithm for things like its caching system or other subsystems. Same with disk compression which is an I/O tradeoff with CPU. I tried installing the blockchain in a BTRFS compressed partition, it was slightly faster in terms of throughput and also saved 10gb+ in size. From what I remember Windows 7 also have compressed folders support, so it should be doable in windows too. Serialization is indeed an issue but if you can get a serial process to get on with it 10-20% faster due to custom compilation, then it's worth it - until these things are fixed in the code. For sync, I make sure network bandwidth is as saturated as possible for as long as possible. This is a shortcut, but practical. If the code cant process the data at full speed, then it can be optimized. Well at least there is a chance to.
Makes sense. |
|
|
|
|
Perhaps the benchmark methodology could be like
a) online (measuring network transfers as well)
b) offline (measuring validation of disks in the data)
further broken down to
a) real-time (getting RL metrics of blocks as they are added in terms of network speeds, cpu time required, I/O time required), including "catchup mode" where you open the -qt client, you are 1 day behind, and you can measure that as well in terms of how much cpu or I/O is used per mb of block data etc - although that is not 100% accurate due to differences in the way txs are included in blocks.
b) non-real time where you could have something like --bench=height 350000-351000 where you'd measure I/O and CPU speeds for validating a pre-selected range of 1000 blocks that are already stored in your hard disk.
...Any alterations on metrics that are useful could also be included.
I made a custom build with march=native flags and I don't really have any serious tool to measure whether my binary is faster than the official one, or my distribution's binary. I also want to experiment with various GCC versions, Intel and AMD C compilers, clang etc etc to see which gets the best performance, but I'm lacking benchmarking tools.
|
|
|
|
|
Show Posts
