please delete

[larry_vw_1955]

 Again, there's no point to dive into details if I don't get an answer to the following:

A1 contains B's hash. In order to spend A1 I need to create a signature that involves B's hash, otherwise the transaction is invalid. But, in order to have B's hash I need to know which are the outputs of B, in this case just B1. But, B1 must contain C's hash. Is that correct until here?

That's like an infinite regress isn't it? Because then C1 has to contain the hash of D and so on ad infinitum.

[BlackHatCoiner]

That's like an infinite regress isn't it? Because then C1 has to contain the hash of D and so on ad infinitum.

This is exactly what I'm saying. You can't prevent double-spending without completing this endless scheme. The outputs of the final transaction, no matter when will they be, can be double-spent.

The reference to B in A1 is secured by the signature in A so it cannot be modified.

I don't disagree. A has a reference of B to A1. But, in order to have a reference to B, it means that B is an unsigned transaction, ready to be signed and broadcasted. But, in order to be signed, it needs to have a reference of C in B1, which means C must be an unsigned transaction, ready to be signed and broadcasted. In order for C be signed, it needs to have a reference of D in C1. It goes on and on, forever.

[stanner.austin]

@garlonicon
It's possible with current gpu to make bruteforce 2 random int to match Z which we need for known public key?
i made some test with cpu and python running from 48hrs not found any yet.
but what you think about GPU if they can do this kind of job or even possible ?

sample code.

Code:

u = randint(1, N)
v = randint(1, N)
r = (u*G+v*PublicKey).x.num % N
s = r * pow(v, N-2, N) % N
z = u * s % N
matching z with list of my known precalculated z for my choice of output.

[larry_vw_1955]

This is exactly what I'm saying. You can't prevent double-spending without completing this endless scheme. The outputs of the final transaction, no matter when will they be, can be double-spent.

There can't even be a final transaction in this scheme. It seems to require an infinite length transaction chain because every utxo published or unpublished has to contain the transaction ID of the transaction that spends it that's an impossible thing unless the chain goes on forever yet is fully known initially.

I don't disagree. A has a reference of B to A1. But, in order to have a reference to B, it means that B is an unsigned transaction, ready to be signed and broadcasted. But, in order to be signed, it needs to have a reference of C in B1, which means C must be an unsigned transaction, ready to be signed and broadcasted. In order for C be signed, it needs to have a reference of D in C1. It goes on and on, forever.

That definitely does appear to be the case. Seems like a logical fallacy which might have been overlooked.

OP claimed it didn't need a consensus mechanism but I still don't understand why not. Even if the scheme worked it seems like it would still need a consensus mechanism.

[garlonicon]

It's possible with current gpu to make bruteforce 2 random int to match Z which we need for known public key?

No, you can make only random signatures. Totally random.

[larry_vw_1955]

But, in order to have a reference to B, it means that B is an unsigned transaction, ready to be signed and broadcasted.

Well, the fact that A1 has a reference to B means that B exists in somebodies wallet, which means it's output B1 has not been spent yet and has no reference, which means it hasn't been signed yet. And that's why it's unpublished.

the way bitcoin works is it has to sign first and then a txid is created, i'm pretty sure. so you're doing it differently in that respect. you create the txid before signing. hmm. ok fine. and as you said in your OP:

This may permit the owner to generate two equally valid signatures in a transaction but the reference in the previous output means that only one transaction is valid so either signature can be used within it.

but the reference is the txid, no? and that txid is the same for both signatures. no?  
keep in mind you don't have a consensus mechanism in your scheme. so you have no way of having the network come to an agreement on which transaction to go with and which one to ignore.

actually i think i see what you mean you're talking about signature malleability not changing the transaction in any way, such as changing the outputs. still though, you using the word "publish" when you admit to not needing or using any consensus mechanism seems problematic.

In step 1, A1 needs a reference to B to be published but B doesn't need any references at that point.
In step 2, B1 needs a reference to C to be published but C doesn't need any references at that point.
So the transaction process is infinitely repeatable but it is not an infinite loop.

So I take it that the txid of B does not take into account any references that B would later contain before it gets signed and published. So you are generating the txid of B just based on its outputs, not taking into account the signature or txid of C. ok. how are you going to maintain consensus? i still think it needs a consensus mechanism, at the very least. since without that, you could create multiple "B" transactions and whats stopping different nodes from having different txid references in their "A1" without a consensus mechanism?

[BlackHatCoiner]

In step 1, A1 needs a reference to B to be published but B doesn't need any references at that point.

A1 contains the hash of B. This means that A1 contains a fingerprint of the fields of B. This means that, excluding the signature, B contains everything needed to be broadcasted once it's signed.

Such fields are input count, inputs, output count, outputs etc. So, before we even spend A1, we possess a transaction B which has B1. But, B must contain a reference to C, otherwise it won't be a valid transaction in the future (as B1 can be double-spent). We need to ensure B1 contains a transaction hash so that it can only be spent only by using that transaction. Thus, it is required to edit B and include C's hash into B1.

Don't you see the loop?

[larry_vw_1955]

In step 1, A1 needs a reference to B to be published but B doesn't need any references at that point.

A1 contains the hash of B. This means that A1 contains a fingerprint of the fields of B. This means that, excluding the signature, B contains everything needed to be broadcasted once it's signed.

Maybe not. Maybe when he's taking the hash of B, the txid of C is not part of B yet. He only puts that into B later before he actually signs B and
"publishes" (whatever that means, because he says he doesn't need a consensus mechanism). He did say the following:

In step 1, A1 needs a reference to B to be published but B doesn't need any references at that point.

See what I mean?

Such fields are input count, inputs, output count, outputs etc. So, before we even spend A1, we possess a transaction B which has B1. But, B must contain a reference to C, otherwise it won't be a valid transaction in the future (as B1 can be double-spent). We need to ensure B1 contains a transaction hash so that it can only be spent only by using that transaction. Thus, it is required to edit B and include C's hash into B1.

Don't you see the loop?

yeah there's an obvious loop there that can't be satisfied if he's trying to do it that way.

[BlackHatCoiner]

Maybe when he's taking the hash of B, the txid of C is not part of B yet.

But in order for B to have a hash, it means it's done. Everything included into B cannot change as that would change its TXID. And B must contain a reference to C's hash, otherwise the outputs of B can be double-spent.

He only puts that into B later before he actually signs B and "publishes"

Once he includes it into B, the content of B changes and so does its hash.


This is not just an infinite loop: It's, by design, non-implementable. Because, you're supposed to go backwards, but there's no final, valid transaction.

[n0nce]

But in order for B to have a hash, it means it's done. Everything included into B cannot change as that would change its TXID. And B must contain a reference to C's hash, otherwise the outputs of B can be double-spent.

Once he includes it into B, the content of B changes and so does its hash.

You are correct, it would not be possible to generate the txid of a transaction if it requires everything.  But the POV protocol doesn't say that txids require everything.  Even if the Bitcoin protocol states that txids must include everything, that doesn't mean it's going to break if it doesn't include some extra things that are added by the POV protocol.

I mean if you're sure this doesn't require an infinite chain, you can surely implement it, right?

As for diagrams, there's many tools such as ASCIIFlow or even good old LibreOffice!

[n0nce]

Thanks for the links, they're awesome!  I can implement this but... it's going to be a while.

No worries! I am now trying to create a picture with ASCIIFlow how I understood it and then you tell me if / where I'm wrong
My mind works a bit in a 'visual' way..

Edit: So this is where I got so far. Now, reading your text multiple times, it's still not clear, how you could put transaction A on the ledger with a TXID of transaction B, if B hasn't had all its fields fully populated yet.

Code:

┌───────┐
│State 1│
└───────┘
Ledger
┌────────────────────────────────────────────────────────────────────┐
│ ┌──────────────────────────────┐                                   │
│ │Transaction A                 │                                   │
│ ├──────────────────────────────┤                                   │
│ │Coinbase=>A1                  │                                   │
│ │                              │                                   │
│ │Amount                        │                                   │
│ │                              │                                   │
│ │TXID(B)                       │                                   │
│ └──────────────────────────────┘                                   │
└────────────────────────────────────────────────────────────────────┘
Off-Chain
┌───────────────────────────────┐
│Transaction B                  │
├───────────────────────────────┤
│A1  =>  B1                     │
│                               │
│Amount                         │
│                               │
│[empty] (will be filled)       │
└───────────────────────────────┘



┌────────────────────────────────────────────────────────────────┐
│State 2 (create TX C, put its 'ID' into TX B, thus modifying it)│
└────────────────────────────────────────────────────────────────┘
Ledger
┌────────────────────────────────────────────────────────────────────┐
│ ┌──────────────────────────────┐                                   │
│ │Transaction A                 │                                   │
│ ├──────────────────────────────┤                                   │
│ │Coinbase=>A1                  │                                   │
│ │                              │                                   │
│ │Amount                        │                                   │
│ │                              │                                   │
│ │TXID(B)                       │                                   │
│ └──────────────────────────────┘                                   │
└────────────────────────────────────────────────────────────────────┘
Off-Chain
┌───────────────────────────────┐  ┌───────────────────────────────┐
│Transaction B                  │  │Transaction C                  │
├───────────────────────────────┤  ├───────────────────────────────┤
│A1  =>  B1                     │  │B1  =>  C1                     │
│                               │  │                               │
│Amount                         │  │Amount                         │
│                               │  │                               │
│TXID(C)                        │  │[empty] (will be filled)       │
└───────────────────────────────┘  └───────────────────────────────┘



┌───────────────────┐
│State 3 (publish B)│
└───────────────────┘
Ledger
┌────────────────────────────────────────────────────────────────────┐
│ ┌──────────────────────────────┐ ┌───────────────────────────────┐ │
│ │Transaction A                 │ │Transaction B                  │ │
│ ├──────────────────────────────┤ ├───────────────────────────────┤ │
│ │Coinbase=>A1                  │ │A1  =>  B1                     │ │
│ │                              │ │                               │ │
│ │Amount                        │ │Amount                         │ │
│ │                              │ │                               │ │
│ │TXID(B)                       │ │TXID(C)                        │ │
│ └──────────────────────────────┘ └───────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────┘
Off-Chain
┌───────────────────────────────┐
│Transaction C                  │
├───────────────────────────────┤
│B1  =>  C1                     │
│                               │
│Amount                         │
│                               │
│[empty] (will be filled)       │
└───────────────────────────────┘

Feel free to copy / paste this code into asciiflow and modify it if changes or additions are needed.


Besides all of this, the question remains how the coins will be minted. And it's not a trivial one or one where we can go 'yeah we'll figure it out later'. Because it is essential to Bitcoin or any cryptocurrency. You can read up on the issues of POS blockchains that generate the coins 'out of thin air', it's a real issue if you don't consume energy to create your coins.

I don't vouch for the info found in the link collection, but it could be a starting point:
https://endthefud.org/PoW

[larry_vw_1955]

Maybe when he's taking the hash of B, the txid of C is not part of B yet.

But in order for B to have a hash, it means it's done. Everything included into B cannot change as that would change its TXID. And B must contain a reference to C's hash, otherwise the outputs of B can be double-spent.

B will most certainly contain a reference to C before B gets signed. But not when B's txid is generated is the point. I think the OP later confirmed this idea that you don't have to include everything in the transaction when you generate its txid. Case solved.

He only puts that into B later before he actually signs B and "publishes"

Once he includes it into B, the content of B changes and so does its hash.

not the way that he's doing it.

Edit: So this is where I got so far. Now, reading your text multiple times, it's still not clear, how you could put transaction A on the ledger with a TXID of transaction B, if B hasn't had all its fields fully populated yet.

I don't think you can fully populate B so he takes the TXID of B before he has a reference to C contained in B. Only before signing and publishing B is he going to put in a ref to C.

You are correct, it would not be possible to generate the txid of a transaction if it requires everything.  But the POV protocol doesn't say that txids require everything.  Even if the Bitcoin protocol states that txids must include everything, that doesn't mean it's going to break if it doesn't include some extra things that are added by the POV protocol.

precisely.


now the question is, is that going to work that he's taking txid of B before he has the txid of C included in B? that's the question.

then another question is why doesn't this thing require a consensus mechanism?

[BlackHatCoiner]

You are correct, it would not be possible to generate the txid of a transaction if it requires everything.  But the POV protocol doesn't say that txids require everything.

I think the OP later confirmed this idea that you don't have to include everything in the transaction when you generate its txid. Case solved.

This is not so simple. If the reference of the next transaction is not included in the transaction data of the previous transaction, then its content is variable and can be double-spent. For instance, say B1 does not contain a reference to C, yet. A1 contains the hash of B, which has been calculated without C's reference. Once I publish B, I can create many B-s that all spend the same output to the same destination, so I can keep the same hash, but with different C-s, that do not take part in the hash function.

Which B is the correct transaction? 

[BlackHatCoiner]

Before B is published, the only valid B is the one referenced in A1.
After B is published, the only valid B is the one with the valid signature for A1 and the only valid C is the one referenced in B1.

I'm trying to tell you that since the reference to C is not included into the content of the transaction it can change, without changing B's hash. For instance I broadcast to several nodes that B contains D's hash and to the rest that B contains C's hash. Which one is the correct B and why, since the reference to the next transaction is not included into the previous' content?

Once you publish your valid B, the network will accept it. Anything other then that will be immediately rejected and, if you continue to publish erroneous data, your peers will start to drop you.

I think we're constantly failing to communicate. How will the nodes know the reference to the next transaction? Is it included into the transaction's content? No, as far as I can tell from your posts. Is it included into the signature?

[larry_vw_1955]

Which B is the correct transaction?  

. Which one is the correct B and why, since the reference to the next transaction is not included into the previous' content?

These two observations of yours highlight the need for some form of consensus mechanism.

Proof of Validation (POV) eliminates double spends without a consensus mechanism by keeping utxos off the ledger until they are spent and including proof when they are.

That's starting to look doubtful.

[larry_vw_1955]

I'm trying to tell you that since the reference to C is not included into the content of the transaction it can change, without changing B's hash. For instance I broadcast to several nodes that B contains D's hash and to the rest that B contains C's hash. Which one is the correct B and why, since the reference to the next transaction is not included into the previous' content?

I think we're constantly failing to communicate. How will the nodes know the reference to the next transaction? Is it included into the transaction's content? No, as far as I can tell from your posts. Is it included into the signature?

Okay, I figured out what you were trying to tell me, and yes, it was broken.
But I found a solution and updated my OP. How does it look now? I think it's fixed.

Well you've definitely made things more complicated that's for sure. Now you're requiring a transaction to contain a reference not only to its immediate sucessor but the one after that too. More analysis would be needed to determine whether that has the same issue. But one thing it definitely does is make it harder to spend stuff!

Lets take a quick look at your new intro:

Beginning with an arbitrary transaction A in the ledger, it's output is A1. A1 is spent by an unpublished transaction B, which is spent by another unpublished transacton C. B and C are still in somebodies wallet. At this point, A1 references the txid of B and C and B1 references the txid of C. The reference to B in A1 means A1 has been spent, and the reference to C in B1 means B has been spent. But these alone will not prevent an adversary from double spending A1 through B1 with lots of different C's. Therefore it is necessary to include references to both B and C in A1.

One issue that comes to mind immediately here is that I as the owner of some output A1 am no longer in control of when I can publish it. Because I have to wait on a reference for C. Maybe the owner of C gets hit by a bus. Maybe the owner of C is not communicating with me for whatever reason. Then what? Find someone else to send my money to? And try and get a reference to C that way? Seems like a pain in the butt. oh not only that but what if it takes the owner of C 10 years to decide how they are going to spend their money? maybe they never spend it. are they allowed to do that? or will i just cancel their transaction and send to someone else and how will they feel about me cancelling their transaction (expecially if I bought sex toys from them and got them already delivered), will they even know i did that? the questions seem endless...if the owner of C can stop me from publishing A1 then that's a big problem don't you think? because then i can't even spend my own money unless i go back on a sale as hinted to in the above sex toy scenario.

oh and that brings up a completely other issue. the owner of C now has to worry about me the owner of A1 getting hit by a bus and thus not being able to publish A1. or not publishing A1 for some other reason like scamming. which kind of forces them to spend C and share its reference with me immediately but what if they don't want to have to do that? then there's a chance they get screwed.

[BlackHatCoiner]

But I found a solution and updated my OP. How does it look now?

Lol. It's the exact system with extra, unnecessary steps.

So, you have three transactions, two of which are unconfirmed. In A1, which is in the ledger, you state that both B's and C's hashes must be included to prevent double-spending of C. This must happen to every transaction, not just to A. For instance, B must contain reference to both C and D. C must contain a reference to D and E etc.

The problem is that you can't finish this procedure. In order to spend one output (A1) you need to include two hashes (B's and C's) to it that have been calculated by the hashes of three others (for B, C and D, and for C, D and E). This goes on and on and on. Long story short: You can never know their transaction hash this way as there's no final transaction and you need to go backwards.

I think that's the only thing you don't realize, everything else looks good. But, you're thinking of TXID as something taken for granted which is where your entire payment system depends on.

[larry_vw_1955]

Code:

 ┌────────────────────────────────────┐
 │ ┌────────────────────────────────┐ │
 │ │             Ledger             │ │
 │ │ ┌───┬────────┐                 │ │
 │ │ │   │ A1     ├─┐               │ │
 │ │ │   ├────────┤ │               │ │
 │ │ │ A │ Ref B  │◄├──┐            │ │
 │ │ │   ├────────┤ │  │            │ │
 │ │ │   │ Ref C  │◄├──┼──┐         │ │
 │ │ └───┴────────┘ │  │  │         │ │
 │ │       ┌────────┘  │  │         │ │
 │ │       │ ┌─────────┘  │         │ │
 │ └───────┼─┼────────────┼─────────┘ │
 │ ┌───────┼─┼────────────┼─────────┐ │
 │ │      ┌▼─┴┬─────┐   ┌─┴─┬─────┐ │ │
 │ │      │   │ B1  ├──►│   │ C1  │ │ │
 │ │      │ B ├─────┤   │ C ├─────┤ │ │
 │ │      │   │ Ref │◄──┤   │ Ref │ │ │
 │ │      └───┴─────┘   └───┴─────┘ │ │
 │ │             Wallet             │ │
 │ └────────────────────────────────┘ │
 └────────────────────────────────────┘

I think by requiring 2 forward references rather than just one, you've created new problems.

For example say we have a BUYER who is sending BTC to a SELLER in exchange for some product or service that will be delivered immediately.

1) Since A is not yet on the ledger, how does SELLER verify that utxo A1 is really real?
2) How does SELLER verify that BUYER has the ability to spend A1?
3) Since B is not yet on the ledger, how does SELLER know it is really real?
4) When the time comes that SELLER wants to spend his utxo B1, what happens if BUYER doesn't do what he was supposed to?  
5) And how does SELLER know that BUYER hasn't created other similar B transactions using the same output A1?
6) What's stopping BUYER from publishing A using some other txid for B than the one he gave to SELLER?

There might be a way around #4 if the SELLER was to immediately create C and D and I guess E too and force BUYER to publish A and B to the blockchain immediately before handing over the product/service? That way everything would be in SELLER'S control maybe. And BUYER'S transactions would all be "published".

But there again, we run up against the word "publish". What's the consensus mechanism that forces all nodes to agree on the transaction history?

 

[BlackHatCoiner]

[...]

Some of those are indeed other problems, but the main one is that it's not implementable. There's no need to discuss how will the seller and buyer agree or how will the minting work. This Proof of Validation simply does not make sense from a technical point of view.

[larry_vw_1955]

[...]

Some of those are indeed other problems, but the main one is that it's not implementable. There's no need to discuss how will the seller and buyer agree or how will the minting work. This Proof of Validation simply does not make sense from a technical point of view.

That's up to him to throw in the towel or keep at it. it was an interesting idea but yeah... so it's not possible for 100% sure?