Quote from: d5000 on July 02, 2025, 07:55:08 PM

I see you updated the OP, @SapphireSpire. But I don't see how the changes really solve the problems pointed out.

Quote from: SapphireSpire on June 30, 2025, 01:43:50 AM

Each output gets a big list with 100 to 1000 addresses, for redundancy. Once the sender broadcasts their transaction, their address is added to the pool so they can be selected as a cosigner by other users.

Again, there is no global mempool, so it's the nodes themselves who select the "big list of addresses". And that continues to be the problem here. There is no way to prove a transaction was broadcasted. All ways to achieve this can be sybil attacked (or involve traditional byzantine fault proof algorithms, like PBFT, or PoW or a similar mechanism).

Quote from: SapphireSpire on June 30, 2025, 01:43:50 AM

The highest address on the list is valid.

What's the "highest address"? The address with the oldest output perhaps? Still the node of the attacker compiles the list, not some "global entity". So again -- they can "grind" through different configurations and eventually they'll reach a state where they can sign a double spend transaction.

What you would need is some interactive mechanism where you can ensure that really different nodes interact with each other which are not from the same entity. And there you'll probably need PoS or PoW to achieve this via incentives.

Quote from: SapphireSpire on June 30, 2025, 01:43:50 AM

If a double spend attack involves multiple transactions with one input for the same UTXO, the fee goes to the highest cosigner on the list who correctly signs just one input. UTXOs are subject to change by this process until the top cosigner responds, or an output is spent.

I don't see how that changes the problem described above.

Quote from: SapphireSpire on June 30, 2025, 01:43:50 AM

If a double spend attack involves multiple transactions, each with multiple inputs for the same set of UTXOs, the inputs should be listed by the size of the TXIDs of the UTXOs they reference in ascending order and cosigners must sign them in that order to avoid signing more than one transaction. The one who correctly signs the first input is the one who ultimately decides which of these transactions is valid.

Let's see how a double spend attack would be carried out in that protocol:

- Attacker pays to merchant.
- In that payment, the attacker ensures that he's the only one who co-signs the payment with one of his addresses. He can compile as many lists as he wants.
- Attacker gets the (virtual) good he wants to purchase, or if the victim is an exchange withdraws everything via cryptocurrency.
- Now the attacker builds a new transaction with the same UTXO. Again he ensures that the list only contains cosigning addresses of his own nodes. Again he can complile as many lists as he wants.
- The attacker deletes all remnants of the old transaction and its cosigners from his nodes. There may be other nodes, apart from the victim's node, still having the old transaction in their database. But the attacker simply tries to outnumber these nodes via a sybil attack, so the new transaction becomes part of the "consensus".

The sybil attack in the last step is the problem PoW (and at least partly PoS) solve, and that's what's missing in the protocol.

@stwenhao: If the protocol doesn't work on its own, then you're correct, the lineage back to genesis via PoW would then be the only protection. But in my post I referred to the (unlikely) situation that the protocol works.

Sybil attacks are used to subvert reputation and voting systems. The random selection of addresses into priority lists is not a reputation or voting system. As long as the opportunity to make the decision of "what transaction is valid" is randomly distributed among all addresses, and the network can never be stuck or fooled by any choice the decider makes, it doesn't really matter who makes the decision. So go ahead and grind out lists so you can flood the mempool with transactions that contain your addresses. Perhaps that's the work that's missing.