Author

Topic: please delete (Read 138 times)

legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
October 24, 2021, 02:22:00 AM
#5
If you attempt to create a bunch of "counterfeit" transactions all spending the same output to different addresses, the only one that will be final is the one that happens to get on the longest chain tip.

So even if there ends up being multiple chain tips via a chain split, all nodes will eventually reject the other transactions for having a spent output.
legendary
Activity: 1456
Merit: 1175
Always remember the cause!
October 24, 2021, 01:40:55 AM
#4
OP,
Your proposed model lacks a measure for quantization of how committed other peers are to their advertised ledger state (mega blocks in your terms) it would be very easy for attackers to advertise whatever they want while there is no voting mechanism to resolve disputes properly.
Satoshi Nakamoto is the one who found a decent solution for this problem, and it is called Proof of Work.
copper member
Activity: 821
Merit: 1992
October 23, 2021, 04:39:48 PM
#3
Quote
can a counterfeit transaction be created that makes it look like the same signature spends the same utxo to a different payment address?
Yes. If you know the private key, you can sign as many conflicting transactions as you want. Zero confirmation transactions are not safe, because some mining pool can always broadcast one transaction to the network and create its own block with a different transaction that will transfer all coins back to the attacker. All that is needed is always trying to mine a block with non-broadcasted version of the transaction for each zero confirmation transaction, for which you know all needed private keys.

Quote
Nodes only need a single distributed block, a megablock, that only contains transactions with utxos.
How do you know who should receive transaction fees? With mining it is obvious that the miner who created the latest block matching the difficulty will get them. Without mining it should be somehow solved. You have two nodes and each of them received the same transaction. How to decide who was first? What if both are connected with the node that created the transaction? What will happen when they will be both connected directly in the future? Who was first and how it is decided without mining?

Quote
If the imported megablocks don't match, copies of the mismatching megablocks are shared between the peers they came from.
If each node is greedy and wants to get transaction fees, then each block is shared (because each node can claim all transaction fees), so there is a lot of traffic in the network, because coinbase transactions will be different for each node.

Quote
If all or any part of the imported megablock data is invalid, the node will eventually discover and correct it.
If there is no mining and each block is identical (except coinbase), then how to decide which coinbase transaction is correct? How to correct the coinbase transaction?

Quote
Only when a node gets a double spend does it broadcast about it.
It is exactly opposite situation to what we have now. Currently, each node can leave the network at will, because joining again and downloading missed blocks is possible. But if each node is required to know about each double-spending attempt, then all nodes have to be online all the time. Getting offline for a while can cause getting out of sync forever, because there is no mining. If one part of the network will receive transaction A and another part of the network will receive conflicting transaction B, then the network is splitted forever, because of first-seen-safe rule, each group of nodes think that another version is a double-spending attempt, so you have a different megablock for each group.

Quote
The utxo remains spent but both txs are discarded.  So it doesn't matter what order they happened in, the attacker loses.
If both transactions are discarded during each double-spending attempt, then many coins could be burned by accident. That means another kind of attack is possible: each first owner of the coin can always create some conflicting transaction and invalidate the whole chain of transactions at will. That means the best strategy is creating one coinbase transaction and one transaction moving all coins to yourself. Then you can create conflicting second transaction by sending coins to yourself and invalidate all later transactions. In this way early adopters are the most powerful participants, because they can send coins to themselves N times and then they can do double-spend by burning N times, so the true owners will be left with no coins, because previous outputs for their transactions will be burned by the attackers.

Quote
If even 1 honest node responds to double spend attacks, it will secure the whole network.
No, it is the opposite: if even 1 evil node responds to double spend attacks by burning coins, it will destroy the whole network by constantly invalidating transaction chains, just because the attacker is early adopter and can destroy everything by double-spending the coinbase transaction.
staff
Activity: 3458
Merit: 6793
Just writing some code
October 23, 2021, 04:11:25 PM
#2
If not then transaction history is not required to validate new transactions.
You don't explain why that would be the case.

If I were a new node, how do I know that the transactions I receive are real transactions? How do I know that the coins being spent are valid? Without a transaction history, how do I know that coins aren't being created out of thin air? There is more to validation than just double spend protection.

But it depends on whether or not it's possible to use the data in a valid transaction message to create a fake double-spend transaction that looks valid.
It is possible. Transaction malleability allows a third party to create a transaction that is technically a conflict (and thus double spend) of the original. The same outputs are being created, and the same inputs are being spent, but the scripts in those inputs are different yet still valid.

Nodes confirm new txs by remaining silent.
Only when a node gets a double spend does it broadcast about it.
The utxo remains spent but both txs are discarded.  So it doesn't matter what order they happened in, the attacker loses.
So what about new nodes? How does the information that those inputs are now unspendable get to nodes that weren't around at the time of the double spend? If you sync and are just told that "these inputs are unspendable", what is the proof that those inputs should be unspendable?
jr. member
Activity: 49
Merit: 38
October 23, 2021, 02:00:26 PM
#1
nothing to see
Jump to: