Gold collapsing. Bitcoin UP.

[justusranvier]

Does this post show up for anyone else?

https://www.reddit.com/r/Bitcoin/comments/3a5f1v/mike_hearn_on_those_who_want_all_scaling_to_be/cs9jehy

I think it might have been censored.

[dEBRUYNE]

Does this post show up for anyone else?

https://www.reddit.com/r/Bitcoin/comments/3a5f1v/mike_hearn_on_those_who_want_all_scaling_to_be/cs9jehy

I think it might have been censored.

Shows up just fine here.

[TPTB_need_war]

For the expansionist here, what do you think?  Should we compromise at 8MB?  Personally I am ok with that, esp if an automatic periodic increase is baked in.

http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size

EDIT: page 1337!  gotta have something substantive on it :-)

i'm ok with it with the automatic expansion.  but i'm alittle concerned with the miner voting for expansion.  why just them and is voting really the way we want to go?

Yes the BIP 100 voting scheme seems a bit under developed at this point.  The problem is that POW mining is the only way to prove independent existence, this is the basis of distributed consensus -- you can easily create a bunch of fake AWS "full" nodes for example -- 1000 nodes just forward requests to a single full node.  And if you could solve the voting problem without using mining, you could use that solution to remove mining from consensus (i.e. from bitcoin).

One way to prove unique nodes is to require that every node use asymmetric functions to encode the data to be stored, with uniquifying "salt".  This is essentially hashing but backwards.

For example, every node chooses a unique 256bit identifier (salt).  Then for every 8 or 16 bits of blockchain data Di, it finds and stores Xi such that Hash(Xi + identifier + i) = Di (where "+" means "append").

This search happens continually as the blockchain is being created.

Now a client can validate the uniqueness of storage by another node by requesting random chunks of data from the node.  The node responds with its ID and Xi0-i1.  The client can then quickly validate this by running the hash function and comparing the result to its own blockchain.

A "full" node (one that is calculating this data and storing it as the blockchain is created) will be able to respond quickly where one that is not doing so will have to calculate the reverse hash function (essentially a random search like mining but easier because only 8 or 16 bits) on the fly.

Once you have this "proof of storage" you might be able to turn it into allowing node voting...

So someone rents hard disk space on Amazon AWS during the voting period and becomes many unique entities.

You were correct that there is no way to prove one computer, one vote. PoW doesn't work by voting. It works by random chance. The only problem PoW solves is consensus on ordering.

Ah I grow weary in this thread.

U repeated exactly what I said.  And then didn't read my partial soln

Ahem, try reading again. You proposed proof-of-storage as a potential means to voting.

Prior proof-of-storage (https://bitcointalk.org/index.php?topic=310323.0) "wastes" storage like POW "wastes" CPU.  It proves that storage exists.  The proposal above proves that a unique copy of the blockchain is stored somewhere.  This is much more valuable than proof that storage exists so it is perhaps better named proof-of-full-node.  The reason you can't just rent hard disk space on AWS to fake this out is because you need to calculate the inverse hash for every byte of the blockchain, salted by your node id.  The designer can choose how hard this is so it could take (say) a normal computer 6 months to do the entire 5 year blockchain. So the proof of storage is backed by POW which makes it hard to calculate the values on-the-fly.  You could rent a bunch of AWS storage AND separately rent a supercomputer to individually calculate the hash-1 blockchain data, storing the result into AWS.  But if you do that, you actually HAVE N individual copies of the blockchain so would receive N votes.

Because I am basically arguing with myself here I will now criticize the approach's limitations.  It is possible that modifications to this approach could solve them:

1. "Difficulty" is chosen in advance, not dynamically.  This is problematic as processing power increases.
2. It takes a long time for a new node to become a provably "full" node.  Of course, nodes could become non-provably "full" nodes just by downloading the blockchain as is done today, and nodes could advertise themselves as partly provable, receiving a partial vote...
3. The provable blockchain could be constructed by many CPUs running in parallel... is this a problem?  If so we could force serialization by salting Xi with Xi-1.
4. The system functions as a real-time interactive proof.  There is no way store a historical proof that a node was full on date D.  Bitcoin-style POW+blockchain does store historical proof of computation power.

Okay I got it now (I was very fatigued before prior reply and you didn't give any high level description). It is a historic proof that an entity was winning PoW blocks. So basically you have to set a threshold as to what level of cumulative PoW difficulty constitutes a vote, thus a centralized party decides what class of voter is included.

This is representative governance, because the users can't vote and those with more PoW can vote more times (creating numerous sockpuppets which is essentially analogous to my prior rebuttal). Representative governance is even more prone to capture by the Logic of Collective Action.

Bitcoin has no choice but to head these sort of perilous directions because the fundamental design is flawed.

If Bitcoin's design would scale without intervention, we wouldn't be seeing the need to do this.

[justusranvier]

Does this post show up for anyone else?

https://www.reddit.com/r/Bitcoin/comments/3a5f1v/mike_hearn_on_those_who_want_all_scaling_to_be/cs9jehy

I think it might have been censored.

Shows up just fine here.

Now it does for me as well.

I think the auto moderator may have grabbed it for a few minutes, which makes me wonder exactly what kind of setting theymos is using for it.

[TPTB_need_war]

Does this post show up for anyone else?

https://www.reddit.com/r/Bitcoin/comments/3a5f1v/mike_hearn_on_those_who_want_all_scaling_to_be/cs9jehy

I think it might have been censored.

Shows up just fine here.

Now it does for me as well.

I think the auto moderator may have grabbed it for a few minutes, which makes me wonder exactly what kind of setting theymos is using for it.

Note to Blockstream, compromise on a BIP and increase the block size already (and don't blablah about you already suggested they propose a BIP, Gavinmike aren't leaders, etc ... get a compromise done with as few words as possible). You are being out maneuvered politically and will be painted as the bad guys if you continue to write more rebuttals to Mike Hearn. STFU (with the diatribes from Adam) and live to fight another day. Stop that nonsense policy on the bitcoin.org that is divisive.

To Adam and Gregory, when you joined Bitcoin you implicitly agreed that it was "one for all and all for one". If you do anything politically to violate that, even if with good intentions to protect Bitcoin from a mad rush towards centralization or technical breakage as the Coinbase et al drive up TPS rapidly towards Visa scale, then you are violating your own interests believe it or not.

Instead of fighting your battle on the political front, go get clever on your technical work and make an end run around what you fear. STFU and reach compromise asap so you can live to fight another day.

Yes Gavinmike are diluting your power. They know what they are doing. You better know they can do it. If you are wise, you will rescue the clout you still have and retain some of it by using your political power less auspiciously (or let's say don't try to paint yourselves as the good guys, because it makes people sneer or skeptical when they read those diatribes that reflect on your egos more than on the reality of the situation) so you can win some concessions on the rate of increase.

Adam and Gregory are engineers and ostensibly thus far not very astute political scientists.

They apparently can't see that Gavinmike purposely incited them to fight in order to drive a wedge between them and more than 50% of the power in the community. It doesn't matter who is right, because both directions are flawed thus whomever resists forward movement will be the bad guys. The most astute action on their part is to not fight in public.

[thezerg]

For the expansionist here, what do you think?  Should we compromise at 8MB?  Personally I am ok with that, esp if an automatic periodic increase is baked in.

http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size

EDIT: page 1337!  gotta have something substantive on it :-)

i'm ok with it with the automatic expansion.  but i'm alittle concerned with the miner voting for expansion.  why just them and is voting really the way we want to go?

Yes the BIP 100 voting scheme seems a bit under developed at this point.  The problem is that POW mining is the only way to prove independent existence, this is the basis of distributed consensus -- you can easily create a bunch of fake AWS "full" nodes for example -- 1000 nodes just forward requests to a single full node.  And if you could solve the voting problem without using mining, you could use that solution to remove mining from consensus (i.e. from bitcoin).

One way to prove unique nodes is to require that every node use asymmetric functions to encode the data to be stored, with uniquifying "salt".  This is essentially hashing but backwards.

For example, every node chooses a unique 256bit identifier (salt).  Then for every 8 or 16 bits of blockchain data Di, it finds and stores Xi such that Hash(Xi + identifier + i) = Di (where "+" means "append").

This search happens continually as the blockchain is being created.

Now a client can validate the uniqueness of storage by another node by requesting random chunks of data from the node.  The node responds with its ID and Xi0-i1.  The client can then quickly validate this by running the hash function and comparing the result to its own blockchain.

A "full" node (one that is calculating this data and storing it as the blockchain is created) will be able to respond quickly where one that is not doing so will have to calculate the reverse hash function (essentially a random search like mining but easier because only 8 or 16 bits) on the fly.

Once you have this "proof of storage" you might be able to turn it into allowing node voting...

So someone rents hard disk space on Amazon AWS during the voting period and becomes many unique entities.

You were correct that there is no way to prove one computer, one vote. PoW doesn't work by voting. It works by random chance. The only problem PoW solves is consensus on ordering.

Ah I grow weary in this thread.

U repeated exactly what I said.  And then didn't read my partial soln

Ahem, try reading again. You proposed proof-of-storage as a potential means to voting.

Prior proof-of-storage (https://bitcointalk.org/index.php?topic=310323.0) "wastes" storage like POW "wastes" CPU.  It proves that storage exists.  The proposal above proves that a unique copy of the blockchain is stored somewhere.  This is much more valuable than proof that storage exists so it is perhaps better named proof-of-full-node.  The reason you can't just rent hard disk space on AWS to fake this out is because you need to calculate the inverse hash for every byte of the blockchain, salted by your node id.  The designer can choose how hard this is so it could take (say) a normal computer 6 months to do the entire 5 year blockchain. So the proof of storage is backed by POW which makes it hard to calculate the values on-the-fly.  You could rent a bunch of AWS storage AND separately rent a supercomputer to individually calculate the hash-1 blockchain data, storing the result into AWS.  But if you do that, you actually HAVE N individual copies of the blockchain so would receive N votes.

Because I am basically arguing with myself here I will now criticize the approach's limitations.  It is possible that modifications to this approach could solve them:

1. "Difficulty" is chosen in advance, not dynamically.  This is problematic as processing power increases.
2. It takes a long time for a new node to become a provably "full" node.  Of course, nodes could become non-provably "full" nodes just by downloading the blockchain as is done today, and nodes could advertise themselves as partly provable, receiving a partial vote...
3. The provable blockchain could be constructed by many CPUs running in parallel... is this a problem?  If so we could force serialization by salting Xi with Xi-1.
4. The system functions as a real-time interactive proof.  There is no way store a historical proof that a node was full on date D.  Bitcoin-style POW+blockchain does store historical proof of computation power.

Okay I got it now (I was very fatigued before prior reply and you didn't give any high level description). It is a historic proof that an entity was winning PoW blocks. So basically you have to set a threshold as to what level of cumulative PoW difficulty constitutes a vote, thus a centralized party decides what class of voter is included.

This is representative governance, because the users can't vote and those with more PoW can vote more times (creating numerous sockpuppets). Representative governance is even more prone to capture by the Logic of Collective Action.

Bitcoin has no choice but to head these sort of perilous directions because the fundamental design is flawed.

If Bitcoin's design would scale without intervention, we wouldn't be seeing the need to do this.

I don't think you get it.  It is a proof that an entity is storing a UNIQUE copy of the blockchain.  What little prior PoS work I've read seems to prove that storage exists, or that a file is being stored.  Unfortunately they do not address the idea that you want to store a file in 2 places A & B and ensure that A & B are not in collusion and so the file is only stored one of the 2 locations.

Honestly I'm less interested in the BIP 100 voting scheme (and the usefulness of voting in general as a governance mechanism) as I am in healing the rift between miners and full nodes.  Clearly no-one is going to implement the above proposal for bitcoin just so full nodes can vote on BIP 100! :-)

Justus: I could see your post just fine.

[79b79aa8d5047da6d3XX]

link repost from adam's thread, in case you missed it:

http://www.bloomberg.com/news/articles/2015-06-17/rbs-customer-payments-missing-after-latest-technology-failure

[TPTB_need_war]

For the expansionist here, what do you think?  Should we compromise at 8MB?  Personally I am ok with that, esp if an automatic periodic increase is baked in.

http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size

EDIT: page 1337!  gotta have something substantive on it :-)

i'm ok with it with the automatic expansion.  but i'm alittle concerned with the miner voting for expansion.  why just them and is voting really the way we want to go?

Yes the BIP 100 voting scheme seems a bit under developed at this point.  The problem is that POW mining is the only way to prove independent existence, this is the basis of distributed consensus -- you can easily create a bunch of fake AWS "full" nodes for example -- 1000 nodes just forward requests to a single full node.  And if you could solve the voting problem without using mining, you could use that solution to remove mining from consensus (i.e. from bitcoin).

One way to prove unique nodes is to require that every node use asymmetric functions to encode the data to be stored, with uniquifying "salt".  This is essentially hashing but backwards.

For example, every node chooses a unique 256bit identifier (salt).  Then for every 8 or 16 bits of blockchain data Di, it finds and stores Xi such that Hash(Xi + identifier + i) = Di (where "+" means "append").

This search happens continually as the blockchain is being created.

Now a client can validate the uniqueness of storage by another node by requesting random chunks of data from the node.  The node responds with its ID and Xi0-i1.  The client can then quickly validate this by running the hash function and comparing the result to its own blockchain.

A "full" node (one that is calculating this data and storing it as the blockchain is created) will be able to respond quickly where one that is not doing so will have to calculate the reverse hash function (essentially a random search like mining but easier because only 8 or 16 bits) on the fly.

Once you have this "proof of storage" you might be able to turn it into allowing node voting...

So someone rents hard disk space on Amazon AWS during the voting period and becomes many unique entities.

You were correct that there is no way to prove one computer, one vote. PoW doesn't work by voting. It works by random chance. The only problem PoW solves is consensus on ordering.

Ah I grow weary in this thread.

U repeated exactly what I said.  And then didn't read my partial soln

Ahem, try reading again. You proposed proof-of-storage as a potential means to voting.

Prior proof-of-storage (https://bitcointalk.org/index.php?topic=310323.0) "wastes" storage like POW "wastes" CPU.  It proves that storage exists.  The proposal above proves that a unique copy of the blockchain is stored somewhere.  This is much more valuable than proof that storage exists so it is perhaps better named proof-of-full-node.  The reason you can't just rent hard disk space on AWS to fake this out is because you need to calculate the inverse hash for every byte of the blockchain, salted by your node id.  The designer can choose how hard this is so it could take (say) a normal computer 6 months to do the entire 5 year blockchain. So the proof of storage is backed by POW which makes it hard to calculate the values on-the-fly.  You could rent a bunch of AWS storage AND separately rent a supercomputer to individually calculate the hash-1 blockchain data, storing the result into AWS.  But if you do that, you actually HAVE N individual copies of the blockchain so would receive N votes.

Because I am basically arguing with myself here I will now criticize the approach's limitations.  It is possible that modifications to this approach could solve them:

1. "Difficulty" is chosen in advance, not dynamically.  This is problematic as processing power increases.
2. It takes a long time for a new node to become a provably "full" node.  Of course, nodes could become non-provably "full" nodes just by downloading the blockchain as is done today, and nodes could advertise themselves as partly provable, receiving a partial vote...
3. The provable blockchain could be constructed by many CPUs running in parallel... is this a problem?  If so we could force serialization by salting Xi with Xi-1.
4. The system functions as a real-time interactive proof.  There is no way store a historical proof that a node was full on date D.  Bitcoin-style POW+blockchain does store historical proof of computation power.

Okay I got it now (I was very fatigued before prior reply and you didn't give any high level description). It is a historic proof that an entity was winning PoW blocks. So basically you have to set a threshold as to what level of cumulative PoW difficulty constitutes a vote, thus a centralized party decides what class of voter is included.

This is representative governance, because the users can't vote and those with more PoW can vote more times (creating numerous sockpuppets). Representative governance is even more prone to capture by the Logic of Collective Action.

Bitcoin has no choice but to head these sort of perilous directions because the fundamental design is flawed.

If Bitcoin's design would scale without intervention, we wouldn't be seeing the need to do this.

I don't think you get it.  It is a proof that an entity is storing a UNIQUE copy of the blockchain.  What little prior PoS work I've read seems to prove that storage exists, or that a file is being stored.  Unfortunately they do not address the idea that you want to store a file in 2 places A & B and ensure that A & B are not in collusion and so the file is only stored one of the 2 locations.

Honestly I'm less interested in the BIP 100 voting scheme (and the usefulness of voting in general as a governance mechanism) as I am in healing the rift between miners and full nodes.  Clearly no-one is going to implement the above proposal for bitcoin just so full nodes can vote on BIP 100! :-)

If you are not talking about its utility for voting, then how can you say I don't get it, when I was responding to its utility for voting, since that is the context in which you sold your idea initially. And for voting it sucks as I explained because it is basically one vote for one hashrate. So you could simplify your idea into its functional equivalent which is a vote placed into each block, which is fundamentally what your idea does for voting (your idea adds the ability to scale up the threshold of how many blocks constitute one vote but I don't see how that is functionally any different than a threshold on the number of blocks of yes to constitute a yes vote).

Yes you could use one vote per block to vote for those who have stake. And I think that would be a horrendous design for the same reason I think PoS sucks compared to PoW, i.e. that the entropy (randomness) of the system is limited internally and thus is game-able. Whereas, PoW is only game-able from the 50% (actually 30% if propagation is an issue for selfish mining) vector, but I claim (awaiting peer review soon) that I have removed that attack vector from my design.

Apologies to rain on your design. You are obviously creative and contemplating new designs which I applaud. What happened to me is I started to think about the problem at a higher level of semantics and then I was able to make the breakthrough. Studying the math for selfish mining lead me to the concept that propagation delay was the enemy I was fighting.

[TPTB_need_war]

Chomsky's confrontation with a truther idiot:

https://www.youtube.com/watch?v=3i9ra-i6Knc

I watched it.

His arguments are:

1) If you don't do science through the establishment, then you are not doing science.

2) Only people trained in universities can be trusted to do peer review.

3) Bush was running the government (and not the DEEP STATE) and Bush's only objective was not "you are either for us or you are against us". He entirely sidesteps the point of 9/11 was to foist  "you are either for us or you are against us" on the entire world. And he substitutes a strawman, Hegelian dialectic for logic. He sidesteps the concept that the DEEP STATE plays many different elements against each other in order to retain control.

In short he is either knowingly acting as a gatekeeper, senile, or just not that smart. I would bet on the first conclusion.

[freakying99]

I sold some btc this morning on localbitcoins and then went and bought 3 ounces of gold.
Did I make the right choice?

[elux]

http://www.zerohedge.com/news/2015-06-17/greek-debt-committee-just-declared-all-debt-illegal-illegitimate-and-odious

[cypherdoc]

http://www.zerohedge.com/news/2015-06-17/greek-debt-committee-just-declared-all-debt-illegal-illegitimate-and-odious

this doesn't look good to me:

[cypherdoc]

I sold some btc this morning on localbitcoins and then went and bought 3 ounces of gold.
Did I make the right choice?

NO

[tvbcof]

Chomsky's confrontation with a truther idiot:

https://www.youtube.com/watch?v=3i9ra-i6Knc

I watched it.

His arguments are:

1) If you don't do science through the establishment, then you are not doing science.

2) Only people trained in universities can be trusted to do peer review.

3) Bush was running the government (and not the DEEP STATE) and Bush's only objective was not "you are either for us or you are against us". He entirely sidesteps the point of 9/11 was to foist  "you are either for us or you are against us" on the entire world. And he substitutes a strawman, Hegelian dialectic for logic. He sidesteps the concept that the DEEP STATE plays many different elements against each other in order to retain control.

In short he is either knowingly acting as a gatekeeper, senile, or just not that smart. I would bet on the first conclusion.

I'll agree with your bet.  Classic controlled opposition.  I have to think that Chomsky (and Kruggman) is fully aware of what 9/11 was all about but for whatever reason or set of reasons they believe that it is better to cover it up.  One of the strongest guesses about why this might be is that it is their job.

I'm not sure what the venue was, but one of the most amazing things I noticed was what the audience clapped about.  The programming to 'shut down' has been deeply and broadly implanted for sure.  As I continue to detach from the 'mainstream progressives', this is fast becoming the most disgusting attribute I notice in these people.

[rocks]

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

[cypherdoc]

JGarzik's proposal:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Wherein the central authority of developers to set block size is passed to the miners who vote (with the highs and lows dropped).

This seems to solve the issue of figuring out the right size a bit better than one person picking an arbitrary number.

It also moves the ball forward in automating the governance of the protocol.

There are a couple of things to like about this proposal.

The first is that miners voting on blocksize plus IBLT effectively guarantees the blocksize limit will be removed and the bitcoin MC will be allowed to scale as required. The reasoning is simple, IBLT only works if the majority of unconfirmed transactions are included in the next block. If transaction volume bumps against a blocksize limit, then a only a subset of transactions can be included in a block and the miner cannot transmit their block using IBLT and instead has to re-transmit the entire block, increasing the risk of being orphaned.

For example let's say that because of the blocksize limit, only 50% of unconfirmed transactions can be included in the block. Miners on the receiving end do not know which 50% of transactions are in the block and which 50% are not. This means they cannot use IBLT and have to transmit the entire block. However it is in miners' interest to use IBLT to reduce their orphan rate and because it enables them to easily include as many transactions as possible for fees.

Because of this it makes sense with IBLT that miners would favor keeping the blocksize limit high enough that it does act as a real limit, but rather constantly rises as needed to match user volume. It is essentially another way to get to Gavin's original proposal of doubling the limit every 2 years.

The second thing to like is it moves us toward the environment where miners themselves are voting on what bitcoin is. Not developers, not regulators, not users, not full nodes (which are subject to Sybil attacks), but miners who spend real work to vote.

It also will force pools to publicly announce their voting preferences, which in turns allows individual miners to see their preferences and decide which pool to switch to to match their own view. For example if most individual miners want to support larger blocks, but the larger chinese pools vote for 1MB limits, well we might just see miners switching to pools that match their views or that have the capability to grow properly. It brings back the true market, which this dev fight shows we don't have right now.

Personally I like this proposal the best right now.

the only problem with voting is that it seems to me that that could be gamed in some way. also, miners aren't forced to follow the results of a vote.  maybe better to leave voting out all together?  just set an automatic adjustment increase and let the market players adapt around it.

[cypherdoc]

big move in mkts.

must have been an FOMC anncmt...

[Adrian-x]

I sold some btc this morning on localbitcoins and then went and bought 3 ounces of gold.
Did I make the right choice?

Never go full retarded - I did something similar when bitcoin as about $10 and gold $2000. I'm hanging in here to say I told you so to cypher.

I have patients (and this new feeling called regret)

[cypherdoc]

big move in mkts.

must have been an FOMC anncmt...

Information received since the Federal Open Market Committee met in April suggests that economic activity has been expanding moderately after having changed little during the first quarter. The pace of job gains picked up while the unemployment rate remained steady. On balance, a range of labor market indicators suggests that underutilization of labor resources diminished somewhat. Growth in household spending has been moderate and the housing sector has shown some improvement; however, business fixed investment and net exports stayed soft. Inflation continued to run below the Committee's longer-run objective, partly reflecting earlier declines in energy prices and decreasing prices of non-energy imports; energy prices appear to have stabilized. Market-based measures of inflation compensation remain low; survey-based measures of longer-term inflation expectations have remained stable.

Consistent with its statutory mandate, the Committee seeks to foster maximum employment and price stability. The Committee expects that, with appropriate policy accommodation, economic activity will expand at a moderate pace, with labor market indicators continuing to move toward levels the Committee judges consistent with its dual mandate. The Committee continues to see the risks to the outlook for economic activity and the labor market as nearly balanced. Inflation is anticipated to remain near its recent low level in the near term, but the Committee expects inflation to rise gradually toward 2 percent over the medium term as the labor market improves further and the transitory effects of earlier declines in energy and import prices dissipate. The Committee continues to monitor inflation developments closely.

To support continued progress toward maximum employment and price stability, the Committee today reaffirmed its view that the current 0 to 1/4 percent target range for the federal funds rate remains appropriate. In determining how long to maintain this target range, the Committee will assess progress--both realized and expected--toward its objectives of maximum employment and 2 percent inflation. This assessment will take into account a wide range of information, including measures of labor market conditions, indicators of inflation pressures and inflation expectations, and readings on financial and international developments. The Committee anticipates that it will be appropriate to raise the target range for the federal funds rate when it has seen further improvement in the labor market and is reasonably confident that inflation will move back to its 2 percent objective over the medium term.

The Committee is maintaining its existing policy of reinvesting principal payments from its holdings of agency debt and agency mortgage-backed securities in agency mortgage-backed securities and of rolling over maturing Treasury securities at auction. This policy, by keeping the Committee's holdings of longer-term securities at sizable levels, should help maintain accommodative financial conditions.

When the Committee decides to begin to remove policy accommodation, it will take a balanced approach consistent with its longer-run goals of maximum employment and inflation of 2 percent. The Committee currently anticipates that, even after employment and inflation are near mandate-consistent levels, economic conditions may, for some time, warrant keeping the target federal funds rate below levels the Committee views as normal in the longer run.

Voting for the FOMC monetary policy action were: Janet L. Yellen, Chair; William C. Dudley, Vice Chairman; Lael Brainard; Charles L. Evans; Stanley Fischer; Jeffrey M. Lacker; Dennis P. Lockhart; Jerome H. Powell; Daniel K. Tarullo; and John C. Williams.
Read more at http://www.calculatedriskblog.com/#HDdC6iT89HzpgKlA.99

[molecular]

I sold some btc this morning on localbitcoins and then went and bought 3 ounces of gold.
Did I make the right choice?

Never go full retarded - I did something similar when bitcoin as about $10 and gold $2000. I'm hanging in here to say I told you so to cypher.

I did something similar, too (when bitcoin reached silver partity) and I was planning to do it again with gold parity (but it wasn't quite reached).

Now I'm not so sure any more if I will swap BTC <-> gold when parity is reached.

To answer freakying99: there are no wrong choices, just choices. You never know what it's good for or how the alternative would've played out. Sure, you can always isolate things and say stuff like: "I should've sold at $1160 and rebought at $160". But everything's connected and who knows, maybe you would've been run over buy a bus or crashed your Ferrari on cocaine had you done that.

The important thing is that you make the choice (not someone else) and that you actually make it and not let time make a choice for you (inaction). And of course also that you use the information, the resources (includes opinions of others) and tools available to you. That way one can learn from mistakes, improve tools and resources and one doesn't get into the habit of blaming others.