Bitcoin Forum
June 21, 2024, 06:46:33 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Virtual currency without block chain  (Read 1880 times)
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
September 14, 2014, 11:25:09 AM
Last edit: September 14, 2014, 11:44:35 AM by Anders
 #1

A virtual currency can be designed by issuing coins with unique ids connected to owners with cryptographic signatures. The coins are transferred between owners in this way:

1. The current owner A unlocks a coin with a private key.
2. A signs the coin with the new owner B's public key.
3. A registers the coin in a distributed hash table.
4. A sends a message to B about the coin having been transferred.
5. B checks the distributed hash table to verify ownership.

Coins of different values 1, 10, 100, 1000 and so on can be issued to make it practical. So for example if a person X wants to send 235 coins to person Y, then two 100, three 10 and five 1 coins are sent in the transaction.
beaver6
Member
**
Offline Offline

Activity: 63
Merit: 10


View Profile
September 14, 2014, 12:37:18 PM
 #2

A virtual currency without block chain ? Is that  a centrenlized coin?

Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
September 14, 2014, 01:22:16 PM
 #3

A virtual currency without block chain ? Is that  a centrenlized coin?

I guess the issuing of the coins will be centralized similar to pre-mined coins. Once a coin has been issued it will be fully decentralized and peer-to-peer.
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 03:58:53 AM
 #4

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/safecoin

Could be a brilliant solution. I haven't learned about it enough yet. Looks at face value to have a huge potential.
true-asset
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250

Uro: 1 URO = 1 metric tonne of Urea N46 fertilizer


View Profile WWW
October 03, 2014, 04:59:11 AM
 #5

Without a block chain, there will be no way to search the past transaction history.

Uro: A Real Long Term Currency, 1 URO = 1 metric tonne of Urea N46 fertilizer[/url]
Urea N46 tracks gradual increases in energy and food prices over the long term.
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 05:42:31 AM
 #6

Without a block chain, there will be no way to search the past transaction history.

Only one transaction back history! Grin But I heard that block chains can be built on top of MaidSafe.
trotter55
Member
**
Offline Offline

Activity: 65
Merit: 10


View Profile
October 03, 2014, 10:27:22 AM
 #7

Cryptonite has a mini-blockchain similar to your proposal, but it's not completely missing a block chain.

https://bitcointalk.org/index.php?topic=713538.520
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 11:49:03 AM
 #8

Cryptonite has a mini-blockchain similar to your proposal, but it's not completely missing a block chain.

https://bitcointalk.org/index.php?topic=713538.520

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.
sadface
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
October 03, 2014, 11:57:21 AM
 #9

check this:

https://bitcointalk.org/index.php?topic=614917.620

its not released yet, but will have what is called 'proof of consensus' and afaik no blockchain.
HunterMinerCrafter
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
October 03, 2014, 03:42:22 PM
 #10

check this:

https://bitcointalk.org/index.php?topic=614917.620

its not released yet, but will have what is called 'proof of consensus' and afaik no blockchain.

The developer himself has said, several times, that there is actually a block-chain.  This is also clearly visible from the source.

This coin will just use a mechanism similar to automated check-pointing in order to reduce burden of storing the chain history.  This carries with it some significant implications and caveats, including a potential "total kill switch" in the hands of the developer, as has been discussed on the thread.
HunterMinerCrafter
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
October 03, 2014, 03:48:38 PM
 #11

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.
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 04:31:37 PM
 #12

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.
HunterMinerCrafter
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
October 03, 2014, 05:02:23 PM
 #13

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.  Wink)

Quote
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.

Quote
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.
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 05:50:54 PM
 #14

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.  Wink)

Quote
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.

Quote
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.
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 06:25:50 PM
 #15

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.html

The 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.
HunterMinerCrafter
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
October 03, 2014, 06:31:23 PM
 #16

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!  Wink
HunterMinerCrafter
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
October 03, 2014, 06:33:07 PM
 #17

The part "trusted group of nodes" sounds shaky. Coins using a block chain are trustless.

Yes, safecoin uses a delegated trust model, which only serves to "re-centralize" the system.  This is precisely what we would seek to avoid, for many good reasons.
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 06:43:10 PM
 #18

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!  Wink

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.
Anders (OP)
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
October 03, 2014, 07:35:39 PM
 #19

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.)
krb91
Member
**
Offline Offline

Activity: 254
Merit: 10

Streamies Rocks!!!!


View Profile
October 03, 2014, 08:56:18 PM
 #20

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?

S T R E A M I E S -  Streaming in Anonimity  -  No rules
▬▬▬▬▬▬▬▬▬▬ ●●     Whitepaper Released    ●● ▬▬▬▬▬▬▬▬▬▬
DISCORD    -    BITCOINTALK    -    WEBSITE    -    EXCHANGE
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!