|
ETHF trolls are very active = ETHF dump time comes again
|
|
|
|
Eth foundation will disappear once they finish pillaging the money. Etc is all decentralized volunteers
Who will contribute to the development of ETC if it does not have the support from a Foundation, maybe from hakcers? Who will contribute to the development of BTC if it does not have the support from a Foundation? |
|
|
|
I don't Know if you are aware of the lastest events but that visa-free travel and 20b€ agreement is never going to happen. It is a failure for Turks too. And it should be. Turkey and Germany acted together along with USA in order to overthrow Assad and steal his land and oil and they failed. Because Russia fucked them up. And now Turkey is about to change sides after the failed coup attemp of the USA. Don't get surprised if Turks take sides with Russia soon.
If you knew the story, and, sorry, versed in politics, you would not have written this nonsense here. Between Turkey and Russia differences are much greater than that between Turkey and any other country. I really don't know which planet you live in but I definitely know It is not Earth. Turkey and Russia were good friends before Turks took down their plane and later it is discovered that the person who hit Russian plane was a coup supporter. Turks used to have free visa to Russia and there were millions of Russian tourists who visit Turkey for vacations. Destroying that plane harmed both Russians and Turks. And who benefit from it? U S A The whole history of Russia is the endless war with Turkey. Until now, Russia's aim was to seize the Bosporus. Today, Russia is in an extremely difficult economic situation, it is threatened with a reduction in the EU's oil and gas sales, which will lead to the final breakdown of the empire, like the collapse of the USSR. Putin is hoped to sell gas to the EU via Turkey. But the EU has other plans. The EU hopes to get energy resources from the Caspian region through the construction of TANAP gas pipeline, which will pass through Turkey. However, this obstacle is aggressive polirika Russia in the Caucasus. The fact that Russia can singe smoldering Karabakh conflict, Armenians continue to give good seizure of Azerbaijani lands to the Great Armenia - Armenian Nazi goal of the Dashnaktsutyun party. By the way, Russia has a military base in Armenia, which says that it is a strategic ally of Armenia. In order to successfully continue the project TANAP, Turkey will conduct endless negotiations with Russia, giving her hope for the project "Turkish stream". Even if he still held, then Turkey may at any time abandon the Russian gas with gas from Azerbaijan have, the more the EU to break Russia's monopoly on gas delivery to Europe. Between Russia and Turkey, there is a complex political game. Read the topic "Trans-Caspian gas pipeline or a Third World War." TANAP pipeline is a farse. Everybody in the gas business knows that. Azerbaijan can not fill even 1/10 of its capacity. You'd better improve your relations with Russia or you'll end up as an American colony as Ukraine Nulandistan. |
|
|
|
This site can’t be reached
opentransaction.org’s DNS address could not be found.
|
|
|
|
ETH-fork is dead?
Why the '?' mark? Of course, it's dead. Nobody will use ETHF as fuel for their smart contracts if ETHC is x6 cheaper. You sell 1 ETHF and get 6 ETHC... Wow... What a deal. Thank you die hard forkers! Keep up the support for ETHF price! That is great news. The Expanse, SOIL is even cheaper. You should use those coins for the smart contracts. Irrelevant. There is no difference between ETHF and ETHC whatsoever. They are identical in every single bit of their technicalities.The only difference is that ETHF is forkable at the discretion of Ethereum central bankers if they decide to bail out greedy and stupid investors. |
|
|
|
ETH-fork is dead?
Why the '?' mark? Of course, it's dead. Nobody will use ETHF as fuel for their smart contracts if ETHC is x6 cheaper. You sell 1 ETHF and get 6 ETHC... Wow... What a deal. Thank you die hard forkers! Keep up the support for ETHF price! |
|
|
|
So, Alex Van De Sande thinks ETC is not worth having!
Please, tell Alex Van De Sande to send over to me those worthless ETHC! |
|
|
|
In Reply:
tylerderden
You are not using statistics in you posts.
Ethereum has retained over 80% of it's difficulty, therefore the miners are mining Ethereum (as supported by Ethereum Foundation) and not ETC.
This is why, your posts resemble the stuff you've been dreaming about!
lol The victim-of-uk-NHS... |
|
|
|
So, time to dump ETHF and buy ETHC again. |
|
|
|
Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.
A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke? You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be. To give a simpler example than I linked to, suppose the order book is in the following bid > ask state: sell 1 BTC @531 sell 1 BTC @530 buy 1 BTC @590 buy 1 BTC @529 If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.
This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet. I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590? In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is. On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated? Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price. So, what you actually explain now is different. Both ask @530 and ask @545 are already on the order book before bid @590 is initiated, right? I haven't changed anything but have assumed from the start that the bid @590 is put on the book after the other orders (should have made that clear). Didn't you say the following: If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. There is a very simple solution to this 'bug'. Out-of-the-market limit orders: - ask initiated below highest bid - bid initiated above lowest ask Every out-of-the-market limit order should be transformed into market order as soon as it is initiated! This is also safety measure against so called 'fat finger' mistakes. |
|
|
|
Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.
A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke? You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be. To give a simpler example than I linked to, suppose the order book is in the following bid > ask state: sell 1 BTC @531 sell 1 BTC @530 buy 1 BTC @590 buy 1 BTC @529 If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.
This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet. I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590? In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is. On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated? Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price. So, what you actually explain now is different. Both ask @530 and ask @545 are already on the order book before bid @590 is initiated, right? |
|
|
|
Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.
A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke? You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be. To give a simpler example than I linked to, suppose the order book is in the following bid > ask state: sell 1 BTC @531 sell 1 BTC @530 buy 1 BTC @590 buy 1 BTC @529 If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.
This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet. I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590? In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is. On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated? |
|
|
|
Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.
A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke? You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be. To give a simpler example than I linked to, suppose the order book is in the following bid > ask state: sell 1 BTC @531 sell 1 BTC @530 buy 1 BTC @590 buy 1 BTC @529 If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.
This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet. I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590? |
|
|
|
Alik Bakhshi
Refugees and the European strategic error
Accepting refugees from Syria and Iraq, Europe is actually indulging dictator Assad and the newly formed Islamic militants of Arab States (LIH). The fact that the majority of refugees, it is not the elderly and children, young and pretty aggressive young people who could easily organize a resistance that does not suit them, not to seek a better life outside their homeland.
Yes, there is European strategic error but it is just the opposite of what you explain. EC warmongers welcomed refugees because those aggressive young people would have otherwise joined the Syrian Army to fight moderate terrorists that are funded by some terror sponsoring Gulf monarchies. The idea behind EC policy was to give young Syrians a reason to be deserters and not join Syrian Army that defends their country from the blatant foreign intervention. |
|
|
|
Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.
A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke? |
|
|
|
Yelp, I'd agree, because no-one is going to want to build a business around a Network that does not care about criminal activity.
lol Money doesn't care about criminal activity! Money is Neutral with N like in Nature. Does Nature care about criminal activities? If Money isn't neutral that is not Money but coupons, vouchers, stamps, checks, tickets, bonds, certificates, notes, tokens... everything you want, but not Money! Money should account for everything that is in the economy and certainly crime is a part of every economy. There are many efficient ways to fight crime but destroying money isn't one of them because you'll make more harm than good! A bitcoin in the hand of a criminal has same purchasing power like other bitcoins. Well, that is money! Yeah, Bitcoin was 1st crypto coin - there was no choice. Now, business minded people can pick from up to 300 Alts Coins and when presented with this kind of choice? Business minded people will not build a business on a Network, which does not care about criminal activity. Ethereum has set a new "Gold Standard", by taking measures to prove to business minded people, that they won't passively accept criminal activity on the Network. Ethereum is not money. It is fuel for smart contracts. By bailing out DAO investors forkers degraded this fuel to a poisonous mixture concocted by Ethereum central bankers. |
|
|
|
Yelp, I'd agree, because no-one is going to want to build a business around a Network that does not care about criminal activity.
lol Money doesn't care about criminal activity! Money is Neutral with N like in Nature. Does Nature care about criminal activities? If Money isn't neutral that is not Money but coupons, vouchers, stamps, checks, tickets, bonds, certificates, notes, tokens... everything you want, but not Money! Money should account for everything that is in the economy and certainly crime is a part of every economy. There are many efficient ways to fight crime but destroying money isn't one of them because you'll make more harm than good! A bitcoin in the hand of a criminal has same purchasing power like other bitcoins. Well, that is money! |
|
|
|
|
What if Bitfinex lied for a profit? I just can't believe so many security locks have been breached. Military-style planning is needed to perform such a diverse attack.
|
|
|
|
positive note: all that exaggerated halving-positivity is vapourized.
Personally speaking I was expecting something like that to happen. Price suppression post-halving could last for so long without some source of coins, so they would have to "find" coins through other means (like hacks). Hacking for coins is an act of desperation for market suppression, yet fundamentals are stronger than pre-halving: Inflation is now -657.000 coins less per year than what it was pre-halvening. So even 110k coins is just 1 months supply at pre-halvening rate. I was expecting something like that too. All those "hacks" can be done only with help from insiders. |
|
|
|
|
ETHF bagholders are selling their cloned ethers for ETHC.
|
|
|
|
|
Show Posts
