Pages:
Author

Topic: Gold collapsing. Bitcoin UP. - page 98. (Read 2032247 times)

legendary
Activity: 2044
Merit: 1005
July 23, 2015, 01:42:12 PM
this is an awesome quote:

The technology will be “of fundamental importance to Wall Street,” Nasdaq Chief Executive Officer Bob Greifeld said during a phone interview Thursday. “The benefits to the industry are immense and cannot be ignored.”


http://www.bloomberg.com/news/articles/2015-07-23/nasdaq-expects-to-be-first-exchange-to-use-bitcoin-technology

you know they're going to want cheap tx fees don't you?

Wall Street is also going to need a tad more than 3 tps as well.


https://bitshares.org/technology/industrial-performance-and-scalability/

IMO they are better off working off of either BTS or learning how they solved the problems to achieve > 100k TPS on a decentralized platform.

BTW the CCEDK exchange will be running off of the bitshares decentralized exchange.
https://bitshares.org/blog/2015/06/16/danish-firm-set-to-revolutionize-cryptocurrency-industry/
legendary
Activity: 1153
Merit: 1000
July 23, 2015, 01:37:40 PM
LOL, the Gavinistas are furiously scribbling their little manifesto.  This gonna be good.   Grin

Exactly like the Peoples' Front of Judea (or was it the Judean Peoples' Front?)

"What have the core devs ever done for us?"

I'm grateful to the developers, but this is not about them, I'm also happy that not everyone at central control is part of the heard, everything in this post is good news. if you read that tweet again, it looks like a critique of the mainstream circle jerk.

Ah, but BitcoinSX is about the developers.  Specifically, SX's lack of them and predictable GFY response from Team Core when larger blocks break something Gavin failed to account for (like upstream bandwidth being ~order-of-magnitude less than down, or catastrophic consensus failure).

XT could be an interesting pseudo-test of the thought experiment i've made a coupla times about perhaps Bitcoin needing nothing more than a big enough block size increase with built in upgrades from now until eternity.  or at least until an emergency patch is needed for an extraordinary event. 

What we need are multiple different cores, that yes might provide different visions for Bitcoin. That enables the users/miners to choose the right path and not a small set of devs.
legendary
Activity: 1153
Merit: 1000
July 23, 2015, 01:33:35 PM
this is an awesome quote:

The technology will be “of fundamental importance to Wall Street,” Nasdaq Chief Executive Officer Bob Greifeld said during a phone interview Thursday. “The benefits to the industry are immense and cannot be ignored.”


http://www.bloomberg.com/news/articles/2015-07-23/nasdaq-expects-to-be-first-exchange-to-use-bitcoin-technology

you know they're going to want cheap tx fees don't you?

Wall Street is also going to need a tad more than 3 tps as well.
legendary
Activity: 2044
Merit: 1005
July 23, 2015, 12:55:19 PM
oops, gold going negative again.

ah, that sweet smell of deflation.

Next jobs claim is gonna be a doozy... lowest claims for unemployment insurance since '74. Look for mickey mouse game to continue with a 300pt rise
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 12:42:43 PM
oops, gold going negative again.

ah, that sweet smell of deflation.
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 12:37:02 PM
iCE, didn't you say you own Hecla?  geez man, you gotta get outta that thing.  once it breaks the red support line, it's lights out:

legendary
Activity: 1764
Merit: 1002
July 23, 2015, 12:28:29 PM
Dow -115
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 12:27:25 PM
BlockCypher on board with bigger blocks.  their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack:

Large mempools are awful

The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost

What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?

Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.


https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4

Hmmm sorry but that's mischaracterizing the idea behind this article. They are in fact very neutral and make no mention of a preferred position on the matter.

Seems clear the culprit in this whole saga of "network disruption" was misconfigured architecture and apparently inadequate mempool implementations.

Quote
Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Evidently the core parameters were not optimized, something they suggest the core devs should concentrate and focus on maybe even before we think about block size. (I am aware there is already progress made toward alleviating this problem)

i heard a good argument the other day about this.  assuming that there are 1.1MB worth of real tx demand, that means not everyone can fit their tx into the next block and at minimum means 0.1MB worth of tx's have to wait until the next 10 min block to get thru no matter what fee they pay.  is Bitcoin a usable system at that point when some ppl may have to wait 20 min and even much longer if you start extrapolating out real use to say 100MB of real user demand?  also assume these ppl want max security of transacting on the MC.

Wouldn't a real 1.1MB transaction demand mean, that at some point fees would escalate an dsome people could not pay for their fee at all, thus locking them out of their own funds ? (Of course the demand will decrease when fees raise, but what happens if not ?)

yes, that's the pt.  it's unworkable for many.  and not just the poor.  i was annoyed the other day having to pay a 0.0002 tx fee to send to someone i did not want to get stuck in the backup of unconf tx's.  but it would get much worse with 1.1MB of real demand plus a spam attack.
legendary
Activity: 1473
Merit: 1086
July 23, 2015, 12:23:21 PM
BlockCypher on board with bigger blocks.  their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack:

Large mempools are awful

The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost

What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?

Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.


https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4

Hmmm sorry but that's mischaracterizing the idea behind this article. They are in fact very neutral and make no mention of a preferred position on the matter.

Seems clear the culprit in this whole saga of "network disruption" was misconfigured architecture and apparently inadequate mempool implementations.

Quote
Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Evidently the core parameters were not optimized, something they suggest the core devs should concentrate and focus on maybe even before we think about block size. (I am aware there is already progress made toward alleviating this problem)

i heard a good argument the other day about this.  assuming that there are 1.1MB worth of real tx demand, that means not everyone can fit their tx into the next block and at minimum means 0.1MB worth of tx's have to wait until the next 10 min block to get thru no matter what fee they pay.  is Bitcoin a usable system at that point when some ppl may have to wait 20 min and even much longer if you start extrapolating out real use to say 100MB of real user demand?  also assume these ppl want max security of transacting on the MC.

Wouldn't a real 1.1MB transaction demand mean, that at some point fees would escalate an dsome people could not pay for their fee at all, thus locking them out of their own funds ? (Of course the demand will decrease when fees raise, but what happens if not ?)
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 12:18:30 PM
remember that CVX chart i kept putting up?  well, the entire index is now following it down:



world's largest mine:



mining capitol of the world:



Canada, no mining slouch:



cheap food. you'll need it:

legendary
Activity: 1764
Merit: 1002
July 23, 2015, 11:41:26 AM
$DJT deepening it's losses.  $DJI getting dragged down:

legendary
Activity: 1764
Merit: 1002
July 23, 2015, 11:30:00 AM
BlockCypher on board with bigger blocks.  their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack:

Large mempools are awful

The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost

What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?

Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.


https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4

Hmmm sorry but that's mischaracterizing the idea behind this article. They are in fact very neutral and make no mention of a preferred position on the matter.

Seems clear the culprit in this whole saga of "network disruption" was misconfigured architecture and apparently inadequate mempool implementations.

Quote
Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Evidently the core parameters were not optimized, something they suggest the core devs should concentrate and focus on maybe even before we think about block size. (I am aware there is already progress made toward alleviating this problem)

i heard a good argument the other day about this.  assuming that there are 1.1MB worth of real tx demand, that means not everyone can fit their tx into the next block and at minimum means 0.1MB worth of tx's have to wait until the next 10 min block to get thru no matter what fee they pay.  is Bitcoin a usable system at that point when some ppl may have to wait 20 min and even much longer if you start extrapolating out real use to say 100MB of real user demand?  also assume these ppl want max security of transacting on the MC.
full member
Activity: 232
Merit: 100
July 23, 2015, 11:26:02 AM
cypherdoc,

where are you getting those pool hashrate distribution graphs?

what about these?

https://blockchain.info/pools?timespan=4days
http://blockinfo.org/pools

legendary
Activity: 1764
Merit: 1002
July 23, 2015, 11:18:06 AM
mining centralization?  what mining centralization?:

hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
July 23, 2015, 11:07:35 AM
BlockCypher on board with bigger blocks.  their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack:

Large mempools are awful

The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost

What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?

Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.


https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4

Hmmm sorry but that's mischaracterizing the idea behind this article. They are in fact very neutral and make no mention of a preferred position on the matter.

Seems clear the culprit in this whole saga of "network disruption" was misconfigured architecture and apparently inadequate mempool implementations.

Quote
Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Evidently the core parameters were not optimized, something they suggest the core devs should concentrate and focus on maybe even before we think about block size. (I am aware there is already progress made toward alleviating this problem)
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 11:00:11 AM
BlockCypher on board with bigger blocks.  their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack:

Large mempools are awful

The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.

Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost

What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?

Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.


https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4
hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
July 23, 2015, 10:56:24 AM
this is an awesome quote:

The technology will be “of fundamental importance to Wall Street,” Nasdaq Chief Executive Officer Bob Greifeld said during a phone interview Thursday. “The benefits to the industry are immense and cannot be ignored.”


http://www.bloomberg.com/news/articles/2015-07-23/nasdaq-expects-to-be-first-exchange-to-use-bitcoin-technology

you know they're going to want cheap tx fees don't you?

It reeks of desperation when you are spinning every story, news and thoughts of yours in some low-level childish "diss".

It'd be nice if this news could get us out of this price funk though!
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 10:48:01 AM
this is an awesome quote:

The technology will be “of fundamental importance to Wall Street,” Nasdaq Chief Executive Officer Bob Greifeld said during a phone interview Thursday. “The benefits to the industry are immense and cannot be ignored.”


http://www.bloomberg.com/news/articles/2015-07-23/nasdaq-expects-to-be-first-exchange-to-use-bitcoin-technology

you know they're going to want cheap tx fees don't you?
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 10:14:32 AM

Satoshi clearly didn't have a plan to manage the core devs, or even a code of conduct as it seems.  We need a Bitcoin-equivalent Hippocratic Oath for the core devs, as well as a way to tell them to buzz off.  Maybe the Foundation can get to work on that. Tongue 

They signed the Hippocratic Oath equivalent when they joined Blockstream - at least that is what was presented in the media, that they would never hurt bitcoin because of their work contracts.

how effective do you expect them to be when they depend on self determination?  how much does money & stock options affect their decision making?  what does talking with your VC investors everyday do to one's view of the world?  since bigger blocks is a no brainer even for SC's & LN, why the delay/stalling?

and yeah, i asked these very questions a year ago well before the block size debate was a "thing".
legendary
Activity: 1764
Merit: 1002
July 23, 2015, 10:12:41 AM
I wonder if the continuing GLD downtrend (with no near or medium-term end in sight) will spur some goldbugs to jump into BTC as they see it rise while their beloved PM falls. Could be one of the many contributing factors in the inevitable coming BULL run.

you mean this POS?  well yeah, that's the whole thrust of this thread for 4y running...:

Pages:
Jump to: