Topic: please delete (Read 555 times)

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. 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.

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.

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.

The common wait time is based on a weighted average of the shared averages. If the weight of every shared average were directly proportional to it's popularity, it would be vulnerable to a Sybil attack. Instead, it's directly proportional to the client's own average, which shouldn't differ much between nodes. The more your client's shared average differs from my client's own average, the less weight it will carry. If your client's shared average falls outside of my client's minimum and maximum stats, it may be ignored altogether. So even if your client controlled the vast majority of nodes, it won't control anything else. Other clients will just search for better peers and your client may end up getting dropped.

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.

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

---

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) . . .

---

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.

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?

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.

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.

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.

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.

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.

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.

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?

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?

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!

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.

Because:



It is also worth noting that:


...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.

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.

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.



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.

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 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).