Topic: Consensusless One-Destination-Units Pool (Read 247 times)

Here's the second part:

For the purpose of desinging ODU, inflation can be viewed as too much money that can be spent. This topic is not covered here, it's only excluded to concentrate on ODU's very own problem: collateral values.

It means that different address lengths exist, and values of units in a small address space are taken and given from payees who did not take part in a transaction. So a client has to consider collateral values as bein there involuntarily. Consequently it has to evaluate the intrinsic, displayed value by minifying these shares that everyone gets.

In other words, the client will only show a balance it can control and judge. It loweres values when collateral received money will lower the need for it and by this the intrinsic value. It doesn't show the difficulty_value accumulated in the graph, but a "share".

Although it's possible that not everything of a balance can succesfully be routed, the client estimates the statistically valuable amount, which does not consider the routing.

The calculation

The share of a unit, of that the client knows no preimage, is zero, because it cannot be spent.

Shares of units with known preimage are calculated by adding the lowered difficulty_value of each connected and spent unit:

For each connected unit that was spent:


This encourages a client to make use of the cooperative routing system, because easy to route units with a short address length are of too low value. The average of input and output address length encourages both payer and payee to do so.

Deriving address length and addresses


All address data is taken from the public name (identity), which itself is the result of a relatively slow hash (15ms here, 128 bit output, if longer *was ok Equihash would be the better option.) No fixed address length is predefined, instead the client tries to evaluate its impact. Ideally, mining power goes into the unit value, without allowing for other approaches that could change the intrinsic value compared to the value displayed in the client.

For this to work, a seperate mechanism may be necessary, which determines the preferable address length.

Here's compiling (MinGW g++) pseudo code covering the ideas for the unit structure and the evaluation: https://pastebin.com/z4m1dbSZ
It mines 3 valid (but not necessarily usable) units and displays their estimated intrinsic value. In short: Hard to route units are worth more. What's still missing is the routing.

Yes, the spending looks like this, but let me explain it in detail:

You want to mine money. You look for a puzzle solution.

After one hour you found a puzzle solution, now you have money.

The puzzle solution is an image where hash(image) is a very low target number. It is at the same time the [unit identity].

You can spend the [unit identity] only to one single address that is derived from [unit identity].
(There's an alternative to this later in the text. **)

Back to the spending. It's done by publishing [spending preimage], which is another image here, namely the preimage of the [unit identity]:

[spending preimage] ---hashed to---> [unit identity] ---hashed to---> [difficulty target]

Spending does not need a signature, because you would only sign one possible message. For that you can also publish the [spending preimage], which is shorter than a signature.

When spending takes place, the payee's client will receive [spending preimage] from the payer and do the two serial hashes. Then it calculates the value of the unit by calculating the difficulty of the target that the unit meets, and inserts the unit to the graph. The graph is the user's pocket where both unspendable and spendable (preimage != nil) units are.

The graph will eventually add the value to all destination units. There are several [unit identities] that share the same input address, because addresses have been shortened to e.g. 32 bit.

Spending in a cycle does not take place. The graph does have cycles in it, but the evaluation algorithm stops before descending into a previously processed node. There is no feedback.

The problem is something like inflation. Let's call it ODU-inflation, because it has two factors:
- uncontrolled money supply
- collaterally received money due to short/colliding input/output addresses

An offline client would have the problem that it does not see the ODU-inflation going on. So it will not know the intrinsic value and what to give in exchange when it receives ODU money.

** Another part is mining over previously chosen adresses - versus - deriving addresses from the mining puzzle solution.

When users define the addresses of a unit themselves, instead of being forced to use derived addresses, then they will want to mine units that have a smaller adresss space which comes with even more ODU-inflation, because they want to be able to spend money without doing much mining or routing.

I'm not a mathematician so it is a little hard to follow your explanations but I'm trying .  This is a pretty complex idea.

Lets see if I understand you correctly:

We start with a pool of tons of big numbers called "units". Each of these units are a coin.  Somehow we can verify if a number is indeed a valid unit.  Now we hopefully can find a "nonce" that the hash of that nonce gives the unit we are after.  When this is done the unit is owned by you...but only so long as you spend it first.  To spend it you hash the unit, nonce, and destination address.  This creates a new number and this is the new resurrected (spendable) unit.  Now to spend this again someone would need to find a nonce for that new number.  I guess if you don't want someone "mining your coin away from you" you would have to keep this new unit identity a secret until you want to spend it.  you give someone the number who you want to pay.  And they mine for a nonce that solves it.  So no one would know who owns what coin until it is already spent!  Interesting.  I think you would have to keep mining the same coin over and over so no one else spends it...you have to have the longest blockchain for that coin so you can guarantee you can spend it whenever you want...

So basically you "mine" to be able to spend that unit.  And if someone else tries to "spend" that unit by finding another nonce for it, if you already spent it then the unit they found the nonce for is no longer valid.

So basically instead of having one blockchain with many "coins" like bitcoin, we have a blockchain for each and every coin, correct?

Thanks for the link to your project. I'll have a look at it and will tell you asap what I think.

I have used the term Bitcoin only to cover many assumptions about entities (wallet, money, signing, peer to peer) at once and explain the proposed system, let's call it ODU. It's true that Bitcoin relies on one version of the ledger being correct about order and timestamps. But it's irrelevant in ODU because the chain will consequently become a pool. Timestamps play no immediate role as ODU has not yet a difficulty adjustment. One of the qualities of adjusted difficulty is that you get a constant blocktime for a constantly updated consensus. But this part is removed, so it makes more sense to think about difficulty adjustment for controlling the money supply.

Imagine ODU like this: There is no chain of blocks, only pool of units. A unit is only the hash of a preimage. This pool is the ledger, and a client will have to grow its knowledge about the pool, but it never has to correct it in the sense of ordering the data or trusting an arbitrary node. All the client would rely on for a single unit is:

• Does the unit satisfy being a unit? This is true if target_hash(unit) < target
• Has it been spent? This is true if at least one node can provide the client a preimage so that mining_hash(preimage) = unit
• What was the destination of the spending? What is the destination if the client can spend it? This is destination_hash(preimage)

target_hash = hash_128_bit
mining_hash = hash_128_bit
destination_hash = hash_32_bit

The task for the client is not getting a correct ledger, but using a growing set of units as database. The client needs to collect, store and evaluate the units, adding the value of each spent unit to its destination. This is a graph where the client counts at the graph nodes.
The next task for the client is to talk to other nodes, so it can evaluate, use and dismiss routes in order to pay. It must find those own spendable units that, when cooperating with others, make the payee's set of units profit the most. The reward for this complicated task is that the system does not constantly need much power for transactions, only for mining which you could in theory let happen only once in a while without stopping everyone from using the actual money transfer system.

One thing I'm not sure if you understand is that PoW is not just to prevent double spending (which probabilistic sending may help solve double spending) but also to make it so we can choose which ledger of transactions is correct.  In your method how do we know who's version of the ledger is accepted?  The way PoW solves this is allows a miner selected at random to provide the accepted ledger.  The miner who mines a block is selected as the person who's ledger is considered correct.  Is it actually correct though?  Mabye, mabye not but the process of PoW makes it so people have to invest a lot of resources to get their version of the ledger accepted so this discourages attacks.

How does your system verify who's version of the ledger is correct?

Also check out www.ir.hn (IOU reciprocol handoff network) ; it seems to me you are tending towards this type of system I have invented.  I believe it is my most important idea in digital currency and solves trust problem, censorship problem by governments, exchange problem, 51% attack problem,  Proof of Work problem, etc.

Thanks for reading it. The major part is about stochastics.

A minor part is this: For the sake of simplicity and also for using the sybil attack as the way of mining, we define that the wallet and the coin are the same thing.
Think of emptying your wallet completely in favour for another wallet. If you always did this for paying, there's less of a difference between the coin and the wallet. I'll call this thing a unit from now on.

The best way to explain the major part of the idea is this chain of reasoning:

Q: What happens if you let the PoW-consensus away?
A: Double-spend is possible.

Q: What happens, if I try to fix this with a protocol that says that the payee of a transfer from unit w is always hash_128_bit(w)?
A: Then you end up with a system that you cannot use, because you will not find any payee that equals to that.

Q: So, what if I use hash_32_bit(w)?
A: Then you will have collisions. You will not only find the single payee you want, but a group of people who even didn't ask to be paid, sharing hash_32_bit(w) because of their w.

Q: What if actually one guy has mined a set of units, and another guy has mined another set, will they have different units in it?
A: Yes, if it's much less than 2^32, then they will have different sets.

Q: Can I ask the one guy I want to pay to tell me his set, so that I can look in my set for units that - if transferred - will make him richer than the other guy?
A: Yes, it's thinkable to pick those units that will make one richer than another one. But you will have a hard time finding units that fit to each other, when the payee has no units yet, or when you don't have many units yet.

Q: Can't I ask everyone for units that have both the needed w and hash(w), so that we can actually route units?
A: Huh?

Q: See, if I'm Alice and I have an A->B unit, and Bob has a B->C unit, and I want to pay Chris, who only has a C->D unit, then I can ask Bob to take my unit, and then he should give Chris his unit.
A: Who tells you Bob will not just keep your unit and do nothing?

Q: Nothing, I trust him. Ok, having mined just one unit is too few. But when I have more than this, I can transfer them and see who's willing to participate in the routing. Anyone who shares a B->C unit could. I need to iterate this with more units and accept minor losses as fees for the routers.

So it sounds exactly like current proof of work, generate a bunch of random numbers until you get the one number (nonce) that wins the block (or transaction)... am I missing something?

I'm sure there is something to learn by your idea I just haven't figured out what it is yet.

@nc50lc

I owe you an answer. I simply didn't get that [1] = 1) and was confused, sorry.


I used the term blockchain so I could cover a lot of assumptions. The proposed system is indeed quite different, and at first it might look wrong to start from Bitcoin. But with starting from scratch, I could not explain anything in a short amount of time.


The reason is the problem of an attacker generating many wallets or sybil attack. The solution would be that generation of wallets is the official mining, the wallets also being the units. The power consumption is at first only moved to somewhere else, and I'm not per se proposing to reduce it.


Yes. The system comes immediately with the problem that you cannot pay anyone when either you have not many units or the payee has not many units. So, a routing system may be a solution to this. It might come with a form of trust evaluation, because you cannot guarantee that everything you try to route is passed by a router. A low worth of a single unit might allow to stop a bad route early enough without losing much.

I can't agree to your first statement. The PoW-consensus-less system has one entity less (miners with block rewards) and therefore might ease the calcluation of money created from power. I don't yet think it "just intensifies existing problems" so to say. But I don't say the opposite, too. Referring to "PoW" as still an existing part of the system seems okay to me. Who knows, if it has other good qualities? Consuming power isn't a really wanted thing, but the other guys do it anyway. And maybe the "wallet mining" allows for giving out units by a government, with no tagging and tracing hopefully, and later having it circulate without power consumption. I wouldn't rule this out.

It's basically the same idea as PoW except that instead of the blockchain paying miners, users are now paying miners. Again, you can't double spend PoW, because its an analogue for elapsed time.

This is true. Partly. You could send it to anyone, not just the miners, because there has not to be the distinction of miners and users at all. No PoW-consensus, no such distinction.

But there would be indeed just someone else consuming power. The system I suggested does only move this part from one place to another place. Since such a coin doesn't yet exist, but comes from a quite simple assumption, I found it interesting. It's no "revolutionary" new coin that is based on people with secrets, at least. I would not try to realize the system I proposed yet, since sharing a money unit is really something I don't know much about yet.

Thanks for your feedback so far!

Well, in that case, what you've got is a more useless version of PoW, where instead of a currency you can send to anyone, you can only send it to the miners.

The solution for this problem is that this *is the mining.
wallet = unit

It doesn't work. The rational thing to do is for every wallet owner to continuously generate millions upon millions of wallets to increase their chances of being able to receive the money.

This is a sybil attack, since generating wallets has no cost.

The main idea is just that because the consensus is for ordering double-spends (thus eliminating them to one spend)..., when there is only one wallet to spend your money to, there is no need for this consensus.

But then you have a totally useless coin because you would need to search 2^key_size to be able to spend money instead of burning it. So the idea is just to see what happens mathematically and socially when you reduce the size of the wallet public key to make it collide. The implications are probably that you don't have a traditional money system anymore, but you could try to build an analytics/action system around it, to get a long with the "sharing" of colliding public keys.

Talking about PoW-Coins is totally right and I have at first restrained from using this subforum, since I, too, don't think anyone should or would try to remove the PoW from anywhere. I am a newbie, but I, too, know that:

- sorry for the non-professional and wording -

1) Government kind of fairly distributes power
2) Proving that someone has had power in a way, that - when everyone knows every existing data - there is still no forging (finding pre-images), is very unique thing and I, too, find it unbeatable

But... I'm just coincidently at the remove-Pow-side of thinkers, and when you can spend only to one wallet, you do not need consensus about the timely order of signatures. That I found just a neat thing to think about again and see how complicated it would be without PoW.

Please give me your concerns! : )
Thanks a lot

Is this based from your reply from the thread: Public permissioned blockchain?
Because I still haven't found a post of yours that stated something like:
Because the OP of that thread didn't presented a Public permissioned blockchain but asked the technicalities about it.

I don't want to be a bummer but, the title itself (without PoW) spells a lot of potential vulnerabilities and I won't make a long list 'coz it's a pain in the ass.
Here's a shortcut:

• [1] Is this supposed to be in the list?
• [2] Why would any coin developer do that?
• [7] Transactions aren't Board/Chat rooms.

And the list... seems like you didn't understand the term "Blockchain" at all.
No worries, it's pretty normal for a newbie.

Here's a refresher: https://en.wikipedia.org/wiki/Blockchain

Hi, because I talked about that idea that is probably a bit flawed but I never dared to write it down, so ...

1) Normal Bitcoin-blockchain

Protocol changes:

2) Allow only sending 1 BTC, not less, not more

3) Allow "sending" (some form of wanted double spending actually) BTC only to a deterministic group of wallets, where payees_wallet = colliding_32_bit_hash(owners_wallet x unit) has to be true

4) Since the wallets collide, when you can sign a payment, you actually give away the (1 / ((2^128) / (2^32))) of the unit (or something like that), you're like a share holder of the 1-BTC unit

5) To send money, you have to receive a loooong list of wallets from the payee, and then look for units where you can provide a collision to at least give it into the direction of your payee

6) You either have many wallets and are able to provide the payee "situation improvement" until you/he can calculate that he has now gotten enough units

7) or you ask other wallets/owners to kindly route the units you want to transfer, until they have reached the destination. when they keep units without passing it on, you actually have paid them, and at some point you may decide it's not worth not to blacklist certain nodes who actually keep too much

lots of lots of data and communication probably

Anyway, to me, when you have defined all the drawbacks and live with them, the system might hold the promises.

Maybe in the far future someone will realize it as a fun project in school or so