I want an entropykey.  Their website only accepts google wallet, which I refuse to use.

So, I'm looking for someone trustworthy to buy me one (or maybe a 10 pack), to be shipped to a US address, in exchange for BTC.  Any takers?

The distinction is subtle.  Debt and credit (savings) are different sides of the same coin, but which side you think is the head, and which is the tail, changes who you are.

With gold and bitcoin, it is:  give -> money -> receive
With dollars and ripple, it is: receive -> money -> give

They are really both part of a tangled knot of cycles and epicycles, but with any cycle, you have to pick a point to be the beginning/end, and that choice, as arbitrary as it seems, makes a world of difference in how you understand the cycle.

Time only flows in one direction, future consumption comes from current production, and current production comes from past investment.  These are essentially definitions of the words; it can be no other way.  But for a long time now, we've been willing to pretend that we can consume today and invest tomorrow.  And the difference is a just a matter of how we choose to see it, at first, but when we start to really believe it, we are no longer the same people.

Heh.  You do know that cars don't operate by tipping gasoline into a black hole, right?  All of the atoms are still here, so we can create as much gasoline and other hydrocarbon products as we want, at will.  However, right now, it is cheaper to pump it out of the ground than it is to sieve carbon and hydrogen out of the atmosphere and crack up so they can form long chains.

Oil is totally 100% renewable.  It is only "cheap oil" that is non-renewable.

At any rate, the "unit of account for oil sales gives dollars value" theory repeated by the OP is nonsense, and has been nonsense for decades now.  No one is holding dollars against their will for oil purchases or oil sales, at least not for more than a couple hundred milliseconds.  Google FOREX.

Apologies in advance, I've rewritten this post three times now trying to shorten it.  Sadly, each attempt has caused it to grow by at least a paragraph.  Just be thankful that I cut out the detour through the historic origins of debt and money.

Bitcoin and ripple are both attempts to make new electronic systems that more closely approach the abstract ideal of "money", but they do so in totally different ways.

Certain things have properties that make them more or less useful as money, but in the abstract sense, money is a means of splitting a barter transaction into two parts that can happen at different times, in different places, and between different people.

Essentially, if you buy a product or service from someone, you are getting wealth from them, and in return you give them money, which is (again, in the abstract sense) an IOU for wealth of similar value in the future.  They can then take that IOU and give it to someone else in exchange for a product or service.  In effect, they are performing a barter where they exchange one thing of value for another thing of value, with the money just as an intermediate step.  In the time that they are holding the money, they have given, but not yet received; they are owed a debt, not by one particular person, but by society in general.

Ripple is an attempt to transfer this abstract debt relationship into the electronic world, making something closer to the abstract ideal of "money" than the ledger and paper/coin system we use now.  The ripple system just helps turn your personal IOU that you give as payment into a general IOU, which is the same job that money does in a transaction.  In the end, both systems require a functional society willing and able to pay back those IOUs, and both systems can be open ended and (more or less) eternal.

All money, including bitcoin, ripple, dollars and even gold, are based on debt.  Holding gold means (more or less) that you have done something worth that gold's value, and you hope that in the future you'll be able to exchange that gold for something of similar value.  Dollars and ripple are the same, with a couple of subtle differences.  In dollars, certain players can create new debt (new dollars) at will, limited only by the willingness of people to accept them.  When you get a bank loan (or a credit card or whatever) that bank has created new dollars out of thin air by magic, limited only by their assessment of your ability to repay.  In ripple, everyone is a bank, and everyone can create money through magic, just by finding someone willing to accept it.

Gold and bitcoin, though based on debt/hope just dollars and ripple, have the advantage that no one can conjure them at will.  Gold and bitcoin are both past-looking, where holding gold or bitcoin is prima facie evidence that a party has already in the past done something of value for society.  Dollars and ripple are more forward looking, where one party has received something of value, and the other party is hoping that they will do something of similar value in the future to redeem that particular debt.

The forward looking version of money didn't grow up by accident.  It is a good system, and it works.  It has produced the amazing world we all live in today.  But it has also brought us horrifying tragedy, with new horrors brewing on the not-so-distant horizon.  I think that we are perched on a turning point in world history.  We will pick either the advantages and disadvantages of future-oriented systems like dollars and ripple, or we will pick the advantages and disadvantages of past-oriented systems like gold and bitcoin.  It isn't a one-sided choice, we are both gaining and losing either way.

But I suspect that the brewing storm will steer the next few centuries towards bitcoin (or something like it).

You don't lose the ability to recover.  You only lose the silent, automatic recovery that obfuscates the damage.  You, the human, is going to have a mess that you are personally going to have to deal with.  The difference is that in one scenario, you have no idea what happened or why, and in the other scenario, you have to clear out some invalid blocks and restart your node, but you know exactly why.


Also, I should point out that section 6 of the paper doesn't really apply here, because section 6 is written with the assumption that q < p, while the assumption in this thread is that q > p.  In this case, it means that we are assuming that the attacker will eventually overtake the honest network.  Your only protection in that case is to have done all transactions and converted all of your bitcoins to wealth prior to the block when the attacker publishes their chain that destroys the entire system.

Erm, don't take this the wrong way, but this seems like a strawman to me.  If an attacker has you isolated, they can already feed you bogus blocks, and there isn't a damn thing you can do about it.  In a parity proof-of-work system, when the isolation is broken, your node will resync with the rest of the world.  But the damage (to you) has already been done, it was done when you accepted blocks that you thought were current, but really weren't.  Throwing them out and loading the correct blocks doesn't fix anything, and might actually make it harder for you to realize what happened.

This is the trade in reality.
You get:  your node can fix itself when reconnected to the global network.
You pay:  The entire global network is vulnerable to hidden chains, whatever damage you suffered while disconnected is unchanged, you don't necessarily know that you were attacked.

Seems like a terrible trade to me.


The best part of my proposal is that it doesn't change the network rules at all.  It is still pure proof of work.  The only change is that the burden of proof for a reorganization is higher than it is now, and it scales with the amount of danger than such a reorganization represents.

Really?  Assuming that you have the transactions already, assembling them into valid blocks is incredibly easy.  Wasn't that the whole point of getblocktemplate?

Meh.  It will converge to near-universal agreement, and the nodes that don't converge to that agreement will know that they need to fix their shit manually.  In your terms, the "higher-level signal" would be a human, and I don't see that as a downside.  If you assume that an attacker can isolate some subset of the network and feed it garbage, then those nodes will need manual help one way or the other.  Why not take the safe and simple measure to protect the rest of the network?


Right now, they would have a 30x power advantage with their ASICs vs. the rest of the network currently running GPUs and FPGAs.  Once we've all switched to ASICs, all they will have is numeric superiority at more-or-less parity per unit.  That's a huge difference.

There is no step 7.  This attack is non-economic, meaning that the attacker has to be willing to burn a lot of wealth to do the attack.  This alone severely limits the categories of potential attackers, but it is not unreasonable to think that such an attacker might show up some day, so it deserves some attention.

To counter this, I proposed an exponential difficulty ramp for reorganizations.  Reorgs of up to X blocks (6 might be a good value for X) happen normally, with the longer chain winning.  Reorgs beyond X blocks require Y^(B-X) more difficulty in the new chain than the old chain, where B is the number of blocks to be thrown out.  Y could be pretty small and still give good safety, maybe 1.1 or 1.05.  For example, for X=6 and Y=1.05, reversing 100 blocks would need ~50 times the total network power, not half.  And replacing 144 blocks (1 day) would require ~400 times the network power.  Recipients of large transactions would be able to decide on their own how long they needed to wait to meet their own safety requirements.  Selling a billion dollar widget?  Wait a week, and then the attacker would need 1*10²¹ times the total network hashing power to unbury it.


Yes, reorgs happen naturally every few days.  All transactions from the discarded blocks go back into the memory pool, and if they are still valid in the new context, they will be retransmitted and eventually end up in new blocks.


ultraprune stores rollback information for exactly this reason, even though it doesn't actually do any pruning yet.


Well, even if the rest of the network forgets, each node scans their own wallet from time to time, and any transactions they see in their local wallet database but not in blocks and not in memory get retransmitted.  So, as long as your wallet is still live, the transactions still have a way to get back on the network.  Hilariously, this causes problems today because if you realize that a transaction isn't going to make it into a block within a reasonable amount of time, there isn't a simple way to prevent your wallet from keeping it alive.  You have to hack your wallet database to delete that transaction so that the network can forget about it, so that you can double spend it with a fee or whatever.

Also, there are ways to fix it, but they aren't particularly pleasant.  One ad hoc way to get things right would be to trace the fork back to the initial divergence, and then hardcode that first block's hash into a blacklist.  This would only help people that upgrade to the new blacklist-enabled version, but basically everyone would want to make that upgrade.  The blacklist could just be a text file in the datadir, managed by each node's user individually; they would have a powerful incentive to not put anything other than obvious attack blocks in it.

What I think really saves us from this scenario is that hashing capacity of sufficient power for the attack does not currently exist in the world, in a readily available form.  There just aren't enough physical Radeon's in the world, in purchasable form, for someone to gather them easily or quickly, even with a huge budget.  The attacker's best bet would be to spend about a year developing an ASIC, but that attack window is not going to stay open much longer.

There are no "requirements" for getting into a block, beyond having valid signatures and not-yet-spent inputs.*

But, if you aren't mining yourself, or don't have sufficient hashing power to get somewhat frequent blocks, then the rules for transaction relaying are effectively the rules for getting other people to put your transactions into their blocks.

* I suspect that we long ago passed the point where the majority of blocks are generated by software other than the reference client.  I could very easily be wrong about that, but I think that most pools are running custom software to generate blocks according to their own local rules.

No.  Yes.

See Scrybe's post just before this one.

That document does not describe any theory, does not appear to be about economics so much as jealousy, and can hardly be thought of as comprehensive.  Zero for three.

Meh.  The value field is such a small part of the transaction that making it wider is probably cheaper overall than having to put up with the headaches of scaled formats.


Most of the constants in bitcoin are totally arbitrary.  I don't see any reason to believe that 2⁶⁴ base units would be "better" in any meaningful way than ~2⁵¹, and the extra bits allow for headroom in accounting.

Keynes had more to say than just "print more".  I see a lot of his other blather in there.

I hate to be the one to say it, but that freicoin manifesto is a cesspit of keynesian gibberish and populist nonsense.  Calling it a "comprehensive economic theory" is to go zero for three.

A histogram would be a more useful view.

Yes, a transaction can have an input in the same block.  The reference client requires that the input come before the output, whether in a previous block, or in the same block.

Philosophically, I prefer to think of all of the transactions in a block as being simultaneous, but officially, they happen in the order they appear in the block.  The official view has a few advantages, such as avoiding loops.

I, for one, would LOVE to hear it.

Double check the endianness of your prevhash.  In the genesis block, it is all zeros, meaning that you still get the right result even if you have it backwards.

Just a guess.