The double spending problem is completely eliminated by having unique coin IDs and using digital signatures. The worst attack nodes could do would be to mess up the distributed hash table.
If you can "mess up" the DHT then you can double spend. For example, send some coins to an exchange, trade them for btc, then scrub the transaction from the dht (perhaps via Sybil attack) and send the same coins off to some second exchange and sell them again. Having the coins identified and signed doesn't really help the first exchange. You can't replace transactions. The unique ID for a coin makes it stored as a single value. By messing up I mean that an attacker can put wrong information into the DHT or delete information. If the attacker manages to delete a coin and then tries to put it in again with another owner then the digital signature would have to be cracked for that to be a successful attack.I see what you mean now. There is no complete history for the transactions so an attacker can simply make up a transaction and sign it correctly. Yes, then messing up the DHT can lead to double spend. |
|
|
|
Hmm... Wait a minute. If a central authority like the U.S. government issued the coins AND run the transaction servers as a public serve then they could use digital signatures even for the nodes in the network with an ordinary distributed hash table implentation. They could issue a bunch of 10 cent, $1, $10, $100, ... and so on coins. Very efficiently and to a small public service cost. The wallets can be digitally signed with a national ID system (a potential Orwellian danger perhaps but anyway) and that would eliminate the need for messy cold storage with paper wallets and all that cumbersome management. That's something for Obama to look into.  |
|
|
|
the double spend and counterfeit problems are solved, yet the problem of ensuring consistent data in the DHT remains to be solved.
One of the key realizations to be had is that these are essentially the same concern. The double spending problem is completely eliminated by having unique coin IDs and using digital signatures. The worst attack nodes could do would be to mess up the distributed hash table. Admittedly, that has to be solved too but the double spending and counterfeit problems are solved in this way without the need for a block chain. |
|
|
|
the double spend and counterfeit problems are solved, yet the problem of ensuring consistent data in the DHT remains to be solved.
One of the key realizations to be had is that these are essentially the same concern. (The coins in my proposal are minted by a central authority but after having been minted the coins are fully decentralized and peer-to-peer.)
Also (arguably) undesirable, for many good reasons. So just Ripple. Minted by a central authority, maintained by a few trusted nodes of their own. Changing their marketcap whenever they feel like it. No, the idea is to have the system without a block chain to be trustless once the coins are in circulation. The central authority would be a government or something like that. For example the U.S. government could issue the virtual currency with the same value as the USD. And then those coins would be like digital peer-to-peer cash with very fast transaction times. And the transactions can have zero transaction fees with servers run by the government as a public service. So it would be a limited use case but it could be used in competition with existing cryptocurrencies. |
|
|
|
Blockless blockchain is possible, but locks are necessary to reduce transaction size. If that was not there, each transaction will take all the data with it and it will be bloated soon.
Bloat can be dealt with since disk space and communication speed follow an exponential progress similar to Moore's law. But what about transaction speeds? Paying for a coffee at Starbucks should only take a few seconds at most. 0-confirmation transactions or payment channels can solve that problem for coins with a block chain. It would be better though if the real transactions would be fast. |
|
|
|
There have been a few occasions when a trusted CA certificates were compromised and had to be revoked by all browsers. Would that compromise a coins security if it was dependent on CAs?
I don't know but it sounds like a dangerous risk. And even if that wasn't a problem, there would still be the problem of having to rely on third party authorities. Even if only one big trusted authority was used, like VeriSign, there would be the problem of only "elite" nodes being able to operate since the big trusted authority would have monopoly on certificates and could demand obscene amounts of money for licenses. And even with healthy competition among several certificate providers they would have to charge quite a lot of money anyway since they would need to have rigorous control procedures for those who they sold licenses to. And personally I wouldn't even trust a big so-called "trusted" central authority, at least not for a system that's meant to remain robust for centuries. |
|
|
|
|
One problem with a PoW that requires lots of memory is that sooner or later, special custom integrated circuits would be developed, even with gigabytes of memory. And if those chips are more demanding to design and manufacture it would lead to even more centralization than the SHA-256d ASICs.
|
|
|
|
As I expected, a distributed hash table can be messed up by mischievous nodes. Kademlia is an ordinary DHT and it must be modified for security in ways like: "The proposed KadS network is almost identical to the Kademlia network, i.e. it consists of the described RPCs and implements the same XOR metric. The major extension to the protocol is that every node is equipped with a public/private key-pair signed by a trusted CA. This extends the normal Kademlia network to a public key infrastructure (PKI) in which every communication is encrypted, every node can be trusted and only verified nodes can participate in the network." -- http://blog.philippheckel.com/2009/03/16/kads-a-secure-version-of-the-kademlia-protocol/That's inadequate since it means trust and third party authorities. By using unique coin IDs and digital signatures for both minting and transactions, the double spend and counterfeit problems are solved, yet the problem of ensuring consistent data in the DHT remains to be solved. (The coins in my proposal are minted by a central authority but after having been minted the coins are fully decentralized and peer-to-peer.) |
|
|
|
Ok, a distributed real-time server could be tricky to develop, but if we assume it's possible, then each 5-second block of transactions would prevent double spending since all transactions in the block are checked for double spending. How to reach consensus for what transactions should be included may be problematic although that too could perhaps be possible to solve.
Maybe we could use something that can logically assert the passage of time, independent of any one peer's notion of it, like an extract-able hash prefix collision puzzle, scaled continuously to match the resources put toward it so as to consistently keep a set pace. Maybe we could avoid double spending by having this puzzle be directly interdependent with transaction selection, and linearly dependent on each prior instance of the puzzle. Maybe we could reach consensus about transaction selection based on some simple rules related to management of an in-memory cache of pending transactions at each node. Maybe there "just isn't" any alternative. Maybe any design meeting the same goals (like using some weighted modular lottery biased by account balances (PoStake) or some pre-coordinated signers' roster (PoActivity)) will actually be entirely isomorphic to what I've just described. Maybe anything that is not isomorphic to this inherently has the wrong security assurances. Yes, it sounds like you are well on your way to reinventing the block-chain. Enjoy the journey, it is quite a scenic road to walk!  In my proposal each coin has a unique ID in the distributed hash table. That prevents double spending since there can only be one owner for each coin. The problem is how to ensure that the data in the DHT is consistent. Or is a DHT automatically always consistent? I guess I need to learn more about DHTs. |
|
|
|
Safecoin handles it in this way: "A separate persona, the TransactionManager, is proposed to handle all the token-related transactions. A TransactionManager group will be a trusted group of nodes which are closest to any given transaction identity. ... The PUT request for safecoin is "no duplication allowed", i.e. if there is already a safecoin data having same name (first 32 bits), the new put request shall be rejected." -- http://maidsafe.net/SystemDocs/user_perspective/safecoin.htmlThe part "trusted group of nodes" sounds shaky. Coins using a block chain are trustless. My idea of a currency without a block chain is that it should be trustless. It could however be that "trusted group of nodes" is a trust based on cryptography or something like that. Then Safecoin is trustless too. |
|
|
|
I thought that maybe a distributed real-time server could solve that.
It certainly could. The block-chain *is* that distributed time server, this is the very function it serves. (We have no other proven design for such a beast. ) For example, the calendar time is taken to be a median value among the nodes in the network.
It is not so simple. Sybil could just overwhelm and warp the median, for example. And then every let's say 5 seconds a chuck of transactions is committed to the distributed hash table.
The definition of "committed" becomes very problematic, here. This is concerning because this committal is strictly necessary as part of avoiding double spends. Without the proof chain securing consensus over a full history you end up in some messy situations. In any case you need "someone" to select and order transaction sequences *before* consensus is reached, and consensus has to be reached in a way that precludes re-selecting or re-ordering those transactions in the process, or after the fact, by any party. Further, you need to do so in a way that reaches at least a "50% + 1" security threshold in order to be able to assert majority consensus, which is much more difficult than it might initially seem. Most (arguably "all") DHT structures fall to only 1/3 collusion, in the best of cases. Bitcoin was the first p2p network to demonstrate any security threshold above this norm. Ok, a distributed real-time server could be tricky to develop, but if we assume it's possible, then each 5-second block of transactions would prevent double spending since all transactions in the block are checked for double spending. How to reach consensus for what transactions should be included may be problematic although that too could perhaps be possible to solve. |
|
|
|
5. B checks the distributed hash table to verify ownership.
The problem here is that it relies on some assurances that a DHT, alone, cannot provide. If a DHT registry were "enough" by itself then we would've had a working bitcoin in the mid 90s, trivially. Unfortunately the "Merkle proof chaining" mechanism of the blocks really is strictly necessary in order to avoid double spend and assure consistent transaction selection and processing. Without such a mechanism the most simple of attacks against the network could easily be used to disrupt the entire system. I thought that maybe a distributed real-time server could solve that. For example, the calendar time is taken to be a median value among the nodes in the network. And then every let's say 5 seconds a chunk of transactions is committed to the distributed hash table. For a transaction to be valid it must be signed with the current coin owner's private key. |
|
|
|
One minute block time is good for many purposes but I'm looking for transactions that can be done in a few seconds. I don't know yet though how fast Safecoin is. |
|
|
|
Without a block chain, there will be no way to search the past transaction history.
Only one transaction back history! But I heard that block chains can be built on top of MaidSafe. |
|
|
|
There is already a virtual currency without a block chain! Safecoin is a part of MaidSafe: "Safecoin is the currency of the SAFE network and a mechanism to incentivise and reward end users and developers as well as provide access to network services. End users who provide their unused computing resources to the network, called Farmers are rewarded in safecoin, while application developers, called Builders earn safecoin in proportion to how often their applications are used. ... Safecoins are managed by the network’s Transaction Manager. This is the SAFE equivalent to the block chain, however, in SAFE’s case it is unchained, keeping record of only the existing and previous owner. In this respect, safecoin should be thought of as digital cash." -- http://maidsafe.net/safecoinCould be a brilliant solution. I haven't learned about it enough yet. Looks at face value to have a huge potential. |
|
|
|
|
Anyone interested in implementing an elliptic curve PoW? As a test of concept. Of course, first the algorithm has to be examined to see if it would work. I don't know enough about this kind of programming myself. It could be fun for someone savvy in these kinds of algorithms. Lots of parameters to specify, modify, tweak and measure. And it's copyright and license free.
|
|
|
|
|
Large memory PoW with fast verification, third version:
The miner sends h and λi as proof.
h is the block hash value.
λi is a key for an elliptic curve point.
i is the value h MOD N.
N is the number of keys used.
The verifier calculates a point pi on the elliptic curve. The proof is valid if pi = λiGj and h XOR hash(λi) is less than the target difficulty, where λi > 1. Gj is a member of a set G with predefined constant points on the elliptic curve. The points in G are chosen so that there is at least one nontrivial solution to pi = λiGj for all points pi.
The point pi is calculated by setting x to hash(i) MOD M, where M is the order of the finite field FM for the elliptic curve y2 = x3 + 7. N < C < M, where C is a value for 1% hash collisions. If no solution y is found for x, then x = x + 1 until a solution is found.
Since the calculations of pi and λiGj are easy the verification is fast without the need for much memory. The miner on the other hand needs the value λi which is difficult to calculate and therefore the miner has to store all keys λi, i = 0, ... N-1 in memory as pre-calculated values.
|
|
|
|
|
Ouch. The equation pi = λiG has no general solution in the sense that there is always at least one nontrivial value λi for all points pi. I have to go back to the drawing board.
|
|
|
|
|
I read that there are actually some elliptic curves that are cryptographically weak. For the PoW algorithm it's possible to deliberately choose a weak elliptic curve, since the keys only need to be difficult enough to calculate. That would prevent the finding of future algorithms that improve the calculation speed.
EDIT: On a second thought, a weak elliptic curve can in the future be found to be even weaker. So it's best to stick with a tested elliptic curve, such as the one used in Bitcoin for digital signatures: y2 = x3 + 7.
|
|
|
|
This is similar to, but more complicated than Momentum, which asks for a simple hash collision.
I read that Momentum was only used in the initial phase of BitShares. Now they use a form of proof of stake. Are there any other altcoins that have used or are using Momentum? I also read some of the Momentum whitepaper, but not enough to understand how the algorithm works. |
|
|
|
|
Show Posts
