Gold collapsing. Bitcoin UP.

[cypherdoc]

maybe Scotland?

http://www.coindesk.com/independent-scotland-cryptocurrency-testbed/

[1714503681]

1714503681

[1714503681]

1714503681

[1714503681]

1714503681

[FNG]

maybe Scotland?

http://www.coindesk.com/independent-scotland-cryptocurrency-testbed/

If you'd like to listen where he brought it up 

http://www.brrmedia.com/event/124409/sp-ag-020714

Check the guys bio   http://www.rba.gov.au/about-rba/people/ag-fin-mkts.html

He Chairs a committee at the BIS (Central Bank for Central Banks)

[FNG]

Gold demand getting out of hand in India. CB going to dump some

http://www.zerohedge.com/news/2014-07-03/india%E2%80%99s-central-bank-sell-gold-market-exchange-gold-bank-england

[zeetubes]

Gold demand getting out of hand in India. CB going to dump some

http://www.zerohedge.com/news/2014-07-03/india%E2%80%99s-central-bank-sell-gold-market-exchange-gold-bank-england

I read a comment somewhere that perhaps the UK could use some extra gold and this helps them out more than it does India. maybe true.

[NewLiberty]

but isn't the speed (7 tx/s) different than the block size limit (1MB/block)?

Sort of, but they are related.  The real limit is the 1 MB blocksize limit.  1 MB every 10 minutes is 10^6 bytes / (10 min x 60 sec/min) = 1,667 bytes per second and 1 MB every 8 minutes is 2,084 bytes per second.  The "seven transactions per second" concept apparently stems from the scalability wiki.  At 1,667 bytes/s, it implicitly assumes that each TX is about 240 bytes (or 300 bytes at 2,084 bytes/s).

The average TX in bytes is most certainly larger than both of these figures (although I don't have a reference on hand).  Simple 1-input/2-output TXs like this are 226 bytes.  Txs that have more inputs or more outputs, or more complex scripts, will be larger.  In other words, the network would likely hit the 1 MB/block bandwidth limit at less than seven transactions per second.  

In any case, the bitcoin community seems to think of the limit as "seven transactions per second."  Although this is an approximation, I think it is useful nonetheless.

Block interval tends less than 10 minutes, so 7/sec is pretty close to our average limit.

[NewLiberty]

actually illegal in many places of the world due to the trading platform and the contracts being deemed securities. This is likely why no one has shown up to complete with them yet.

well then, this should catch up with them too.  

i'm not recommending anyone doing this but you could report them if you wanted to stop them from doing this.

The point being that they are actually being run by a far more powerful entity, one that is capable of breaking these sorts of rules with no repercussions. They may have not started off that way but let's face it, that area of the world is filled with corruption and who wouldn't want to get their paws all over the most powerful global currency ever invented? Normal miner incentives don't affect these sorts of players the same way.

you may be right and i'm glad to see that solutions are being worked on as proposed in Hearn's blog post.  as long as these solutions stay away from the main core protocol.

iirc, Bitfury themselves pulled 1.5 PH/s from ghash during this issue so there are solutions being implemented as we speak. also Petamine voted to move to p2pool.  i may in fact move to p2pool as soon as some of the software issues get cleared up.

P2pool is a solution.
bitfury repointing isnt. 

Control remains centralized, the repointing can be for as long as desired and then pointed elsewhere.  The control remains with the bitfury/cex/ghash Keiretsu

Repointing does hide the centralization though.  It relaxes folks.  Makes people think that all is well, when instead we are on the edge or over it, and can't even tell.

It also encourages folks to do nothing or even to join GHash because "look it isn't so bad now and they are protecting us".  It makes me wonder if sometimes people can't even hear their own thoughts with any critical review.

[kehtolo]

I really think there should be something done to limit pools to a Maximum of 20% - I've no idea how this would work, as I am ignorant of mining..
(i tried it out in the early days, but left it as my GPU wasn't suitable, couldn't afford a good one at the time)

Anyway.. perhaps even some sort of general agreement between the pools, or something in the protocol that won't recognise pools if they go over 25%
They get a warning at 20% and have time to take action to avoid reaching 25%
Or that pools won't accept extra hash if they reach 20%

Would be better for all.. At least i think it would but i'm sure there are issues that i'm not thinking about.

EDIT: There is nothing stopping an organisation having 2 pools at 20% = centralization by a different name, but at least there would be no danger of a 51% attack.

[NewLiberty]

I really think there should be something done to limit pools to a Maximum of 20% - I've no idea how this would work, as I am ignorant of mining..
(i tried it out in the early days, but left it as my GPU wasn't suitable, couldn't afford a good one at the time)

Anyway.. perhaps even some sort of general agreement between the pools, or something in the protocol that won't recognise pools if they go over 25%
They get a warning at 20% and have time to take action to avoid reaching 25%
Or that pools won't accept extra hash if they reach 20%

Would be better for all.. At least i think it would but i'm sure there are issues that i'm not thinking about.

EDIT: There is nothing stopping an organisation having 2 pools at 20% = centralization by a different name, but at least there would be no danger of a 51% attack.

This wouldn't be bitcoin. 

Maybe an alt coin could do it.  We'd need to see it work for a significant amount of time.  Counter measures have counter-counter measures.

The way the percentage is measured is more or less, after the fact.
Its done by looking at who solved the blocks.  You are proposing a way of measuring the hash power that went into that solve other than just estimating based on time and averages, numbers of hashes submitted, etc.

[flipperfish]

but isn't the speed (7 tx/s) different than the block size limit (1MB/block)?

The block size determines the transactions per second. Allowing a larger block size means that more transactions can be included per block.

thx for making me review that. i was getting confused with data rates.  is there a maximum MB/s that constrains the network speed?

At least there is no hard limit. There seems to be a soft limit depending on the network bandwidth of single nodes, though. If a single node has not enough bandwidth to download the next block within 10 minutes, it can't catch up with the blockchain. E.g. a typical private residential internet connection has about 2 MB/s (?) receiving bandwidth. When blocksize is larger than 2 MB/s * 10 * 60 s = 1200 MB, home nodes can't download the blocks in time and will be left behind. Luckily it's the receiving speed that is relevant here, which is a lot faster than sending speed on the typical home internet line.

EDIT: There is nothing stopping an organisation having 2 pools at 20% = centralization by a different name, but at least there would be no danger of a 51% attack.

The danger of attacks possible by controling more than 50% of hash power are still there, even if a single organization decides to operate 2 pools. The organization simply has to coordinate the attacks across both its pools.
I think having one organization operating 2 pools is even worse than having one organization operating one pool. More so, if it's not known by the public, that both pools belong to the single organization. The real danger is hidden in this case, which is worse, than a danger the public knows about.

[cypherdoc]

The way the percentage is measured is more or less, after the fact.
Its done by looking at who solved the blocks.  You are proposing a way of measuring the hash power that went into that solve other than just estimating based on time and averages, numbers of have shes submitted, etc.

I thought it was measured  by who relayed the block?

[cypherdoc]

but isn't the speed (7 tx/s) different than the block size limit (1MB/block)?

The block size determines the transactions per second. Allowing a larger block size means that more transactions can be included per block.

thx for making me review that. i was getting confused with data rates.  is there a maximum MB/s that constrains the network speed?

At least there is no hard limit. There seems to be a soft limit depending on the network bandwidth of single nodes, though. If a single node has not enough bandwidth to download the next block within 10 minutes, it can't catch up with the blockchain. E.g. a typical private residential internet connection has about 2 MB/s (?) receiving bandwidth. When blocksize is larger than 2 MB/s * 10 * 60 s = 1200 MB, home nodes can't download the blocks in time and will be left behind. Luckily it's the receiving speed that is relevant here, which is a lot faster than sending speed on the typical home internet line.

EDIT: There is nothing stopping an organisation having 2 pools at 20% = centralization by a different name, but at least there would be no danger of a 51% attack.

The danger of attacks possible by controling more than 50% of hash power are still there, even if a single organization decides to operate 2 pools. The organization simply has to coordinate the attacks across both its pools.
I think having one organization operating 2 pools is even worse than having one organization operating one pool. More so, if it's not known by the public, that both pools belong to the single organization. The real danger is hidden in this case, which is worse, than a danger the public knows about.

So right now with ghash at 37%, you'd have to assume Discus, at 15%, was owned or influenced by ghash.  That's pretty far fetched.

[chriswilmer]

Something that critics (or hysterical enthusiasts) miss about 51% attacks is the possibility of defensive mining.

Basically, as long as you have a large stake in Bitcoin (or the Bitcoin economy), then you would be willing to mine at a loss to thwart any entity from approaching 51%. Think companies like BitPay or Coinbase, or people who hold 10,000+ bitcoins. Those entities could invest significant resources in mining and make it that much harder for a malicious super-miner. It's always economically irrational for a super-miner to be malicious, but this would make it even more painful.

[cypherdoc]

I found it interesting to read the comments of the ghash owner who said that pulling a  double spend is actually quite difficult from an  internal technical stand point.

I  wonder what he was talking about?  

[cypherdoc]

Pool miners solve blocks; how do pool owners hold back blocks secretly without the miner who solved the block noticing?

[Peter R]

Something that critics (or hysterical enthusiasts) miss about 51% attacks is the possibility of defensive mining.

Basically, as long as you have a large stake in Bitcoin (or the Bitcoin economy), then you would be willing to mine at a loss to thwart any entity from approaching 51%. Think companies like BitPay or Coinbase, or people who hold 10,000+ bitcoins. Those entities could invest significant resources in mining and make it that much harder for a malicious super-miner. It's always economically irrational for a super-miner to be malicious, but this would make it even more painful.

Quoted because this is important yet often ignored.

[cypherdoc]

Something that critics (or hysterical enthusiasts) miss about 51% attacks is the possibility of defensive mining.

Basically, as long as you have a large stake in Bitcoin (or the Bitcoin economy), then you would be willing to mine at a loss to thwart any entity from approaching 51%. Think companies like BitPay or Coinbase, or people who hold 10,000+ bitcoins. Those entities could invest significant resources in mining and make it that much harder for a malicious super-miner. It's always economically irrational for a super-miner to be malicious, but this would make it even more painful.

Quoted because this is important yet often ignored.

i don't think an economic 51% attack scenario is a problem.  the incentive structure is too well set up for it to happen.

it's the non-economically driven one thats interesting to consider altho even that one is difficult to imagine given the repercussions of attempting it.

[justusranvier]

it's the non-economically driven one thats interesting to consider altho even that one is difficult to imagine given the repercussions of attempting it.

It's impossible to secure against all possible non-economically driven attacks.

At the extreme end of the spectrum, the US military could defeat Bitcoin by using nuclear weapons to end all human life on the planet.
At the other end of the spectrum, there is an adversary who is willing to lose a maximum of 1 Satoshi in order to attack the network.

Somewhere between those two extremes there's a boundary between the attacks which we can successfully defend against, and the attacks we shouldn't even bother defending against.

[cypherdoc]

accelerating to the downside on volume:

[cypherdoc]

likewise with Litecoin:

[Colonel Panic]

Alt players moving out of risky sideshows, now that its time to strap back onto the confirmed bull.