pfft, it was reasonably solved a long time ago: https://bitcointalk.org/index.php?topic=505.0

I also independently came up with the solution in 2011: https://bitcointalk.org/index.php?topic=44682.0

Requires a direct connection, unreliable.

The true beauty of being able to include say an 8 byte message, is that you can have the seller sign a message saying "I am giving you widget X for Y coins paid to Z address" then hash that and include it as the receipt of the transaction. Later you can prove you have made payment. (Though not forever.)

This was an idea I had come up with while developing encoin/decrits. It's a nice feature, and it allows increased anonymity as say, someone using a bank-like intermediary can prove to the intermediary that the transaction is his, or simply have the intermediary approve the receipt first, and the transaction will be credited to his account. Network privacy++

This coin will have it's 2nd birthday in a little over a month.

Bump for dramatic thread title change.

"Probably won't" should not be enough for people who claim to want liberty and freedom.


Yay, back in the same spot we're at now. This sounds great. I love how the future of bitcoin is summed up with it "probably won't" be wall street all over again.

Fuck. That.

At that point, millions of people are defrauded by bitcoin. It deflates until the mass exodus when everyone else is left holding the bag.

Instead, creating a totally better system before that happens would be the moral obligation. See my signature for some modest suggestions.

Bitcoin's monetary supply is increasing. The price trend on most scales is quite deflationary.


It is, as the OP has surmised and I agree with, one of bitcoin's silliest shortcomings. Pandora is out of the box, and there will not be one cryptocurrency to rule them all in a deflationary system, because people will just use or create others when bitcoin is annoying. Alternatively, if you drop the pyramid distribution scheme, there is no longer an incentive to leave the currency for one that is less one-sided. An example if this is proposed here.

When taken at different scales and time intervals, bitcoin will always have big periods of price inflation and big periods of price deflation because a fixed money supply is easily manipulated. Because of the properties of other cryptocurrencies follow the same scheme, bitcoin is ultimately relegated to being one of many. New, deflationary currencies are likely to be "the cure" for manipulation. Instead, if the money supply were unbound in the first place, everyone could stick around and live in utopia.

If I hadn't bought drugs with the few bitcoins I had once, I'd donate to you. Phenomenal post.

You are correct, I blew it on that one. I had a nagging suspicion I was forgetting something.


Sounds reasonable, I think it can still be subject to some manipulation, but it's fairly vague and requires a lot of investment to save money with a depreciating currency.

I don't see needing much trust in the time stamp. Just adjust the demurrage rate infrequently in the same vein as difficulty. You can't legitimately speed it up, because nodes won't accept blocks from the future. You can't legitimately slow it down, because honest miners will put an honest time. The attack vector is no worse than someone with a 51% hashrate stalling the network, and it will perform much more accurately when the network is honest.


[ad for decrits]
PS - Stable currency needs a stable network. Some new details.
[/ad for decrits]

First of all, you have to rely on an authority, just not a central one. Bitcoin's authority is hashing power, Decrits' is consensus. Now while consensus at first may seem wishy-washy, the fact is that it is a very public, very distributed network where any collusion attempt by the consensus will be out in the open, recorded, for all to see and prove. But I think you are willing to agree on that point. Even in absolute worst-case scenarios where EvilCorp owns a significant amount of real shares and has a target's connection to the network surrounded, whatever manipulation was attempted will be recorded, and the victim can later prove malfeasance.

A bit of a side bar for sec. There is (brag) a bit of ingenuity in how the transaction block chain works (nb: as proposed in my notes). kokjo assumed earlier in this thread before asking that the order that transactions are approved in is ever in the control of one node or several nodes. It is not. The chain goes in a random order that is changed only by adding the hash of every single SH's signature on the prior CB to some random function. This is the reason why SHs will lose their deposit if they do not sign the CB. They either can't affect the randomness of this function, or lose 3,000 DCR or whatever the price may be for a share. They are also required to sign the "potential" CB (I have to clarify this in the OP) during their assigned TB, meaning that if they do not sign it then (by missing their TB), they will receive a soft strike*. The very last person to sign the CB could make for two potential outcomes [one of them might be better than losing 3,000 DCR], but I think there are ways to avoid that too--I'm going to go too far on a tangent though. Generating a distributed, unmanipulatable random number for the network is significantly important though, and was something I solved only recently. It's like 50 hours of ideating and 10 lines of code.

* - this is to prevent repeated attempts to learn information about other SH's signatures

The point of writing all that was to say this: even if EvilCorp controls, say, 80% of the shares and a strong enough control over the CN or is somehow man-in-the-middle attacking a MITM-resistant network (section 2.B) to pull off a massive currency heist, the odds of a TB being forcibly missed because EvilCorp temporarily can't let you see anything from TheGoodGuys during the time frame of this heist are very high. Say the transaction is for 100kDCR, a very prudent person would want to wait for enough transaction blocks to pass to cover at least 100kDCR, i.e. 34 (5 and a half minutes) if the share price is 3kDCR.. It would be another tangent to explain why covering it is important. Anyways, someone determine the odds of EvilCorp owning all 34 in a row. It's low. So if EvilCorp manages to pull this off, they must pull it off in a window where they control every single SH for as long as the victim wants to wait. Because if a TB in the chain is missing, the victim has a thought of "what if...?" Missing TBs are only slight hiccups for regular, every day transactions, but they have big implications for big transactions. This all requires a lot of detail though into how massively awesome I believe consensus-based security can be, and this post is already too long and hasn't answered your question.



Now, as long as the client has the genesis block for the network it is interested in participating in and at no point has the consensus massively colluded to do something nefarious*, then the newbie node can very reasonably determine which network is the correct one in the face of competing networks.

* - This would be common knowledge, like mtgox being hacked or something, except a lot of people just sacrificed a lot of money.

There are two ways for money to be removed from the "share ledger"--1) being destroyed for doing something bad (such as not agreeing to the consensus, section 1.B.ii), 2) by the share's owner withdrawing it. In situation 1), we have no way to determine whether or not the shareholder actually did something bad--only that the consensus agreed he did. Even if we did store a record of a bad transaction block as proof, because the state of the network is routinely pruned, it will be meaningless evidence in the future. In situation 2), the shareholder signs a hash of the shareholder record as they remove their share. While the shareholder record would not likely be kept forever (an ongoing hash could though), it is pretty heavily bound by around 100 bytes for every share purchased and 100 bytes for every share legitimately removed. If you've had 500,000 shareholders in the history of the network, you have 50-100MB of data you need to download, plus the headers of the transaction blocks from present back to 100% consensus or whatever makes you feel comfortable (100 or so bytes X the number of current shareholders).

What this does is create an ongoing consensus. Each member who has left the network has written, "yup, everything's cool" and everyone else still there is around to confirm it. Members that are no longer in the network and did not sign out lost 3,000 DCR. If that percentage is, say, 1%, then there's a monumental chance that you are on the correct network.

A smart client would interpret the data this way: if there were originally 100 SHs in the genesis block, and 99 of them never signed out and are no longer present, the maximum consensus that this chain can have is 1%, even if there are now 500,000 SHs. In the future, the real network is likely to have somewhere around 95-98% consensus I would think, as 3,000DCR should be a lot of money to people if Decrits is useful and popular--but there will be people that accidentally or intentionally lose their shares over the history of the network. If the network is currently split in an ongoing attack, if EvilCorp was not in on it almost from the start of the network, it will be very, very difficult for EvilCorp to look like the better network, even to a complete newbie node, but the real network might also be below 50%, so it is not 100% cut and dried. Or maybe it is, because there will not be a rational reason to do this.

Essentially, if EvilCorp has a mad plan and buys up 101,000 shares when the network has currently 100,000 shares to perform a "51% attack", assuming no one signed out in the mean time, EvilCorp will have a network with 0% consensus and TheGoodGuys will have 49% consensus. That's why a 99% attack doesn't work either. This is not a network-enforced choice but it's a brain-dead obvious one.

The money in mintchip has a centralized distribution architecture, even if it can be used in a decentralized way. It does not require hashing power to be secure, it requires whatever signature algorithm the chips use to remain secure from people trying to hack the chip.

Give me some time to get home and write a post and I will show you why your attack is ineffective in more detail, aaaxn.

kokjo, your attack just goes back to the general network overtake attack, which assuming the dishonest network plays by the rules (what's the point?) it will be up to the people to decide which network is honest, which boils down to where the amazons and best buys and their friends who are not massive colluders intent on destroying the currency will be.

Except either you buy enough SHs for real money to cause trouble, in which case you have spent massive amounts of money to accomplish fooling unconnected new nodes (and they will still be able to detect the mass "exodus" of people who just let their money get destroyed), or you enter into the network split scenario where you still have to be on your best behavior because everyone is watching. These are things I will get into later.

You are correct. I am distracted atm. I never thought much on this because it is, for the most part, an edge case. In the case of seeing two networks (the node is not surrounded), the node that is being deceptive was either part of both (signing the CB) at the same time, still part of both (in which case the deception is obvious), or signed out of the honest network at the same time (still obvious), or had his stake destroyed by the honest network because he went "missing". If he's still in both, he's going to get his share destroyed for provably signing an incorrect block, assuming the one being deceived eventually realizes this and still has the info.

If the node is only getting one view of the internet, this is always going to be an easy to manipulate case, just like it is for bitcoin. The client could warn against "hey there's a time when there was only 1 SH -- this network is unlikely to be honest" type thing.

I can explain more if necessary a little later

The seats won't be for sale, they will be given away. But yes your question already led me to thinking about this, so the proper way to do it would be to have just 1 original SH with an initial transaction to bring in the rest. This would mean only one person could do it. There might be a way to use it for just this transaction and then destroy it, or perhaps use a one time signature. Kudos to bringing this to my attention though, but the whole bootstrapping process has never been something I've worried that much about. Save it for when things are actually getting close.

In any case, relying on the genesis block would only be a last ditch resort, if it were ever even needed. If the network became ubiquitous, there would be many ways to find the honest network. There is not much an attacker can do to a new node. Anyone accepting payment would be really dumb to verify this acceptance through any means other than its accepted channels.

Last paragraph of this post. There have to be SHs that exist at the beginning of the network or you'll have to resort to PoW to begin the network which will involve adding a whole slew of bootstrap code just to avoid giving money away to the "early adopters" when the late adopters also receive free money in Decrits. An attacker can't create a false history because he'd have to get the genesis block SHs to agree to it.

I forgot to mention a timestamp (or datestamp) would be included with transactions. To avoid needing all transactions ever there would be a maximum TTL after which txes would no longer have to be checked. This was my initial idea anyway to avoid the problem you mentioned in the other thread. I had a wiki for encoin that went into some more detail about this stuff, but it's lost now. I just wanted to have a basis to know that it could be done and then worry about the nitty gritty later because I had bigger things to focus on like a stable money supply.

Although now I've been trying to think of a way to consolidate the account ledger with the changes that need to be made to the ledger, while trying to keep in-memory requirements low and keeping db hits low. I think this may affect how everything ends up playing out.

The network maintains the list of shareholders, but the shareholders do update the list. A new node could conceivably be fooled by an attacking network, but this can be addressed in two ways: 1) something similar to the "lock block" in bitcoin built in to the client, or 2) knowing the "genesis block" and retrieving the all-time shareholder join/leave history which still requires knowing the genesis block (ergo having something built-in to the client). Bitcoin can't take option 2 because anyone could build a new chain from the genesis block.

Any node that has ever gotten the state of the shareholders of the network (via the shareholder section of the consensus block) will either know which network is correct or will know that the network has split. As long as a node can be sure it was on the right network once, it can't ever be fooled. The shareholder stuff probably won't be held forever, but 5 or 10 years isn't much data at all for this type of security. I'll explain in some more detail later.

A nice advantage of an idea like Decrits (see sig), is that in addition to being blockchain-less, the proof-of-consensus mechanism requires only only about 100 bytes per shareholder for a light client to see that consensus has been reached. ~100k people securing the network? A 10MB download from virtually any historical point to verify any hash tree in the account block (a few kb). I can go into more detail, but this is something I went over a looong time ago when first trying to change bitcoin. It can be done and I have the game plan for it.

"Transaction is (from_pubkey, from_last_spend, destination_pub_key). You prove your ownership by signing it with private key of sending address."

Don't forget (from_acct_num, amt, to_acct_num) for a total of 15 or so bytes + signature. If you are going to use blocks of accounts, you need to take advantage of assigning them an integer instead of a key for bandwidth savings.

:facepalm: