This is actually incredibly common.  For example, pretty much every commodity exchange asserts the right to pay you out in cash if they need to.  This is one of the reasons they say it is safe to trade more futures contracts for gold than actually exists.  That is just an example, everything else is done the same way too.

Shit, I'll pay extra for coins from newsworthy events.  Premium negotiable depending on the event and the purity of the coins as I get them.

In that case, good luck, but I don't think you'll get much traction with it.  A few people are greatly concerned with the magic numbers, but most of us don't care.  I've personally read dozens of threads on that subject, and so far no one has ever come up with a good argument why removing them would be beneficial.

This isn't physics where we kept getting 1/137 but didn't know why.  We already know why we have 600 and 2016, and we are ok with it.

You don't know the value of the current block's hash until after you hash it, and once you do that, you can't go back in and figure out which block you should have linked to, because that would change the hash and value.

Adding a block index to the block gives you the ability to move forward, but it also gives you full random access.  Why bother with a second link when you can instantly seek by index?

With random access, the only job left for hashes is to preserve ordering, that is to prove that Z came after Y came after X.  Someone creating a fake skipchain only has to make one trivial fake block per high value fake block, and make them in the right order, which is still billions and billions of times easier than creating a whole fake chain, at least over intervals long enough for this system to make any sense at all.

Ok, so I read this thread again and figured out the part that I had been missing.

When creating a new block, the skiphash points to the most recent block with a value higher than the previous block, not the block with the previous highest value ever.

I'm working through the implications of this, but at first glance, it does not appear to produce a chain of links that leads to a high value block.


The problem is that when you follow that first "up" link, the block you find there does not have a link to a value higher than itself, it has a link to a value higher than its predecessor.  If you want to find a block with a value higher than the block you are on, you have to go forward and then "up" from there, and forward links aren't possible.

Blocks don't currently have a concept of height.  If you add that too, you have more information, but not that much more.

And backing up doesn't give a new walk, ever.  Every block from X+1 to Y has a skiphash value of X, every block from Y+1 to Z has a skiphash value of Y.  If you back up one block to Z-1 you don't get a new walk, you get the exact same one again.

What do you do with the subinterval exactly?

You don't know any blocks between X and Y or Y and Z.  You don't know how many there are, you don't know what their difficulty is, you don't know what their values are, you don't know anything at all about those intervals, except that if you get block Y-1 (or Z-1) and the value is higher than Y (or Z), one of the blocks is lying.  But which one?

And since you don't know anything at all about these intervals, your estimated work is going to be W>X+(y*Y)+(z*Z) where y and z are probably greater than 2.  And I just don't see any way, using this method, to improve our estimates.

Again, I might be missing something, but from what I see, it looks like you are using knowledge of the blockchain in your estimates, which is a problem, since this is intended to be a system for finding out information about the blockchain that we assume that you do not actually possess.

It has neither false positives nor false negatives, because it simply doesn't do ANY verification whatsoever.

Consider this, you get a block, block Z.  You do not have block (Z-1), so you check the skiphash and ask for block Y.  You also don't have block (Y-1), so you check the skiphash again and ask for block X.  Now block X is one that you do have, so you stop there.  How much should you trust blocks Y and Z at this point?

The answer is "not at all" because you don't have ANY context for them.  You have NO idea what their difficulty should be, you have NO idea if they actually connect back to the real chain or not, and you have NO idea what their timestamps should be.  In short, you have no idea if these are real blocks, or if they were prepared just to attack you, and you won't have any idea until you verify the chain the hard way.

The skiphash chain means that when I create my attack chain, the difficulty values must follow some rules, but following those rules is still billions and billions of times easier than following the full network rules because you only need to make a couple of blocks.

Unless I'm wrong, of course.  It could be that the skiphash chain rules add up to a much stronger context than is immediately apparent to me.

Ok, I get it now.  It lets you jump backwards through the chain, leaping over portions until you get back to the first block that had this feature enabled.

But what's the point?

You can't trust this chain unless you've verified all of the blocks the hard way.  And if you've done that, why do you care about following these links back?

Notice that building a couple of phony blocks that look legit when viewed in this chain is trivial compared to building a couple of phony blocks to fool the real chain.  And by trivial, I mean billions and billions of times easier.

I am completely missing the point of this.

Block X includes a hash of block (X-1) so that you can be sure that block X follows block (X-1).  What is the point of including a hash of block (X-y) where y varies (but in practice will usually be either that one insanely lucky block from a while back or a block about halfway through the last difficulty bump)?

And how does this magically let you jump around the chain?

If you really need to override this behavior, you should be able to use the raw transaction API.

Also, the client won't include generated coins in the balance or new transactions until 120 blocks have passed.  I just mention it for completeness.

No, phoenix is actually measuring the actual hashrate of the card.  Everything else is an estimate, and all of the estimates are based random proxies, and all of the proxies have means less than 100% of the actual hashrate (over infinite time).

Sorry, the evidence does not support your assertion.  summary, with a link to the book.

Barter came first, then debt, then money.

My forum avatar is a Sumerian word (amagi) meaning "freedom".  Literally, the first sign (ama) means "mother" and the second sign (gi₄) is the verb "to restore".  Together, they are an idiom understood to mean freedom.  Sumerians had a complex economic system centered around their temples.  Writing itself was invented in the temples of Sumer to facilitate exactly this accounting of debts.  People would get themselves into debt and end up essentially selling themselves into slavery to settle up.  Over time, this turned out to be a problem, because people don't like being slaves, so if there were too many, they had a tendency to revolt and wreck up the place.  So, the jubilee was invented, where debts were wiped out, slaves set free (and able to go home to their mothers, hence the idiom), etc, every few years or so.

This was all well established at least 2000 years before money was invented.  And for all we know, even thousands of years earlier (it is really hard to pin down intangible concepts like debt prior to the invention of writing, but it is very clear that writing was invented for accounting).

The placement of the decimal is arbitrary.  Any place where you would want to place it will be just as arbitrary.  Except that if we get in the habit of changing it a lot, it becomes difficult (or impossible) to do understand value over time (which is why we allow governments to inflate currency).

Actually, commerce predates money by thousands of years.  Money was invented to account for debt, not wealth.

This thread again?

Once the block size limit is approached, miners will prioritize transactions based on fees.  Actually, they'll probably do that for other reasons long before it becomes necessary because of block size.

And there are several other potential reasons why we might need to do a hard fork in the future, so we can bundle them up if we need to.

Yeah, if you can dig that up, let me know.  I'll include it in p2pcoin.

There is actually a 0.4.3 version that is on the fixed version of p2pool.

http://www.jerviss.org/bitcointalk.org/p2pcoin/

I haven't posted them here because they also have version 0.6.2 of bitcoind, which has problems.  My understanding was that the version of p2pool that was included in 0.4.1 wasn't the version causing problems on the network.  Let me know if I'm wrong about that.  I'll try to spin up a 0.6.99 setup for testing before the weekend too.

P.S.  My 4 nodes of p2pcoin are all running 0.4.3, which has the 3.1 release of p2pool.  I suspect that my nodes represent a decent fraction of all p2pcoin nodes in the world.

There is actually a 0.4.3 version that is on the fixed version of p2pool.

http://www.jerviss.org/bitcointalk.org/p2pcoin/

I haven't posted them here because they also have version 0.6.2 of bitcoind, which has problems.  My understanding was that the version of p2pool that was included in 0.4.1 wasn't the version causing problems on the network.  Let me know if I'm wrong about that.  I'll try to spin up a 0.6.99 setup for testing before the weekend too.

P.S.  My 4 nodes of p2pcoin are all running 0.4.3, which has the 3.1 release of p2pool.  I suspect that my nodes represent a decent fraction of all p2pcoin nodes in the world.