Fakhoury
Legendary
Offline
Activity: 1386
Merit: 1027
Permabull Bitcoin Investor
|
|
June 22, 2015, 10:48:14 PM |
|
I have the log downtrend line at 262. Which is currently a paltry 4200 coins away on bitfinex.
It is just a matter of when the price moves up now IMO.
Btw who in their right mind leaves btc to be lent out short at 0.008% a day? lol
How can I see the log downtrend ? Could you tell me more about it please ? This is the resistance we are facing, right ?
|
|
|
|
Karartma1
Legendary
Offline
Activity: 2310
Merit: 1422
|
|
June 22, 2015, 10:52:29 PM |
|
248$ again, 250's here we come.
|
|
|
|
inca
Legendary
Offline
Activity: 1176
Merit: 1000
|
|
June 22, 2015, 10:56:19 PM |
|
I have the log downtrend line at 262. Which is currently a paltry 4200 coins away on bitfinex.
It is just a matter of when the price moves up now IMO.
Btw who in their right mind leaves btc to be lent out short at 0.008% a day? lol
How can I see the log downtrend ? Could you tell me more about it please ? This is the resistance we are facing, right ? Go to bitcoinwisdom.com. Choose the logarithmic price option. On 1week connect a line from the all time high downwards. Change the mode back to linear and you will see a nice bendy line curling downwards. Zoom in to a smaller time mode and you can see that it today is about 262.
|
|
|
|
ChartBuddy
Legendary
Online
Activity: 2240
Merit: 1779
1CBuddyxy4FerT3hzMmi1Jz48ESzRw1ZzZ
|
|
June 22, 2015, 10:57:10 PM |
|
|
|
|
|
ChartBuddy
Legendary
Online
Activity: 2240
Merit: 1779
1CBuddyxy4FerT3hzMmi1Jz48ESzRw1ZzZ
|
|
June 22, 2015, 11:57:25 PM |
|
|
|
|
|
shmadz
Legendary
Offline
Activity: 1512
Merit: 1000
@theshmadz
|
|
June 23, 2015, 12:47:21 AM |
|
Waiting for over 4hr for my tx now... :/
Did you forget to tip the miners? err, pay transaction fee? I sent payment during 20k utxo last time there was a "stress test" and it went through instantly. Verified first block. I don't see any reason for the big panic and I think it's quite irresponsible of Hearn and Gavin to pretend like the sky is falling.
|
|
|
|
BlackSpidy
|
|
June 23, 2015, 12:56:03 AM |
|
We're really close to breaking the log downtrend, and I expect to see a few days in $310+ when we definitely break out of it.
We will sideways break it so there is no misunderstanding To be honest, I have no idea how we will break it. The thing is that when we broke the (I dont know if this is really a thing) lineal downtrend, sometime in feb 26 with $240-something, we spiked up for a few days, then went back to the weak uptrend we've been having since the dead cat bounce of this January. Sometime between now and august (we'll be above the log downtrend), I think we're going to spike upwards above $310, stay there for a week, then drop back down to whatever the price was before that rise. We'll be at $250-something, move up to $310+, then drop back down to $240, to slowly rise up to $260-$270. Then it's a steady rise until the early 2016 pre-halving mini-bubble. We've going to end 2015 somewhere between $280 and $320. ... and that's what my gut tells me
|
|
|
|
ChartBuddy
Legendary
Online
Activity: 2240
Merit: 1779
1CBuddyxy4FerT3hzMmi1Jz48ESzRw1ZzZ
|
|
June 23, 2015, 12:57:10 AM |
|
|
|
|
|
Kanapka
|
|
June 23, 2015, 01:47:20 AM |
|
Waiting for over 4hr for my tx now... :/
make sure to look other block explorer. Once I thought that my transaction has no confirmation for hours, and has been a blockchain.info issue
|
|
|
|
JorgeStolfi
|
|
June 23, 2015, 01:50:46 AM |
|
The stress was very weak, unfortunately. From this plot: Estimated network capacity: 85 kB/min Typical input tx rate before test: 30--50 kB/min Typical queue size before test: 300--600 kB Peak input tx rate during test: 126 kB/min (~3x normal, ~50% over capacity) Peak queue sizes during peak test: 12 MB (14:00), 14 MB (21:30) Sustained input tx rate for several hours after peak: 70-100 kB/min Methink the test was necessary for people to pay attention to the problem. The test showed that even a small player can create a large backlog with modest expense. It showed that when the input transaction rate is close to the network capacity, even a small increase in that rate can create a huge backlog. Between 18:00 and 21:30, when the input rate increased from ~75 kB/min to ~112 kB/min (a 50% increase), the queue grew from ~3 MB to ~14 MB (a 370% increase). The previous stress test (on a late friday night) used only free transactions, so the fee-paying transactions were delayed only slightly. This one used fee-paying transactions: it will be interesting to see how it affected the ordinary fee-paying transactions.
|
|
|
|
|
ChartBuddy
Legendary
Online
Activity: 2240
Merit: 1779
1CBuddyxy4FerT3hzMmi1Jz48ESzRw1ZzZ
|
|
June 23, 2015, 01:57:12 AM |
|
|
|
|
|
Chef Ramsay
Legendary
Offline
Activity: 1568
Merit: 1001
|
|
June 23, 2015, 02:17:44 AM |
|
I have the log downtrend line at 262. Which is currently a paltry 4200 coins away on bitfinex.
It is just a matter of when the price moves up now IMO.
Btw who in their right mind leaves btc to be lent out short at 0.008% a day? lol
Yeah, no shit. This just subsidizing short dicks while getting peanuts for it. If i ain't getting at least seven times this, i wouldnt even consider swapping.
|
|
|
|
shmadz
Legendary
Offline
Activity: 1512
Merit: 1000
@theshmadz
|
|
June 23, 2015, 02:25:44 AM |
|
The stress was very weak, unfortunately. From this plot: Estimated network capacity: 85 kB/min Typical input tx rate before test: 30--50 kB/min Typical queue size before test: 300--600 kB Peak input tx rate during test: 126 kB/min (~3x normal, ~50% over capacity) Peak queue sizes during peak test: 12 MB (14:00), 14 MB (21:30) Sustained input tx rate for several hours after peak: 70-100 kB/min Methink the test was necessary for people to pay attention to the problem. The test showed that even a small player can create a large backlog with modest expense. It showed that when the input transaction rate is close to the network capacity, even a small increase in that rate can create a huge backlog. Between 18:00 and 21:30, when the input rate increased from ~75 kB/min to ~112 kB/min (a 50% increase), the queue grew from ~3 MB to ~14 MB (a 370% increase). The previous stress test (on a late friday night) used only free transactions, so the fee-paying transactions were delayed only slightly. This one used fee-paying transactions: it will be interesting to see how it affected the ordinary fee-paying transactions. Do you know if there's a way to see what fee they paid? Was it like normal fee of 0.0001 btc? (About 2 or 3 cents) If so, wouldn't a move to a minimum fee of say ten cents largely fix the problem? Also, do you know why Satoshi decided to limit the block size in the first place? I mean, I've heard it was to prevent some kind of spam attack, but now people are saying that increasing block size will prevent spam attack... I've never seen a good description of the attack they were trying to mitigate by limiting block size in the first place. Best guess is simply to prevent bloat?
|
|
|
|
rolling
|
|
June 23, 2015, 02:41:08 AM |
|
The stress was very weak, unfortunately. From this plot: Estimated network capacity: 85 kB/min Typical input tx rate before test: 30--50 kB/min Typical queue size before test: 300--600 kB Peak input tx rate during test: 126 kB/min (~3x normal, ~50% over capacity) Peak queue sizes during peak test: 12 MB (14:00), 14 MB (21:30) Sustained input tx rate for several hours after peak: 70-100 kB/min Methink the test was necessary for people to pay attention to the problem. The test showed that even a small player can create a large backlog with modest expense. It showed that when the input transaction rate is close to the network capacity, even a small increase in that rate can create a huge backlog. Between 18:00 and 21:30, when the input rate increased from ~75 kB/min to ~112 kB/min (a 50% increase), the queue grew from ~3 MB to ~14 MB (a 370% increase). The previous stress test (on a late friday night) used only free transactions, so the fee-paying transactions were delayed only slightly. This one used fee-paying transactions: it will be interesting to see how it affected the ordinary fee-paying transactions. Do you know if there's a way to see what fee they paid? Was it like normal fee of 0.0001 btc? (About 2 or 3 cents) If so, wouldn't a move to a minimum fee of say ten cents largely fix the problem? Also, do you know why Satoshi decided to limit the block size in the first place? I mean, I've heard it was to prevent some kind of spam attack, but now people are saying that increasing block size will prevent spam attack... I've never seen a good description of the attack they were trying to mitigate by limiting block size in the first place. Best guess is simply to prevent bloat? I'm pretty sure I read somewhere that there was no block size limit in Satoshi's software. They added it later. He believed in game theory where things sort themselves out through risk and reward.
|
|
|
|
shmadz
Legendary
Offline
Activity: 1512
Merit: 1000
@theshmadz
|
|
June 23, 2015, 02:53:36 AM |
|
I'm pretty sure I read somewhere that there was no block size limit in Satoshi's software. They added it later. He believed in game theory where things sort themselves out through risk and reward.
Not sure, but I found this? "Andresen never mentions the actual reason that Satoshi imposed a block limit. Oleg Andreev, however, does: Huge blocks could lead to excessive use of bandwidth which could lead to higher percentage of orphaned blocks due to higher synchronization delays." From: http://cascadianhacker.com/blog/2014/10/25_notes-on-increasing-the-maximum-bitcoin-block-size-or-why-it-aint-happenin.htmlIf bandwidth is really the only issue then you would think the 8mb compromise will likely gain enough traction to get implemented. After all, even with a 8mb limit, most miners will still be sticking to 750 k - until you provide sufficient incentive to change.
|
|
|
|
ChartBuddy
Legendary
Online
Activity: 2240
Merit: 1779
1CBuddyxy4FerT3hzMmi1Jz48ESzRw1ZzZ
|
|
June 23, 2015, 02:57:14 AM |
|
|
|
|
|
rolling
|
|
June 23, 2015, 03:05:43 AM |
|
I'm pretty sure I read somewhere that there was no block size limit in Satoshi's software. They added it later. He believed in game theory where things sort themselves out through risk and reward.
Not sure, but I found this? "Andresen never mentions the actual reason that Satoshi imposed a block limit. Oleg Andreev, however, does: Huge blocks could lead to excessive use of bandwidth which could lead to higher percentage of orphaned blocks due to higher synchronization delays." From: http://cascadianhacker.com/blog/2014/10/25_notes-on-increasing-the-maximum-bitcoin-block-size-or-why-it-aint-happenin.htmlIf bandwidth is really the only issue then you would think the 8mb compromise will likely gain enough traction to get implemented. After all, even with a 8mb limit, most miners will still be sticking to 750 k - until you provide sufficient incentive to change. Yeah, exactly. You can have a higher limit or no limit at all and it's still a risk for a miner to build a block that big. It's going to take a longer time to propagate over the internet which means more time for another miner to find another (smaller/faster) block and possibly orphan yours. I'm sure the limit was created to prevent some kind of "large block attack" (to disrupt miners with slow internet?) but in reality, risk and reward will prevent most miners from increasing their block size very much even when the limit is officially increased.
|
|
|
|
shmadz
Legendary
Offline
Activity: 1512
Merit: 1000
@theshmadz
|
|
June 23, 2015, 03:31:29 AM |
|
I'm pretty sure I read somewhere that there was no block size limit in Satoshi's software. They added it later. He believed in game theory where things sort themselves out through risk and reward.
Not sure, but I found this? "Andresen never mentions the actual reason that Satoshi imposed a block limit. Oleg Andreev, however, does: Huge blocks could lead to excessive use of bandwidth which could lead to higher percentage of orphaned blocks due to higher synchronization delays." From: http://cascadianhacker.com/blog/2014/10/25_notes-on-increasing-the-maximum-bitcoin-block-size-or-why-it-aint-happenin.htmlIf bandwidth is really the only issue then you would think the 8mb compromise will likely gain enough traction to get implemented. After all, even with a 8mb limit, most miners will still be sticking to 750 k - until you provide sufficient incentive to change. Yeah, exactly. You can have a higher limit or no limit at all and it's still a risk for a miner to build a block that big. It's going to take a longer time to propagate over the internet which means more time for another miner to find another (smaller/faster) block and possibly orphan yours. I'm sure the limit was created to prevent some kind of "large block attack" (to disrupt miners with slow internet?) but in reality, risk and reward will prevent most miners from increasing their block size very much even when the limit is officially increased. Unless you had a situation where a very large miner (over 25% of the network) purposefully creates these large blocks because they can start building immediately while other miners have to wait to verify... One could imagine a scenario where a large miner could go on a run of consecutive blocks because of the slight advantage of starting on the next block first, Example - F2Pool recently: It's mostly due to dumb luck, but there is an advantage to building on your own block before anyone else, and increasing the block size will only increase this advantage. (Note: this also makes certain types of double-spend attacks easier, but currently the block subsidy is large enough that it is still more profitable to "play fair"... what might happen in ten years under Gavin's plan when block subsidy is only 3.125 btc and blocks are 256MB however might get interesting, )
|
|
|
|
ChartBuddy
Legendary
Online
Activity: 2240
Merit: 1779
1CBuddyxy4FerT3hzMmi1Jz48ESzRw1ZzZ
|
|
June 23, 2015, 03:57:13 AM |
|
|
|
|
|
|