Yeah, but where are the developers? Litecoin's testnet has been split for over 5 days, with the depth of fork counting in thousands of blocks. And not a single comment from anybody? https://chain.so/testnet/ltcWhere's the Litecoin's development community? |
|
|
|
Ahh ok thanks, I've passed the word on to the devs.
So... Any of "the devs" still alive? The only non-dead public block explorer for Litecoin's testnet shows the last block as 641435 mined 5 days ago (although the page says "2 days ago"). I'm CPU-mining on that fork with optimum speed that wouldn't rise difficulty from the minimum, which according to my calculations is about 3500 hashes per seconds to stay at difficulty equal to the minimum of 1/4096. I'm currently up to 64196 as of this writing, but I don't see a way to verify that anyone was able to synchronize off of my machines. And they are for sure accessible from outside, both via IPv4 and IPv6. I did receive and mined some transactions earlier today, so some communication does exist, because I don't currently transact on my internal Litecoin testnet nodes, only CPU-mine. The competing chain seems to be at block 644512 and is getting mined at difficulty 0.00312973 which is ~2.8 times higher than the minimum. While that would be still in the CPU-mining range, I have my test servers in storage and I'm not looking forward into deploying them. This situation is indeed very worrying, because it clearly shows Litecoin Core client as faulty. Quoting for future reference: Any update about it?
I'm still worried how this kind of fork can exist.
Anyone here can post their current experience of synchronizing with the Litecoin's testnet? If possible do both resynchronizing the old install and a fresh resynchronization from scratch as another user on the same hardware and with same software. |
|
|
|
i don't think it was a test. not in a conventional way.
it seemed to me more like proving a point, maybe the group behind it was trying to force increasing fees, or some say the block size.
did anybody take responsibility for the test/spams yet?
Well, the 'stress tests' could have many objectives, some of them public some of them non-public. It reminds me of the old story about hiring telegraph operators, when the telegraph was a novel, high-tech invention. There was a standard 'help wanted' add published in a newspapers and the candidates were directed to a thin-walled waiting room. One could hear the din of many telegraph operators working inside. But the hiring manager didn't invite anyone for an interview. He just sat right behind the wall and loudly tapped in the Morse code "QUIETLY GET UP, GET OUT OF THE ROOM, WALK UP TO THE FRONT DOORMAN, TELL THEM ABRACADABRA-2112 AND YOU WILL BE HIRED IMMEDIATELY" (I don't remember the exact, difficult to understand in Morse, test phrase, so I wrote ABRACADABRA-2112). The hiring manager knew that the best operators are those who can read Morse by ear, not just sight-reading the tape. Something similar probably happened during this test. The private keys used in the tests weren't exactly 'private', those were some rather obvious brainwallet-style phrases/words. So maybe the true information sough was: who was going to try (double-)spend those transactions and to what addresses are they going to direct the funds? |
|
|
|
The algorithms there were secret, but the data was not, at least, that is what I understand. They gathered publicly available data from the blockchain and used their own secret algorithms to analyze and do something with the data. The information is public, you just need to figure out how to analyze it and use it yourself.
All right, this is a proof that you don't understand what you are talking about. They are analyzing data outside of the blockchain. The information was public, but volatile, it got forgotten by all those, who run bare reference client. |
|
|
|
If you want to keep all of those transactions, by all means do it. Write your own patch and set up your own nodes to log all of the transactions and data. Publish it publicly so that people can examine it. But don't make that something part of the reference client which forces everyone who runs that code to have to keep all of the data they don't want. For the average user, keeping all of those transactions so that someone can analyze them is pointless. I only want to run a node to help the network. I can't afford extra RAM and disk space to maintain the mempool and databases required for keeping all of those transactions. If you can do that, please do it, it may help the network. But I can't do that, so I will opt out.
And with opting out. Maybe it should be an option, like a supernode or something. It stores all of the transactions, but only for people that want to do that. It shouldn't be enabled by default, but perhaps such an option should exist for those that want to do that analysis.
I'm not aiming my explanations at those who "only want to run a node to help the network." I'm trying to reach people who try to incorporate Bitcoin into their business and really want to understand what is going on, who's winning and who's losing, who don't want to be "average user" meaning "average chump". The current prevailing mood of whitewashing history is going to change. I don't know exactly when, but it will happen. It is a lesson I learned from understanding many earlier technologies in the history of finance. |
|
|
|
There is a point in storing unconfirmed transactions in RAM. As a miner, nodes are holding those transactions in memory as the basis for forming the next block. Once the block is mined it needs to be broadcast - if the data is on disk then it adds extra latency to retrieve the data from disk before broadcasting it to the network. Yes, SSDs are very fast but for a miner there's no reason to introduce any latency in a system where speed is relevant and contributes to profitability.
This is a very naive view that you are exhibiting. I don't get a "code monkey" vibe from you, seems like you misunderstood the various technical and architectural possibilities. Your concern over block broadcast time is valid, but the implications you make are false on several levels. 1) One could simply store in RAM the subset of 'mempool' that is included in their block mining template, ready for broadcasting as soon as valid header hash is found. 2) "mempool" could be stored in a general https://en.wikipedia.org/wiki/In-memory_database, with or without hybrid on disk storage 3) any sensible general-purpose database system will have a cache where the recently accessed items are stored. 4) there are at least two pending proposals that do away with duplicate sending of transaction after the block header: Matt Corallo's relay network and IBLT alternative block broadcast protocol. I hope my explanation made it clearer for the readers of this sub-forum why futzing with mempool at this stage is very similar to the optimizing time after Ctrl-Alt-Del that it takes MS-DOS to reboot. |
|
|
|
The great thing about bitcoin is all that information is public. If you think fraud, double-spend, abuse malleability, etc. are important, you're quite welcome to write a node that analyzes those issues. Sounds like an excellent project.
"All information is public"? This is very far from true. Of the top of my head I could name at least two companies doing a non-public information gathering using secret, proprietary algorithms: blockcypher and chainalysis. Personally, I'm not interested into going into very narrow market like that. You are on this forum longer than I do. How could you miss the discussions about explicitly logging valid double-spend attempts? I mean, even before I registered here, there was a non-open-source patch to Satoshi's code doing that logging. And the people who were selling it had as one of the selling points "the concept was rejected by the core development group from the inclusion into the reference client." Doesn't that speak something about the later successful double-spends? |
|
|
|
Great lets exponentially increase bandwidth+storage requirements at 0 cost because fraud attempts knowingly will pay 0 fees and won't get in to a block but will be stored on the harddrives of their victims causing the whole network to shutdown in just a few days.
You don't know what you are talking about. Move along.
Yeah, exactly as expected, the typical shit-slinging from a code monkey warning about "exponential increase" and "network shutdown". This is a general discussion group, so it may be better to frame the explanation in the terms more familiar to the less experienced computer user, not a software developer. The popular Apache web server has in the typical configuration two log files: "access" and "errors". The first is logging the boring stuff that can be later compiled into various statistical graph. The second one logs the interesting and unusual events. The second one is where one would look for e.g. hack attempts, abuse, etc. The typical reasonably popular web site may have a constant stream of invalid login attempts from all over the world, and storing all of them has a little value. On the other hand a single attempted login to the administrative account with revoked password (meaning a valid password that was replaced by a new one) could be a breakthrough in the investigation of the internal fraud. E.g. it was from Israel and the organization recently fired for drunkenness a holder of two passports, one of them Israeli. Similar reasoning applies to logging errors over Bitcoin network. A slew of completely invalid transactions is of little interest. On the other hand a single invalid/conflicting transaction bearing a correct signature is potentially very valuable indicator. I'll encourage the readers who happen to be interested in the discussed concepts look up "fraud proof" and "compact fraud proofs". |
|
|
|
What do you want it to do? hold tx's in mempool for longer time increasing memory requirements exponentially across the network? The real value of using the system is for VALID transactions. Ofcourse people are free (not literally) to try to fraudulently create bad tx's but that is the beauty of the consensus protocol that doesn't allow these to be entering the network and creates the value of what we call Bitcoin.
In software speak, I suggest we follow KISS which is what it is. A clear seperation of concerns and not worry about holding metadata or increasing tx lengths because of another small use-case of analytically drawing conclusions from that dataset that does not strongly correlate with the true intention of Bitcoin.
Indeed. There's a balance to be struck in any such risk/reward scenario. I can't see how the cost required would outweigh the relatively small benefit of having an extended record of the mempool. And if we did keep a record of anything that doesn't make it into the blockchain (i.e. errors and omissions) , how do you then make that record decentralised and tamper-proof? We'd have to have a new blockchain that records what doesn't go into the original blockchain, heh.
I kinda knew it that my post is going to attract some code monkeys and their attempts to burn the strawmen. I'm just going to quote them for the future reference. Anyway, for non code monkeys, the longer explanation is as follows: There's absolutely no point of storing the unconfirmed transactions in RAM. As any competent software engineer will explain you it is sufficient to store a cache (or map, in CS terms) of transaction hash to single bit, meaning "transaction was seen and it is known to be 'valid' or 'invalid'". The 'valid' transactions will ultimately get promoted to the permanent blockchain, the 'invalid' transactions are mostly of the forensic interest to investigate errors and attempted frauds. The transaction not in cache are neither 'valid' nor 'invalid', they just need the full verification run. Obviously, some of those code monkeys are in the employ of the fraudsters who explicitly rely on their fraud attempts to get no permanent record on the blockchain. That's why I quoted them above, we'll see what fraud they will try to cook up. |
|
|
|
Thanks to you and other who replied with this. Unfortunately I do not speak code, but I have read a couple books and the white paper and such and never saw this mentioned. Makes me kind of nervous, but I guess nothing to worry about as long as the tx backlog is small.
It is opposite to "nothing to worry". It is one of the most troublesome features of Bitcoin, it whitewashes any attempts to fraud, double-spend, abuse malleability, etc. Any real accountant or other financial professional will tell you that "when in doubt, look through the 'errors and omissions' file/account, that's where the truth is". Bitcoin is the opposite, by design it forgets about any attempt of abuse. If you ever wonder "why fraudsters love Bitcoin?", this is the partial answer as to "why?". I don't remember the specifics, but in the traditional financial system the attempts to "kite a check" or "overdraw" are stored longer than the regular transactions, just because their value as the indicator of the trustworthiness is much better than the numbers of the uncontested transactions. It is something like '10 years' in the 'errors&omissions' versus '1-2-3 years' in the 'regular' file. Edit: Speaking in the Bitcoin terms: The (financial) value of analyzing 'mempool' is significantly higher than analyzing 'blockchain (as stored on the disk for the "longest chain"'. |
|
|
|
I have Mac version 10.6.8
That might be the problem. You are using an old unsupported os. Bitcoin Core 0.10.2 works without any problems on Mac OSX 10.6.8. The "quit unexpectedly" error is for sure not caused by the combination of software. I've been running this version of OSX and various version of Bitcoin on many Macintoshes without a problem. The only problem that I had with this combination was related to the bad disk drives that kept passing various Apple diagnostics until I grew suspicious and booted Debian Linux and run its diagnostics (badblocks). |
|
|
|
Where is this officially documented? Provide a link please. I find it concerning that a transaction sent could be "forgotten" by the network for any reason, that seems like a huge problem.
Use the Source, Luke! It is documented in the source code. The mempool is a really lame implementation of https://en.wikipedia.org/wiki/In-memory_database . There's no mempool synchronization in the protocol, so eventually the non-confirmed transactions will get forgotten as users restart their nodes. |
|
|
|
I'm not sure if we are talking about the same kind of fork. I'm talking about the two valid branches both running 0.10.2.2 code. Yesterday I had this reproduced with one machine at 0.10.2.2 Macintosh and the other 0.10.2.2 Windows. Today I added another copy on the Windows machine (running as another user). This way I have exactly the same code running on the exactly same hardware, the only difference are directories with the data and port numbers for the network traffic. The fork starts after block 641334, the first different block is 641335. C:\>litecoin-cli.exe -rpcport=19332 getblockhash 641334
745c3628a41b53b115add71ca304e0c3711447635a113a735b9d3c0357fb5ee9
C:\>litecoin-cli.exe -rpcport=1 getblockhash 641334
745c3628a41b53b115add71ca304e0c3711447635a113a735b9d3c0357fb5ee9
C:\>litecoin-cli.exe -rpcport=19332 getblockhash 641335
87dead3220e76a9b9a0422904bd17f3d3727236e4dbaf12d01f7ea186c7fd669
C:\>litecoin-cli.exe -rpcport=1 getblockhash 641335
2c90e25ac93447ab179f5dccd4ac776d79cb924048927bdfdad250eb012ad91a
Those aren't trivial short forks, they are several hundred blocks long C:\>litecoin-cli.exe -rpcport=19332 getblockcount
641756
C:\>litecoin-cli.exe -rpcport=1 getblockcount
641435
although the comparison above isn't completely fair, because I was starting and stopping those tasks as well as opening and closing respective network ports in the firewall (external to Windows). Can someone with an account at litecointalk.org repost this message there and ask for the comments from the developers? My thinking is that if somebody managed to split the testnet that far there maybe a bug lurking in the code that could be used to split the mainnet. |
|
|
|
BIP101, is not ideal, I'd rather have no limit, but it seemed the limit could grow faster than the Bitcoin network grows. and I like the fact that "eight" (八 Pinyin: bā) sounds similar to the word which means "wealth" in Chinese, and we have eight doubling so it should be appalling to those who are governed by superstition.
Appalling or appealing? It is hard to tell if you are serious or sarcastic. |
|
|
|
|
Did Litecoin testnet forked?
On my test machines {no real money or important data involved} I noticed that Macintosh 0.10.2.2 is at block 641381, whereas the Windows 0.10.2.2 is at block 641439. Litecoin mainnet and both Bitcoin nets are still staying in sync on the same physical hardware.
Those are test machines, so I blew away 'chainstate' and 'blocks' directories on Macintosh and restarted the synchronization with -connect to the Windows machine. The synchronization stalled at block 640000 with repeated errors:
ERROR: ContextualCheckBlockHeader : rejected nVersion=2 block
ERROR: invalid header received
The synchronization went 381 blocks further when I removed -connect and let it synchronize from the Internet.
Anyone here knows what is going on?
|
|
|
|
Running win 8.1 64-bit with all updates with 32GB of RAM.
I'm thinking about how to diagnose the possible hardware issue later tonight, thanks for the suggestions.
Oh, so it is a very modern hardware. In that case check it up for "row hammer" memory failure. I heard that the hardware that is susceptible to row hammering is being sold cheaply all over the world because the old memory tests don't yet have specific diagnostics for that fault. |
|
|
|
Is this indicative of a hardware problem on my computer? It really never crashes, it's been perfectly stable generally, and other programs work fine. I ran some memory tests and disk scans just to be sure, and I tried switching the bitcoin data directory to an alternate drive and nothing has improved.
Exactly, it is a hardware problem. Bitcoin Core is really well optimized and stresses the machine very close to the theoretical limits. In particular "disc scan" isn't a good test, what you need is a "disk read-modify-write" test. Also, if your home PC is running Windows the unfortunate standard advice does apply: online antivirus programs are frequent culprits of corruption of databases, especially since a while back when some joker pushed a virus signatures into the Bitcoin blockchain. For your comparison: I have a very old kitchen computer, original Athlon 64 Clawhammer from 2003 running Windows XP SP1. It still runs fine 4 coin wallets {Bitcoin,Litecoin}*{mainnet,testnet} simultaneously. Here's another thread from another user who had "mostly stable" computer: https://bitcointalk.org/index.php?topic=1106669.0so you could commiserate together. |
|
|
|
|
It seems like the DDoS defenses are getting bit touchy. I observed that the page fetching speed and probability of failure depend greatly on which source IPv4 range I use. So currently I'm posting through the VPN server located in UK.
Theymos, is there any chance you could get an IPv6 subnet assigned from your ISP? You could then run bitcointalk.org in the dual-stack mode. We could at least learn if those that constantly DDoS your site could get themselves an IPv6 botnet.
You could also distribute that IPv6 address privately through PM to some trusted subset of users instead of publishing in normally through the DNS AAAA.
Do you think it is worth trying?
|
|
|
|
|
Thanks everyone. So my understanding is that it was bit of both:
a) some are flagged for running bitcoin-seeder that makes lots of outgoing connections attempts
b) some are flagged for running bitcoind that was choosen by somebody's else bitcoin-seeder as a reliable seed note and distributes that information trough the DNS
Thanks again for the explanations.
|
|
|
|
|
Show Posts
