4.Development of flexible software rather then all in one "take it or leave it" client, and eco system that would take advantage from it.
I'll say simply reorder this list: give your fourth item number 0. If and when the core software is properly modularized then everything else can build on top of it. Right now we have various proposals for restyling the body while the engine is barely working and in fact dropping its own bits along the road. And the drivers are all saying "all is well, look at our shiny new rims". |
|
|
|
They haven't done so. I tend to think the project is far beyond working against specific goals at this point and only working toward very focused ones.
Well, I probably cannot change your thinking. In my opinion the great part of the effective obfuscation is to appear constructive. I'll give you an example: Bitcoin protocol is a train-wreck of endianness and alignment problems. Yet while it was being developed some "core team" members were using MacOS X {Tiger,Leopard,Snow Leopard} which makes it almost trivial to locate and fix those problems. Consider the code: #include <stdio.h>
union {
char b[4];
int w;
} t = { 0x11, 0x22, 0x33, 0x44 };
int main()
{
return printf("%08x,%i\n",t.w,(int)sizeof(void*));
}
and its compilation and invocation: $ gcc -arch ppc -arch i386 -arch x86_64 bo.c
$ ./a.out
44332211,8
$ arch -i386 ./a.out
44332211,4
$ arch -ppc ./a.out
11223344,4
Now go search the history of this forum for discussion about the byte-order issues. Watch the mental gymnastics expended (especially by Jeff Garzik) to quash any work or discussion about this goal. I'll bet this will be very instructive to you, even if you disagree with me overall. |
|
|
|
which goal?
The goal of having multiple compatible implementations of the same protocol. The longer they have an effective control over the whole network in the hands of about 6 people the more time they have to monetize their investment of time into this project. It is quite amazing to watch an open source project that had successfully prevented any competing groups from developing a compatible implementation despite the source being in the open. Subtle changes in protocol, using corner cases of exception handling to prevent running the Linux client on the majority of commercial Linux distributions, reintroducing exact bugs fixed in earlier patches, etc. The whole arsenal of tricks of hardcore purveyors of job safety. I have to say that watching this project is a great learning experience for me. |
|
|
|
|
The key protocol data is incompressible: correctly implemented cryptography is indistinguishable from noise. I have feeling that you completely don't know what you talking about.
|
|
|
|
so i guess the solution is to modify bitcoind so that it can perform the functions of multiple bitcoind instances?
run several wallets at the same time, separately, all from the one binary and one set of ports.
I think I responded to you in the PHP thread. Your only hope is that libbitcoin development group delivers something useable. The core development team is actively working against this goal. What you have here is the essence of using obfuscated C++ code for the purpose of guerrilla warfare amongst the competing software development teams. Satoshi is/was a grand-master of it. |
|
|
|
You mean as in ram usage or are you talking about something else?
RAM doesn't seem to be a problem. The worst are: disk access queues and disk space usage. Then there's a CPU use spikes and network traffic spikes during operation when separate daemons duplicate their work. Last but not least is the outgoing network connectivity which gets close to launching a non-distributed DoS on the servers when your multi-bitcoind machine restarts after maintenance. Overall it isn't pretty and it would be hard to maintain and troubleshoot. |
|
|
|
Is is possible to run multiple bitcoind instances on a single machine?
Yes. Each one has to be under a different account and use "-rpcport" (documented) and "-port" (undocumented) or "-nolisten". The overhead can be stupendous though. |
|
|
|
though the result is the same, there is a huge difference between leaving a door unlocked to your bank and someone stealing... or setting up a bank with the intention of stealing all your depositors money.
Your analogy is a nonsense. If you want to make a sensible comparison with paper money then talk about bank which didn't have a fire protection system and all the deposited cash had burned after a lightning strike. |
|
|
|
|
This is easy. Make the bot send HTTP headers exactly as the browser that you use on your computer. MtGox uses some DDoS protection that is very sensitive to the content and order of the HTTP headers. What exactly needs to be done changes dynamically with the DDoS attack signatures that are going on from zombie computers in your network neighbourhood.
|
|
|
|
Hmm. The code must be extremely bad if it can reach 1MB/s doing that.
Well, yes the "satoshi client" code is really bad. On Mac it shuld be very easy to debug; just do: sudo dtruss -n bitcoin and it will show you what's it doing while grinding the disk. |
|
|
|
and Bitomat were fronts for someone acting anonymously. The operator of Bitomat.pl was never anonymous. His home address, telephone and employer were always readily available. Only after the recent failure the WHOIS information became hidden to avoid constant interruptions at his residence (or his parents' residence). This doesn't change the fact that he was an incompetent sysadmin. |
|
|
|
I'm still interested in exactly what the Bitcoin client is doing writing 1MB/s to disk with no actual file getting any larger though.
I think it is updating the database of peer IP addresses in a stupid way. I never got up to 500 peers but I've noticed that the more connections you have the more frequent the updates. |
|
|
|
Do they shred files when they reboot the machines there or could some lucky bastard running some sort of undeleter actually hit jackpot?
AWS storage is zero-initialized upon allocation. |
|
|
|
An angry investor taking the head of the one responsible
Rumor has it that it isn't the head of the operator that's in danger. Some of the lost BTC apparently belonged to the people who are not above breaking bones or cutting fingers to collect the debts. They cannot afford to let it slide. |
|
|
|
see if the coins have been shifted?
No they are still where they were. As I understand the current plan is to convert lost bitcoins into shares of a new for profit venture that will take over managing and operating bitomat.pl. They are planing on introducing transaction fees and use the dividend to pay off the owners of the lost coins. Apparently new venture is going to be some sort of a merger/takeover using some yet unspecified going concerns from Poland and U.K. All the above is hearsay, please treat accordingly. |
|
|
|
Pay the hoster to rip out the HDD asap and run some undelete programs... I don't know which infrastructure they used though, so it might or might not help.
You can learn and experiment on EC2 for free: http://aws.amazon.com/free/ . You will then understand why this isn't feasible to shut down EC2 farms to recover somebody's deleted data. |
|
|
|
Has anyone filed a police report?
Yes, people did report this to the business crime division of Polish police. With regard to his liability this will unlikely be criminal and currently it is treated as a case of safeguarding evidence for a civil case. bitomat.pl didn't charge any fees because it didn't have proper legal framework to do so. Apparently he sustained the expenses by keeping the PLN balance in overnight certificates of deposit. PLN funds weren't lost and both deposits and withdrawals are processed promptly. |
|
|
|
I, for one, am not buying an EC2 failure.
This wasn't an EC2 failure. It was an EC2 customer's failure to read the documentation and understand the tools he's using. EC2 by default deletes the volume used to boot the instance after the instance gets stopped. The MySQL database survived because it resided on the separately attached volume which would need to be explicitly deleted. I spoke with people working in Poland and apparently this was all around amateur hour, including all the futile attempts at recovery. Apparently the bitomat.pl operator even served Amazon with a legal demand using Polish legal process. Also, he didn't incorporate the business and operated it as an after-hours hobby while keeping full-time job at www.ceneo.pl. |
|
|
|
You missed the fact that Bitcoin uses little endian on the network. This is probably Bitcoin's biggest design mistake.
I wouldn't call it biggest, but probably one of the most difficult to rectify. The longer it stays this way the higher are the chances that people enshrine this mistake in the alternative clients. At present time the alternative block layout should be not too hard to implement. So long as it stays this way all the implementations will suffer problems related to those inconsistencies, e.g. ufsminer which was mining on the incorrect endianness. |
|
|
|
Shift attitudes from "works for me, lusers" to "our users are a fragile and delicate resource that must be protected at all costs"
While I agree with what you wrote above, I also think that you don't completely understand the motivation of the people who donate their time towards the project. Perhaps you could shift your thinking towards: "I invested years of my time to excavate through this shipwreck. Now it is payback time or forever hold your peace." and "the users are worth as much as the transaction fees they are willing to pay, no more & no less". Your sentences above make me think that you were more involved in some commercial product development and not an open source ego-stroking fests. To that extent you'll probably find more people willing to listen if you modify your approach to the developers here. |
|
|
|
|
Show Posts
