please delete

[SapphireSpire]

bad ideas

[n0nce]

to make a payment:
The sender creates a new transaction that spends one or more of his unpublished utxos.

How is a UTXO 'his' if it was never published? The sender could double spend it (do the whole payment procedure simply twice) since it was never recorded on the ledger that these coins are actually 'his'. Let's play devil's advocate and continue.

In his new transaction, he creates an output with the exact amount for the receiver and another for change to himself. He also creates an unpublished transaction that spends his change output. He then publishes the transactions that he just spent and sends this new transaction and sigs to the receiver in secret.

This is not entirely clear. Which transactions are published when and everything. A kind of flow chart would be helpful.
From what I grasp, you want to spend a transaction before it was mined (validated, confirmed) by the network. This is not feasible since nobody can then verify if the inputs exist (utxo set can't be calculated correctly), right?

The receiver creates two new transactions of his own, one that spends the sender's new transaction and one that spends his own new transaction (unpublished). He then publishes the two completed txs as a pair.

To which address does he spend his transaction? And why? And again he's publishing a transaction whose input is not in the utxo set or am I missing something?

Since every published utxo is bound to the txid of the unpublished transaction that spends it, no consensus mechanism is required.

Let's take a step back, completely fundamentally: if you have no consensus mechanism, it means you have no validating nodes, which means no rules are enforced, thus no security, or not? Also without blockchain, where are you going to store the transactions? You said in the beginning that you're removing it entirely, but then you talk about 'publishing' the transactions. Oh and you forgot that one reason for mining is preventing spam; this is not covered in your concept.

[odolvlobo]

Your description is complicated. Perhaps some diagrams and examples would help.

When an output is created, a transaction that spends it is created too and it's txid is embedded in the output before it gets published.

So, the intended receiver creates a transaction that spends the output he is receiving and gives the txid to the sender to insert into the transaction, right?

In order for the receiver to create the transaction that spends the output, he needs the output's txid. How does the sender compute that txid without the txid of the receiver's transaction? It's a circular dependency.

He then publishes the transactions that he just spent (advanced delegation) and sends his new transaction and sigs to the receiver in secret. Once the receiver sees those spent transactions on the network, they validate the transaction that the sender just sent to him. The receiver then creates two new transactions of his own, one that spends the sender's payment output and one that spends his own output. He then publishes the last two spent transactions as a pair.

Again, how do you create a txid for a transaction that is incomplete? If the txid of the followup transaction is not included in a transaction's hash, then nothing prevents someone from creating double-spending transactions.

[BlackHatCoiner]

Beginning with an arbitrary transaction in the ledger, A, it's output is A1.  The unpublished transaction that spends it is B and it's output is B1.

So what prevents you from creating another unpublished transaction that spends A1 and do every step you've written? How will the nodes know which one is correct? From your sayings I understand that there's no point for a consensus mechanism, because the nodes keep the txid of the unpublished transaction.

Alright, so what happens if they each keep different txids?

[larry_vw_1955]

When an output is created, the transaction that spends it is created too and it's txid is embedded in the output before it gets published.  The output of the last transaction is not yet spent so it remains unpublished.

Your idea seems to good to be true and I think I see why. there is no unique "transaction that spends it". One could take that same output and create multiple "transactions that spend it". Without a consensus mechanism you could publish more than one of those transactions which means not only double spending but you could literally spend that same output infinitely many times. How's that?  

Alright, so what happens if they each keep different txids?

That's another reason why it doesn't work. no consensus mechanism means that could happen.

[ir.hn]

First I will say I don't understand this and a more lengthy explanation would be needed.

But I do think something like this could be possible.  Basically if I am getting the gist you are basically making a web of transactions instead of just one transaction so it couldn't be easily double spent.  Kind of like proof of history with solana or something.

[larry_vw_1955]

Back in step 1, the owner of B1 might try to double spend it by creating multiple versions of C, each with a different payment address to a different receiver.  But each receiver is waiting for him to publish B with a reference to C in B1. So the sender has no choice but to pick one thereby defeating his own attack.

Without a consensus mechanism to tie everything together, it won't work. Your "Proof of Verification" doesn't sound like a consensus mechanism. In other words, there is no concept of the word "publish" until you have a way in which everyone can agree on what exactly is considered published. In your system, how does one go about "publishing" something? And how does the network come to an agreement on what transactions are "published"? That's why bitcoin uses proof of work. And why some other things use proof of stake. They are consensus mechanisms.

[BlackHatCoiner]

Because all published outputs like A1 contain the txids of the unpublished transactions that have already spent them.

A1 is an UTXO. B spends it and its TXID is included into A1, but B is unpublished. To spend from B the owner creates C that spends B1 and splits the coins in C1 and C2. Now everyone knows that A1 contains B's hash whose output also contains C's hash.

Look what's the problem: This goes on to infinity. Once you include C's hash to B's output, you ensure that C is invariable. You must have also created another transaction (D) that spends C's outputs so that you can't double-spend. But, in order to avoid this, you must have also created another transaction (E) which spends D's outputs.

Long story short: Yes, every non-final transaction's outputs cannot be double-spent, but the final's can.


You've also forgotten to outline how will the minting work. You need to ensure there's a fair distribution and without a consensus mechanism the only way is for you (and your development team) to begin by owning all the coins.

[BlackHatCoiner]

It's not necessary to keep generating new transactions forever, only when you spend them.

A1 contains B's hash and it's spent. B1 contains C's hash and it's unspent. When I want to spend B1 I'll reveal C's hash which is a transaction that contains D's hash in C1. However, in order to know D's hash I need to also have E, since D1 contains E's hash. This never ends.

Here's my pseudocode:

Code:

TX A --> A1 
          | 
          > TX B (HASH) --> B1
                            |
                            > TX C (HASH) --> C1
                                              |
                                              > TX D (HASH)
                                                .
                                                .
                                                .

Have I understood it correctly?

[PrimeNumber7]

So what prevents you from creating another unpublished transaction that spends A1 and do every step you've written? From your sayings I understand that there's no point for a consensus mechanism, because the nodes keep the txid of the unpublished transaction.

Because all published outputs like A1 contain the txids of the unpublished transactions that have already spent them.

Under what circumstances is a transaction published? From what I can tell, a transaction will never get published because someone receiving a transaction will need to spend their coin before the previous person can have their transaction published.

Another issue is that the person who spent a given UTXO has veto power over how the next person spends their coin. If Bob sends coin to Alice, Bob will need to sign information about Alice's subsequent transaction, so if Alice tries to send coin to Bob's ex-wife, Bob can decline to sign Alice's spending transaction.

I also don't think it would be possible to create coins under this setup. With PoW, a UTXO is created when a block is found, and the block header is a derraritive of the coinbase transaction. However if a spending transaction needs to include information about the subsequent transaction, it would not be possible to include the coinbase transaction because it will later change.

[BlackHatCoiner]

Did you check my response? I want to ensure I've understood your proposal.

The entire coinbase originates from a single genesis transaction.

I hope you acknowledge that this couldn't be less unfair. Whether your system works with or without mining, a currency can't realistically work if one entity holds all the money from the very beginning.

[larry_vw_1955]

All full nodes can validate but, as long as utxos aren't published before they're spent but referenced when they are, then the network doesn't need a consensus mechanism because it only ever sees the final outcome.

Of course it needs a consensus mechanism. Every distributed ledger needs a consensus mechanism. Otherwise double spends can happen, including with your scheme too.

POV is the core concept of an alternative transaction protocol that doesn't require a consensus mechanism. It's not intended to solve every problem.

you havent even explained how your POV prevents double spends and yet you keep saying it doesn't require a consensus mechanism  

[larry_vw_1955]

I've edited my op for clarity, you should re-read it.  If you still think that double spends can happen in POV, just give me one example so I can fix it.

Ok, starting from the very beginning of your explanation in your original post:

Beginning with an arbitrary transaction in the ledger, A, it's output is A1.
A1 is spent by an unpublished transaction, B, and the txid of B is referenced in A1, so A1 cannot be double spent.

Code:

A1 > B

So you seem to be assuming the existence of A1 in everyone's ledger without explaining how A1 gets accepted into everyone's ledger (and not some other output) in the first place. In your scheme, the same person that creates output A1 could also create another output called A2 spent by another unpublished transaction call it BB where the txid of BB is referenced in A2. Without some form of consensus mechanism, then some nodes' ledger could contain A2 as the output of A while some could contain A1 as the output of A. Some might even contain both. Maybe some might contain neither. Any of those would result in a non-functional network. 

Not sure it's productive to go further into your original post if the above issue can't be addressed. I know you already attempted to address this issue with the following statement though:

Back in step 1, the owner of B1 might try to double spend it by creating multiple versions of C, each with a different payment address to a different receiver.  But each receiver is waiting for him to publish B with a reference to C in B1. So the sender has no choice but to pick one thereby defeating his own attack.

But the problem with your attempted explanation is that you are relying on their being a consensus when you use the word "publish" above. Yet you claim that no consensus mechanism is needed. That seems to be an issue.

[BlackHatCoiner]

If you still think that double spends can happen in POV, just give me one example so I can fix it.

An yet, you keep avoiding me...

It's not necessary to keep generating new transactions forever, only when you spend them.

A1 contains B's hash and it's spent. B1 contains C's hash and it's unspent. When I want to spend B1 I'll reveal C's hash which is a transaction that contains D's hash in C1. However, in order to know D's hash I need to also have E, since D1 contains E's hash. This never ends.

Here's my pseudocode:

Code:

TX A --> A1 
          | 
          > TX B (HASH) --> B1
                            |
                            > TX C (HASH) --> C1
                                              |
                                              > TX D (HASH)
                                                .
                                                .
                                                .

Have I understood it correctly?

[BlackHatCoiner]

There are at least two hashes in every transaction, the txid and the signature.

The signature is not a hash.

The txid is generated when it is still unspent and has no references to future transactions. The signature is generated after it is spent and has references.

The transaction hash was calculated using the signed transaction and therefore, from a combination of the transaction itself and its signature. This means that the content of the signature cannot be changed if the transaction hash remains the same.

If you choose to separate the transaction hash and the signature, for example by calculating the SHA256 only of the transaction without the signature, then you have another problem: You can't prevent the user from double-spending using two signatures.

[garlonicon]

You can't prevent the user from double-spending using two signatures.

Technically you can, because you can create a consensus rule for R-value in a signature, so that for one public key, there will be only one valid signature for a given transaction. Another question is: how to make it safe enough and is it really needed to force a single matching script per transaction input in a given transaction. You can force that, but the question is: do you really need that and do you really want that? Because then, there are more unexplored problems, for example implementing different sighashes in such system.

[BlackHatCoiner]

Technically you can, because you can create a consensus rule for R-value in a signature, so that for one public key, there will be only one valid signature for a given transaction.

How? How can you ensure that from the [r, s] pair the r is valid only if it takes one value given a specific public key?

The developer guide states that the secp256k1 signature is made using the ECDSA, a hash algorithm

ECDSA stands for Elliptic Curve Digital Signature Algorithm. Not hash algorithm. Yes, there are hashes involved in the process, but it should not be confused with a hash function.

But even if that enables the sender to generate two equally valid signatures for a given input, he still can't double spend because any other transaction will have a different payment address, and a different txid, which will not be referenced in the output that it's attempting to spend.

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?

[garlonicon]

How? How can you ensure that from the [r, s] pair the r is valid only if it takes one value given a specific public key?

Just by taking your public key and using addition and multiplication of some number on it (that can be a hash of something). For example: in every signature you have Q public key and R "signature public key". You always know that by doing "Q+(z/r)" and "R*(s/r)" you will reach the same point, that's how ECDSA works. If you know a direct relation between your private key "d" and your "k", your "signature private key", then it is unsafe. Knowing that "d=k+number" is unsafe, knowing that "d=k*number" is unsafe, but knowing that "d+number1=k*number2" is safe (you can extract that from any signature). So, all that is needed is simply taking your public key Q and calculating R=(Q+hash(something))*hash(somethingElse). If you choose your added and multiplied value in a right way, you can reveal your public key, everyone will do some hashing and tweak that key, reaching R-value of your signature. And you can take your private key, tweak it in the same way as your public key is tweaked, and reach your k-value of your signature, producing (r,s) pair with matching r.

Some example:

Code:

Q=03678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 (compressed pubkey from block zero)
z/r=SHA-256("I am not Satoshi!")=3d0e14577c6c0bbfc97644c36900bf941ba3afe23f0840017814afd320f17dcc
r/s=SHA-256("garlonicon")=272fc6644fedff1a897d6034bed23f61859e99440ee699033307976590316723
Q+(z/r)=02b13f778fffa38caffef23d236b7e7a39a22e47200a6bc310f844ecbf205fa60b
R=(Q+(z/r))*(r/s)=0299495c29155cff3bdba965ab209daab3039b4c05388d820604527ded15affb7e
r=99495c29155cff3bdba965ab209daab3039b4c05388d820604527ded15affb7e
z=(z/r)*r=3d0e14577c6c0bbfc97644c36900bf941ba3afe23f0840017814afd320f17dcc*99495c29155cff3bdba965ab209daab3039b4c05388d820604527ded15affb7e
z=abb986eeb49536362f4d845641ae21e813680b4848c1daa84a07c389a65530dc
s=(1/(r/s))*r=(1/272fc6644fedff1a897d6034bed23f61859e99440ee699033307976590316723)*99495c29155cff3bdba965ab209daab3039b4c05388d820604527ded15affb7e
s=b3c543ed385e6b8d5b15fecea33c478538200e032ecf19d28f3446f5d0802761*99495c29155cff3bdba965ab209daab3039b4c05388d820604527ded15affb7e
s=a4e2eb8ff9439df33d6e1aafecf8c35cf67a6c50fe89a343a8a0ccce222bde82
s>7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0
s=fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141-a4e2eb8ff9439df33d6e1aafecf8c35cf67a6c50fe89a343a8a0ccce222bde82
s=5b1d147006bc620cc291e55013073ca1c4347095b0befcf8173191beae0a62bf

So, let's assume that Satoshi created some transaction and made a signature:

Code:

Q=03678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6
z=abb986eeb49536362f4d845641ae21e813680b4848c1daa84a07c389a65530dc
r=99495c29155cff3bdba965ab209daab3039b4c05388d820604527ded15affb7e
s=5b1d147006bc620cc291e55013073ca1c4347095b0befcf8173191beae0a62bf

All values are random, this signature is fake, because I don't know any message that can be hashed to z. And everyone knows that:

Code:

signature_nonce=(satoshi_privkey+3d0e14577c6c0bbfc97644c36900bf941ba3afe23f0840017814afd320f17dcc)*272fc6644fedff1a897d6034bed23f61859e99440ee699033307976590316723

It is safe, because you cannot calculate satoshi_privkey or signature_nonce from that information alone (and you can get similar equations for all signatures). So it is possible to take some hashes, tweak some public key, and reach some R-value in this way. Then, the owner of the coins can tweak the private key in the same way and make a signature that will be always unique for a given z-value.

[larry_vw_1955]

In the Bitcoin whitepaper, 'publishing' means broadcasting transaction messages to all other users of Bitcoin, because "all users need to be aware of all transactions".  

It would be nice to see a more detailed explanation of your protocol one with more technical details included because all you really provided is a high-level overview which is really not so clear do you actually have any code? Does it work? Do you have a white paper?

I'd like to try and understand it but there's not enough details in the original posting to really understand it fully.

[BlackHatCoiner]

Then, the owner of the coins can tweak the private key in the same way and make a signature that will be always unique for a given z-value.

In order for the signature to be unique, you need to include into the previous output/transaction the z-value or use some sort of consensus rule in which z-value is calculated in a predictable way. For instance, when you created A1 you included B's hash into it. But, you must have stated what's the unique z-value that can be used in a signature to spend A1.

But, for the B1 to be spendable by only one z-value, it means you must have also stated it somehow. 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?