|
Title: please delete Post by: SapphireSpire on January 18, 2022, 11:26:31 PM bad ideas
Title: Re: Proof of Advanced Delegation (PAD) Post by: n0nce on January 19, 2022, 02:17:53 AM to make a payment: 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.The sender creates a new transaction that spends one or more of his unpublished utxos. 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.Title: Re: Proof of Advanced Delegation (PAD) Post by: odolvlobo on January 19, 2022, 06:02:21 AM 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. Title: Re: Proof of Advanced Delegation (PAD) Post by: BlackHatCoiner on January 19, 2022, 08:04:11 AM 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? Title: Re: Proof of Advanced Delegation (PAD) Post by: larry_vw_1955 on January 20, 2022, 10:28:04 AM 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. Title: Re: Proof of Advanced Delegation (PAD) Post by: ir.hn on January 20, 2022, 12:50:14 PM 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. Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 21, 2022, 08:09:06 AM 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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 21, 2022, 08:37:22 AM 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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 21, 2022, 02:54:26 PM 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 Have I understood it correctly? Title: Re: Proof of Validation (POV) Post by: PrimeNumber7 on January 21, 2022, 03:03:12 PM 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.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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 21, 2022, 04:17:45 PM 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. Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 22, 2022, 02:08:55 AM 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. Quote 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 >:( Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 22, 2022, 08:28:05 AM Quote from: SapphireSpire 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: Quote 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: Quote 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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 22, 2022, 06:27:12 PM 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 Have I understood it correctly? Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 22, 2022, 08:54:41 PM 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. Title: Re: Proof of Validation (POV) Post by: garlonicon on January 22, 2022, 10:21:52 PM Quote 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.Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 23, 2022, 08:32:19 AM 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?Title: Re: Proof of Validation (POV) Post by: garlonicon on January 23, 2022, 10:09:01 AM Quote 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) Code: Q=03678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 Code: signature_nonce=(satoshi_privkey+3d0e14577c6c0bbfc97644c36900bf941ba3afe23f0840017814afd320f17dcc)*272fc6644fedff1a897d6034bed23f61859e99440ee699033307976590316723 Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 23, 2022, 10:38:39 AM 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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 23, 2022, 12:27:01 PM 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? Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 24, 2022, 02:12:57 AM 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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 24, 2022, 06:49:48 AM 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. Title: Re: Proof of Validation (POV) Post by: stanner.austin on January 24, 2022, 08:28:08 AM @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) Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 24, 2022, 08:30:33 AM Quote from: BlackHatCoiner link=topic=5382059.msg59062183#msg59062183 [quote 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.Quote from: BlackHatCoiner 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. Title: Re: Proof of Validation (POV) Post by: garlonicon on January 24, 2022, 03:00:40 PM Quote 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.Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 25, 2022, 06:25:25 AM 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: Quote 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. Quote 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? Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 25, 2022, 07:39:33 AM 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? Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 25, 2022, 12:16:10 PM 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: Quote 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? Quote 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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 25, 2022, 12:36:00 PM 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. Title: Re: Proof of Validation (POV) Post by: n0nce on January 26, 2022, 12:53:14 AM 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. 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.Once he includes it into B, the content of B changes and so does its hash. As for diagrams, there's many tools such as ASCIIFlow (https://asciiflow.com/) or even good old LibreOffice (https://www.libreoffice.org/)! :D Title: Re: Proof of Validation (POV) Post by: n0nce on January 26, 2022, 01:05:56 AM 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: ┌───────┐ 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 Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 26, 2022, 04:15:07 AM 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" Quote Once he includes it into B, the content of B changes and so does its hash. not the way that he's doing it. Quote from: n0nce 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? Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 26, 2022, 08:03:22 AM 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? ::) Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 26, 2022, 08:40:16 AM Before B is published, the only valid B is the one referenced in A1. 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?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. 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?Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 26, 2022, 01:43:51 PM Which B is the correct transaction? ::) Quote . 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. Title: Re: Proof of Validation (POV) Post by: larry_vw_1955 on January 28, 2022, 05:32:49 AM 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? Okay, I figured out what you were trying to tell me, and yes, it was broken.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? 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: Quote 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. Title: Re: Proof of Validation (POV) Post by: BlackHatCoiner on January 28, 2022, 07:09:11 AM 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. Title: Re: Proof of Validation (POV) [Updated 1/27] Post by: larry_vw_1955 on January 28, 2022, 09:22:59 AM Code: ┌────────────────────────────────────┐ 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? :o 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? Title: Re: Proof of Validation (POV) [Updated 1/27] Post by: BlackHatCoiner on January 28, 2022, 09:30:57 AM [...] 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. Title: Re: Proof of Validation (POV) [Updated 1/27] Post by: larry_vw_1955 on January 28, 2022, 09:34:13 AM [...] 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... ;D so it's not possible for 100% sure? >:( Title: Re: Proof of Validation (POV) [Updated 1/27] Post by: BlackHatCoiner on January 28, 2022, 03:03:14 PM so it's not possible for 100% sure? >:( With the way they describe it? 100% Title: Re: Proof of Validation (POV) [Updated 1/27] Post by: larry_vw_1955 on January 29, 2022, 01:09:35 AM so it's not possible for 100% sure? >:( With the way they describe it? 100% I mean the overall concept of not having a consensus mechanism but still not allowing double spends: Quote 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. Title: Re: Proof of Validation (POV) [Updated 1/27] Post by: BlackHatCoiner on January 29, 2022, 07:29:50 AM I mean the overall concept of not having a consensus mechanism but still not allowing double spends No one can be sure for this. However, the Byzantine generals need a mechanism to operate. Title: Re: Proof of Validation (POV) [Updated 1/27] Post by: larry_vw_1955 on January 30, 2022, 03:02:18 AM I mean the overall concept of not having a consensus mechanism but still not allowing double spends No one can be sure for this. However, the Byzantine generals need a mechanism to operate. I notice the OP has changed the title of this thread to: A small tweak solves the double spend problem without a blockchain. If only that were the case, but I think its going to take way more than just a "small tweak" to accomplish something like that. Maybe he's got an ace up his sleeve though. :o I'm hoping he hasn't given up on this. ;D But if he has given up, then we might need a bit of help from Greg Maxwell on this one. Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: garlonicon on January 31, 2022, 02:46:50 PM Quote A small tweak solves the double spend problem without a blockchain. Quote This really is a slippery problem. Just when you think you've solved it, it throws a curve ball at you. Just read the Bitcoin whitepaper again. Satoshi explained why blockchain is needed: "The only way to confirm the absence of a transaction is to be aware of all transactions". To solve the double-spending problem without the blockchain, you need some kind of proof that Satoshi was wrong, that you can "confirm the absense of a transaction" without "being aware of all transactions".Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: garlonicon on January 31, 2022, 08:31:41 PM Quote We can still take the opposite approach that a transaction must be qualified to spend an output by some unique attribute and only one transaction can possess that attribute. If there is only one valid transaction at all, then it means you can send coins only to one person. And if that's the case, then why you need any transaction at all? If Alice has some coin that could be moved only to Bob, then could you truly say that Alice owns the coin? If Alice can send her coins to Bob or Charlie, then it means there are two possible transactions. That means, you need a blockchain to tell Bob that Alice really moved her coins to him, and not to someone else.Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: n0nce on February 01, 2022, 12:16:27 AM Quote A small tweak solves the double spend problem without a blockchain. Quote This really is a slippery problem. Just when you think you've solved it, it throws a curve ball at you. Just read the Bitcoin whitepaper again. Satoshi explained why blockchain is needed: "The only way to confirm the absence of a transaction is to be aware of all transactions". To solve the double-spending problem without the blockchain, you need some kind of proof that Satoshi was wrong, that you can "confirm the absense of a transaction" without "being aware of all transactions".It's also definitely not a 'small tweak'. You have multiple things that mining ensures which have to be replaced: 1) solving double spending problem 2) minting and distributing new coins (extremely important - look at the issues PoS'ers are facing with this) 3) financial incentive for node operators (who run node + mine) 4) attaching real-world resources (energy) to digital utxo's (otherwise you create 'out of thin air') 5) probably more... Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: vjudeu on February 01, 2022, 07:43:28 AM Quote Or, it means that when you create the transaction that spends Alice's coins and pays them to Bob, you also create and include the unique attribute that qualifies the transaction to do so. The transaction to Charlie or anyone else will not have that unique attribute so the network will know they are invalid if they see them. You have two possible cases:1) Alice can send coins to Bob, Charlie or someone else 2) Alice cannot send coins to Bob, Charlie or someone else, she is forced to move coins to some predefined destination In the first case, it is technically possible to create valid transaction "Alice->Bob", as well as "Alice->Charlie" and "Alice->Daniel". If you have all transactions, you can prove that "Alice->Bob" is included in the chain, so nothing else like "Alice->Charlie" or "Alice->Daniel" can be included later. To do that, you have to "be aware of all transactions", as Satoshi wrote. In the second case, the coin is useless, because there is no owner of any coin. The whole history is predefined, because for each coin there is only one valid transaction, so the only one valid list of inputs and outputs, and the only one valid list of amounts, everything has to be known when the coin is created. Then you can look at Alice's coin of 50 BTC and you know that moving 10 BTC to Bob and 40 BTC to Charlie is the only valid transaction that you can create. Everything is predefined, so no blockchain is needed, but the whole system is then useless. Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: BlackHatCoiner on February 01, 2022, 07:58:49 AM Her keys, her coins. Her keys, her coins, but if she can only publish one transaction, then as said above, the currency has no utility. 4) attaching real-world resources (energy) to digital utxo's (otherwise you create 'out of thin air') This is really debatable. Why would it be bad to validate UTXOs from thin air? It sounds fascinating; it's just the implementations bad. For example, in PoS, there's full hierarchy and a million other disadvantages that I won't mention. There aren't other similar mechanisms to PoS. But, having the same Bitcoin without needing energy? Hell yeah. Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: vjudeu on February 01, 2022, 08:50:55 AM Quote But, having the same Bitcoin without needing energy? Hell yeah. It exists and it is called "signet". You can remove mining from signet, set up a similar network with regtest difficulty, and then you will get your "Bitcoin without needing energy". You know why mining is needed? Because in this way you can choose who can introduce new coins to the system in a decentralized way. If you have no mining, then you have to predefine the "miners" of the network (they can be also called "validators").Quote Some of you mentioned that this would require a crystal ball but really it doesn't. Even if it doesn't, the system is still useless. When you create "Alice->Bob" transaction, you have to know "Bob->Charlie" transaction. By induction, for each output you have to know the final destination. That means, the whole history of the coin is predefined when the coin is created. It is of course possible to predefine the history in a non-random way, but it is also useless, just more compressed. For example, you can define that each coin can be sent only to "(pubkey+sha256(pubkey))*sha256(sha256(pubkey))". And you can define that "sha256(amount) modulo amount" has to be sent and you have to pay "amount-(sha256(amount) modulo amount)" fees. You can predefine history in many ways to avoid going backward in time before releasing the coin, but it will still be useless.Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: BlackHatCoiner on February 01, 2022, 10:06:33 AM It exists and it is called "signet". You can remove mining from signet, set up a similar network with regtest difficulty, and then you will get your "Bitcoin without needing energy". You know why mining is needed? Because in this way you can choose who can introduce new coins to the system in a decentralized way. Highlighting the “same”.Quote But, having the same Bitcoin without needing energy? Hell yeah. Okay so, the reason all my prior reference schemes weren't working is because the references didn't ripple back and change the txid of every transaction in the utxo's history. No, that's what I was trying to tell you here: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. There can't be a final transaction, because it has to be valid, but in order to be valid it has to contain a reference to a transaction which makes it non-final. Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: vjudeu on February 01, 2022, 10:50:49 AM Quote Highlighting the “same”. It is the "same". Because "without needing energy" means you want to change Proof of Work to something else. That means mining can be changed, and everything else should be "the same". And signet meets that definition: you have the heaviest Proof of Work chain that is signed, that's the rule. By lowering the difficulty to the absolute minimum, you will get it "without needing energy". Proof of Work created by Satoshi solves the problem of coin distribution in decentralized way: if you remove "work" from that system, you will get it centralized, like Proof of Stake (where you are a miner because you are a whale), like signet (where you are a miner because you created the coin). Nobody solved "decentralized coin distribution problem" in a different way than Proof of Work, any different system can be simplified to the "obscured Proof of Work", like in this table: https://www.truthcoin.info/blog/pow-cheapest/#nonproductive-investments-are-wastefulTitle: Re: A small tweak solves the double spend problem without a blockchain. Post by: BlackHatCoiner on February 01, 2022, 11:04:25 AM It is the "same" No, it's not unless we have a different understanding of what's the same Bitcoin. There's no Bitcoin without decentralization. Bitcoin was created to defend the user who's resented by a central point of failure. You said it yourself;Proof of Work created by Satoshi solves the problem of coin distribution in decentralized way: if you remove "work" from that system, you will get it centralized I know that my statement was a little vague, but what I meant is that if you could have the Bitcoin you have today, emphasizing the decentralization in coin distribution, then it'd be better morally-wise. But, you can't. You can only have Bitcoin with Proof of Work. Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: n0nce on February 01, 2022, 12:52:30 PM 4) attaching real-world resources (energy) to digital utxo's (otherwise you create 'out of thin air') This is really debatable. Why would it be bad to validate UTXOs from thin air? It sounds fascinating; it's just the implementations bad. For example, in PoS, there's full hierarchy and a million other disadvantages that I won't mention. There aren't other similar mechanisms to PoS. But, having the same Bitcoin without needing energy? Hell yeah. I know that my statement was a little vague, but what I meant is that if you could have the Bitcoin you have today, emphasizing the decentralization in coin distribution, then it'd be better morally-wise. But, you can't. You can only have Bitcoin with Proof of Work. Oh yes, correct, got you.Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: decodx on February 02, 2022, 12:21:17 AM Okay so, the reason all my prior reference schemes weren't working is because the references didn't ripple back and change the txid of every transaction in the utxo's history. What's required is for outputs to reference the txids of the transactions that spend them before their txids are generated. Some of you mentioned that this would require a crystal ball but really it doesn't. Just a really long time or a really fast cpu. Even if that were true (which I do not believe that it is), then we would be back at square one. Why would such a system be better than PoW if it required enormous processing power (and a really long time)? Title: Re: A small tweak solves the double spend problem without a blockchain. Post by: larry_vw_1955 on February 02, 2022, 03:27:10 AM Beginning with an arbitrary transaction A in the ledger, it's output is A1. A1 references a randomly generated 256 bit hash target for input 1B "Ref 1B". In order to spend A1 the sender must: 1. Get the receiver's payment address. 2. Create a new transaction B with input 1B that spends A1 and pays it to the payment address in output B1. 3. Generate a random 256 bit value as the hash target for the next input "Ref 1C". 4. Generate the TXID of B. 5. Generate the ID of 1B by scanning the TXID of B and a nonce to until it matches the value referenced in A1. 6. Sign and publish B. Confused about this method. You make it hard for legitimate owner of utxo A1 to spend because he has to do proof of work. I dont understand if this really does anything useful though. It's not clear. But what is clear is if you require a full match in step 5 to a 256 bit value, they will never be able to spend it. No one will. why can't the owner of A1 perform the above series of steps twice for 2 different receivers and publish each transaction to different nodes and since their's no consensus mechanism, that will cause a fork in the network. ??? Hello OP, any new ideas? I hope you didn't just quit on this. |