Topic: please delete (Read 934 times)
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.
If there is only one valid transaction at all, then it means you can send coins only to one person.
That's the idea.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?
Her keys, her coins.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.
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. 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".
He's not wrong but, you have to understand the context of what he's saying. The double spend problem exists because any transaction can spend an output. That's why you need to be aware of all transactions, so you can confirm the absence of all but one transaction. But he didn't say it was the only solution to the double spend problem. 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.
This really is a slippery problem. Just when you think you've solved it, it throws a curve ball at you.
The latest incarnation of the idea looks good. I don't see any hangups but I'll not be popping the champagne until it's peer reviewed.
The latest incarnation of the idea looks good. I don't see any hangups but I'll not be popping the champagne until it's peer reviewed.
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.
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)?
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. 
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. 
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-wasteful 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”.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.
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. 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.
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.
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...
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. 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". 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.
I'm hoping he hasn't given up on this. 
But if he has given up, then we might need a bit of help from Greg Maxwell on this one.
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.
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.
so it's not possible for 100% sure?
With the way they describe it? 100%
Jump to: