please delete

[SapphireSpire]

nothing to see

[1714111159]

1714111159

[1714111159]

1714111159

[1714111159]

1714111159

[1714111159]

1714111159

[1714111159]

1714111159

[1714111159]

1714111159

[ranochigo]

Imagine a brand new network from scratch. It operates sort of like a chat room, where every node has a list of all other nodes by pseudonym.

It's not exactly feasible for nodes to be able to obtain the IPs of every node, especially with dynamic IPs which means that the nodes would have different IPs every now and then. It would be impossible for them to tell which one is active if they do not connect to each node every now and then. And that is infeasible as well.

1. Every node generates it's own blockchain at zero difficulty. It's okay if nodes have different blockchains. What matters is that they all record the same transaction history. Nobody publishes their blockchain anyway.

It's not possible for every node to keep the same transaction history without some sort of consensus. Having each node operate independently of each other means that no one can be sure if they have the full transaction history.

2. Every once in a while every node gets an opportunity to publish a coinbase transaction for itself- a participation bonus!
This can be regulated by a time limit or a turn-based system or something along those lines.

Which means, the one who has the most nodes earns the most. Who is going to determine who gets the "participation bonus"? No one can keep track of how long which node has been online for without a constant connection and a central authority. This defeats the privacy and decentralised aspects of Bitcoin.

[pooya87]

1. Every node generates it's own blockchain at zero difficulty. It's okay if nodes have different blockchains. What matters is that they all record the same transaction history. Nobody publishes their blockchain anyway.

the whole idea of the blockchain is that everyone is in perfect sync at all times and has the same exact ledger. otherwise if for example i have a transaction output and spend it without telling everyone else then i can spend it more than once and only tell some. and the system will at some point fall apart.

Mining only forces everyone to use the same blockchain which isn't strictly necessary in order for every node to have the same transaction history.

no, actually mining is the process of updating the ledger with new changes in an irreversible way!

it is like wanting to spend money from your bank account but not have the bank update your balance! it can't work. each (bank) transaction has to be recorded in their database to update the "ledger" so that if you tried spending more than your balance, the system prevents you.

in bitcoin we don't have balances, we only have transactions that are either spent or unspent. the ledger has to be updated each time through an irreversible costly process called mining so that when a transaction output was spent the subsequent attempts at spending the same thing fails.

[HeRetiK]

Nobody ever knows the full history but if a node appears to be lacking data, it can simply wait or request it from the network. In Bitcoin, transaction messages are constantly being validated and relayed between peers. How is that not a consensus?

Because it doesn't resolve conflicting ledger states.

The challenge is not to share a consistent ledger state across multiple nodes -- the challenge is to solve this in a way that still works even when someone is actively trying to manipulate the ledger in their favour.

There's only one node per IP address though, not per wallet, so nobody is going to be hosting a million nodes on their PC.

There can be millions of IP addresses per node though. Attacking a network by pretending to be millions of IP addresses is fairly easy comparing to attacking a network by obtaining a decent amount of hashpower. Which is one of the reasons why PoW has been invented to begin with (even before Bitcoin, look up Hashcash).

[HeRetiK]

If you do get one or more double spend transactions, all of them should become invalid and the output(s) they attempted to spend should be locked so it can never be spent again.

What if only part of the network sees the double-spend attempt? Now part of the network will lock the outputs and part of the network will accept it as valid.

What if there's a double-spend attempt using outputs that are already spent? In the network you describe you have no idea whether everyone has the same ledger state so while one node may accept a transaction based on what they deem a "confirmed" output another node may flag it as a double-spend, lock the coins and therefore invalidate all subsequent transactions.

In Bitcoin, it's the block interval that prevents double spending, not the blockchain.

The block interval only keeps the orphan rate at bay. In itself it does nothing to prevent double-spends.

What prevents double-spending is cooercing miners to cooperate into cryptographically sealing the ledger state, creating a tamper-proof time-stamped history of transactions that all nodes in the network can agree upon.

[pooya87]

off the top of my head a simple Sybil attack would mean you can end up accepting a transaction that is double spent without knowing it until the attack stops. all the attacker has to do is to fill your inbound connection slots with his own connections and prevent you from finding the double spend from others.

[HeRetiK]

If an output is spent, it means the network is aware of it so, why would anyone accept a transaction that attempts to double spend it?

Because:

There's no such thing as instant flawless communication.

It is also worth noting that:

[...] all nodes receive all messages eventually.

...the above can not be ensured. Outages happen. DDoS attacks happen. In the scenario in this thread the correct order of events is not known and not consistent across nodes (e.g. what happens if a node receives a transaction that spends the outputs of a transaction it hasn't seen yet?).


In general this approach reminds me very much of what we see in DAG-based coins. Problem being even these coins have to rely on some form of central coordination to prevent things from going awry (eg. IOTA's coordinator and ByteBall's witnesses) despite being far more fleshed out.

[DannyHamilton]

Please explain how your system would handle the following...


You, and ranochigo are both running nodes on your coin network.

I am running TWO nodes on your coin network (Node_A and Node_B). My Node_A is communicating directly with your node.  My Node_B is communicating directly with ranochigo's node.

All nodes on the entire network have confirmed and validated that I have control of 1 coin on this network.

I create 2 transactions.  One of the transactions spends my entire coin and sends it to you. The other transaction ALSO spends my entire coin, but sends it to ranochigo.  I place the transaction that is sending my coin to you on my Node_A (the node that is communicating with your node).  I place my transaction that is sending my coin to ranochigo on Node_B (the node that is communicating with ranochigo's node).

Then, I trigger both nodes to send their respective transactions simultaneously.  Your node hears from my Node_A that I've just sent you 1 coin.  ranochigo's node simultaneously hears from my Node_B that I've sent him 1 coin.  You both believe you've been paid 1 coin.

Both transactions trace cleanly back to a coinbase transaction with a valid POW. All inputs and outputs are valid.  But, since you seem to think that "nobody needs to know the precise chronological timing of transactions", there is no way to tell the rest of the network which of these two transactions came first.  They are essentially simultaneous as far as everyone else is concerned.

Which of you has ACTUALLY been paid? How will the other nodes in your network determine which transaction to include in their blockchain and which to reject?


This is one of the most important problems that Bitcoin Mining solves.  There are other variations on this, but I'll save those until/unless you can explain how your system handles this exact situation.

[pooya87]

Notice how you had to make use of two nodes to attack the network. The ability of clients to manage multiple nodes would be very useful in analyzing network health, improving message routing, and detecting attacks.

you don't really need to run "two nodes", heck you don't even need to run one node! all you need is less than 100 lines of code to open two sockets to two receiving node's endpoint, construct a couple of messages (version, verak, tx), build two (or any number of) transactions with different outputs and send them on each socket!

[Wind_FURY]

3. Validation
Coinbase transactions are confirmed by their proof of work while regular transactions are validated by confirming that the inputs spend valid outputs. All transactions trace back to one or more coinbase transactions.

4. Blockchains
Every node generates it's own blockchain at zero difficulty. It's okay if nodes have different blockchains. What matters is that they all record the same transaction history. Nodes share transaction history but nobody publishes their blockchain.

What could possibly go wrong?  

I'm the stupid one, but I'll give it a go.

Collusion by bad actors in the network? What assures your network of "safety" in an adverserial environment?

[DannyHamilton]

. . . You only have a brief window of opportunity to get away with whatever you paid for with one or both of your transactions before . . . it's "game over".

. . . you only have to wait a few seconds. I also have a rule that when more than one properly signed transactions spend the same output, their outputs cannot be spent . . . they each invalidate the other. Most of the network will see this . . . any node that attempts to accept a transaction that spends the output of either transaction will be immediately rejected by it's peers . . .

Great.  The problem is... When you try to invent something new without really understanding all of the underlying problems, you end up breaking something every time you try to fix something.

Now that you've explained your solution to the problem that I presented, you've created a new problem.


You, and ranochigo are both running nodes on your coin network.

I am ALSO running a node on your coin network. My node is communicating directly with both your node and ranochigo's node.

All nodes on the entire network have confirmed and validated that I have control of 1 coin on this network.

I create 2 transactions.  One of the transactions spends my entire coin and sends it to you. The other transaction ALSO spends my entire coin, but sends it to ranochigo.  I broadcast the transaction that sends my coin to you.  I wait until I've received my product or service from you.

Then, I trigger my node to broadcast the transaction that pays ranochigo.

From what you just explained, this new transaction invalidates the transaction that paid you.

"I also have a rule that when more than one properly signed transactions spend the same output, their outputs cannot be spent . . . they each invalidate the other"

Every node on the network will share this new transaction, so everyone will know not to accept the coin that you are holding.

You now have a coin that you can never spend.  I've got my product or service, and I've lost the amount that I intended to pay for it, so I'm not harmed at all.  You, however, are screwed.

Both transactions trace cleanly back to a coinbase transaction with a valid POW. All inputs and outputs are valid.  But, since you seem to think that "nobody needs to know the precise chronological timing of transactions", there is no way to tell the rest of the network which of these two transactions came first.  They are essentially simultaneous as far as everyone else is concerned.

Any new rule that you create (which doesn't include either mining a blockchain or a centralized service) to solve this problem, is just going to create another problem..  Shall we keep going until you finally begin to understand the problems that Bitcoin solved?

[HeRetiK]

So it's important for all nodes to know and share the average propagation time of the network. Any two or more transactions received within that time are treated as double spends and invalidated. Any additional transactions received beyond that time after the first are simply rejected. Merchants only need to wait that long after receiving a payment before rendering goods or services for 95% of the network to know that there are no double spends and no risk of invalidation.

So now we have a network filled with adversarial nodes that share a wrong propagation time. The "average propagation time" can be moved towards any arbitrary value depending on what the attacker wants to achieve. They can push the timeframe down to a few milliseconds, or the can inflate it to a few years. Both of which will render the network unusable.

[Wind_FURY]

Collusion by bad actors in the network?

What assures your network of "safety" in an adverserial environment?

The first concern is the distribution of clean and reliable copies of the client software.

Then next concern is the distribution of malware in message payloads. The only solution is to scan everything.

I'm confused. I don't know if you didn't understand me, or if I misunderstood you. Because collusion is simply a collusion by bad actors to co-opt the network using the same software as the honest nodes.

To take control.

[HeRetiK]

So it's important for all nodes to know and share the average propagation time of the network. Any two or more transactions received within that time are treated as double spends and invalidated. Any additional transactions received beyond that time after the first are simply rejected. Merchants only need to wait that long after receiving a payment before rendering goods or services for 95% of the network to know that there are no double spends and no risk of invalidation.

So now we have a network filled with adversarial nodes that share a wrong propagation time. The "average propagation time" can be moved towards any arbitrary value depending on what the attacker wants to achieve. They can push the timeframe down to a few milliseconds, or the can inflate it to a few years. Both of which will render the network unusable.

How will adversaries know whether to push the wait time up or down? Unless they're all cooperating, they will be working against each other as well as the network.

That's the point. There's no need for cooperation as a single adversary can relatively simple take over the vast majority of the network.

Mining costs a significant amount of electricity so attacks are both expensive and logistically hard to pull off. At least in terms of Bitcoin and most of the larger alts.

The payment system you are describing can be crippled for days on end by spending a couple of hundred bucks on your friendly neighbourhood botnet-operator (or AWS, for that matter). I'm not even kidding.

[DannyHamilton]

I also have a rule that when more than one properly signed transactions spend the same output, their outputs cannot be spent . . . they each invalidate the other.

Great.  The problem is... When you try to invent something new without really understanding all of the underlying problems, you end up breaking something every time you try to fix something.

Now that you've explained your solution to the problem that I presented, you've created a new problem.

Any new rule that you create (which doesn't include either mining a blockchain or a centralized service) to solve this problem, is just going to create another problem..  Shall we keep going until you finally begin to understand the problems that Bitcoin solved?

. . . it's important for all nodes to know and share the average propagation time of the network. Any two or more transactions received within that time are treated as double spends and invalidated. Any additional transactions received beyond that time after the first are simply rejected. Merchants only need to wait that long after receiving a payment before rendering goods or services for 95% of the network to know that there are no double spends and no risk of invalidation.

Now you've referred to a "first".  Remember that you said: "nobody needs to know the precise chronological timing of transactions, it's unnecessarily strict".

That being said, let's take a look at how this new scenario is broken...

The problem is... When you try to invent something new without really understanding all of the underlying problems, you end up breaking something every time you try to fix something.

Like before, my node is connected to both you and to ranochigo...  Meanwhile, Wind_FURY and HeRetiK are elsewhere on the network.  They aren't directly connected to any of us. I spend the exact same coin sending both a transaction to you that pays you, and a transaction to ranochigo that pays him.  Both transactions begin to propogate through the network.

The transaction paying you reaches Wind_FURY before the common wait time.  The transaction paying ranochigo reaches HeRetiK before the common wait time.

However...

The transaction paying you does NOT reach HeRetiK until AFTER the common wait time.  The transaction paying ranochigo does NOT reach Wind_FURY until AFTER the common wait time.

So, as far as HeRetiK is concerned (and everyone else that received your transaction after the common wait time), according to your current rules of "Any additional transactions received beyond that time after the first are simply rejected", ranochigo got paid, the transaction paying you is simply rejected.

As far as Wind_FURY is concerned (and everyone else that received ranochigo's transaction after the common wait time), you got paid, the transaction paying ranochigo is simply rejected.


How do HeRetik and Wind_FURY resolve this inconsistency?  There are no timestamps.  There is no centralized entity to sort it out.  There is no mined blockchain to sort it out.

Any new rule that you create (which doesn't include either mining a blockchain or a centralized service) to solve this problem, is just going to create another problem..  Shall we keep going until you finally begin to understand the problems that Bitcoin solved?

Using your "timing rule"...
You ARE GOING TO HAVE some nodes that see both transactions within the common wait time (group_A).
You ARE GOING TO HAVE some nodes that only see your transaction within the common wait time (group_B).
You ARE GOING TO HAVE some nodes that only see ranochigo's transaction within the common wait time (group_C).
You ARE GOING TO HAVE some NEW nodes that try to join the network and try to synchronize from any possible combination of group_A, group_B, and group_C.

[Wind_FURY]

That's impossible. A node can't have low latency for some transactions and high latency for others. They either have low latency for all or high latency for all. Any node capable of getting any transaction within the wait time is going to get all transactions within the wait time.

I believe it can. Maybe ISP issues for a node, bad-actors DDOSing honest nodes, or some other adversarial reason. You cannot predict it as "either have low, or high latency". Something might happen.

[HeRetiK]

That's impossible. A node can't have low latency for some transactions and high latency for others. They either have low latency for all or high latency for all. Any node capable of getting any transaction within the wait time is going to get all transactions within the wait time.

It's not only possible, it's also very common. Even under normal network conditions, without adversarial behaviour by other nodes. It's part of what makes logic that relies on network connections so tricky.

[DannyHamilton]

That's impossible. A node can't have low latency for some transactions and high latency for others. They either have low latency for all or high latency for all. Any node capable of getting any transaction within the wait time is going to get all transactions within the wait time.

Sure it can.  It all depends on where the transactions are coming from, and how many nodes need to forward it before it gets to the destination being discussed.

For example, imagine that HeRetiK's node has a direct connection to your node, and you are both in China.  Imagine that Wind_FURY's node has a direct connection to ranochigo's node and they are both in the USA.  Imagine that China is filtering all communications in and out of their country, and that this filtering is adding a delay to communications between China and the USA.

If I'm in the USA and send a transaction directly to your node...  It may take a while for that transaction to get to you, but once you see it, you will very quickly get it to HeRetiK's node.  So HeRetiK will see it immediately after you, but it could be delayed beyond the common wait time to get back out of China (from you, HeRetiK, or anyone else in China) to Wind_FURY.

A few milliseconds (microseconds?) later, I send the transaction to Wind_FURY. Since he's in the USA with me, he sees that competing transaction immediately, but it could be delayed beyond the common wait time to get into China (from me, Wind_FURY, or anyone else outside of China) to HeRetiK.

So, HeRetiK accepts your transaction as the legitimate one, and Wind_FURY accepts ranochigo's transaction as the valid one.

The problem is... When you try to invent something new without really understanding all of the underlying problems, you end up breaking something every time you try to fix something.

Any new rule that you create (which doesn't include either mining a blockchain or a centralized service) to solve this problem, is just going to create another problem..  Shall we keep going? Or are you finally begining to understand the problems that Bitcoin solved?

[DannyHamilton]

Correct me if I'm wrong but, I believe the 2nd transaction is supposed to go to Wind_FURY who then passes it to ranochigo.

You are wrong.  See my post above where I first discuss the split possibility due to transactions arriving after the common wait time:

. . . Like before, my node is connected to both you and to ranochigo...  Meanwhile, Wind_FURY and HeRetiK are elsewhere on the network.  They aren't directly connected to any of us. I spend the exact same coin sending both a transaction to you that pays you, and a transaction to ranochigo that pays him . . .

So, in the end, HeRetiK would accept the 1st transaction from me before getting the 2nd and ranochigo would accept the 2nd transaction from Wind_FURY before getting the 1st.

Use whatever scenario helps you to see that this isn't going to work.  However, the specific scenario I described involved payments to YOU and ranochigo (sent to YOU and ranochigo respectively) and involved HeRetiK and Wind_FURY ending up split on which coin was valid to receive in the future (the one you now have or the one ranochigo now has) . . .

Both transactions begin to propogate through the network.

The transaction paying you reaches Wind_FURY before the common wait time.  The transaction paying ranochigo reaches HeRetiK before the common wait time.

However...

The transaction paying you does NOT reach HeRetiK until AFTER the common wait time.  The transaction paying ranochigo does NOT reach Wind_FURY until AFTER the common wait time.

So,
As far as HeRetiK is concerned . . . ranochigo got paid, the transaction paying you is simply rejected.

As far as Wind_FURY is concerned . . . you got paid, the transaction paying ranochigo is simply rejected.

How do HeRetik and Wind_FURY resolve this inconsistency?  There are no timestamps.  There is no centralized entity to sort it out.  There is no mined blockchain to sort it out.

This could happen if the wait time was arbitrary and static, or based solely on propagation delays in the USA, but the wait time I described here is based on average propagation delays between all peers as measured by all nodes without regard to geographic location and it adapt to changes over time. So the wait time should be long enough for the 1st transaction to get to ranochigo and for the 2nd transaction to get to HeRetiK.

There is, however, a remote possibility of desync if China's filtering algorithms cause a sudden spike in latency, before the network has time to adapt. Or, if they block all traffic completely (like an eclipse attack), it could split the network up and cause a fork. I'm still working on these issues.

I'm sure you are.  People have been working on these issues for decades.  You haven't suggested anything yet that wasn't already suggested and shot down decades ago.

Are you familiar with the phrase:  "Those that fail to learn from history are doomed to repeat it?"

Your lack of knowledge and understanding are wasting your own time and the time of everyone that chooses to interact with you on this.  Every time a solution is proposed to the current shortcoming, that solution will result in a new shortcoming being created.  In the end, assuming you are able to find a workable solution at all, the solution you'll finally "discover" will either require the involvement of some central authority or will block mining.

Prior to Bitcoin, these synchronization issues were always handled by a centralized authority.  The mined blockchain was the first (and only) solution so far that was able to maintain synchronization while completely eliminating the need for a centralized authority.  Anything that depends on timing will always have issues of some people receiving the information sooner than others.

[Wind_FURY]

Your lack of knowledge and understanding are wasting your own time and the time of everyone that chooses to interact with you on this.

I believe people should stop giving merits to topics that have questionable assumptions such as these. Other stupid ones like me might be too quick to believe in the OP.

But I learned something. Thanks.