Bits of proof website launched http://bitsofproof.com background info, presentations and documentation coming soon. You might be interested to check the Jobs section. |
|
|
|
|
Your site does not yet mention Bitcoin. Would you mind to elaborate how you are connected?
Drop me a mail please if you are interested in custom Bitcoin enhancements or professional support.
|
|
|
|
UDP is an example of the tremendous misalignment of incentives between "core dev" and commercial use.
UDP has the potential to deliver blocks and transactions more rapidly throughout the network. The former benefits miners, and the latter benefits all bitcoin users. No doubt that it has a potential benefit. It would however have lowest priority on the wish list if ranked by commercial user. If Satoshi client was not the reference but the reference was independent tests, then such extension was permissible. Now it would compound the problem for minuscule upside. |
|
|
|
Sure, I'd love it if the Bitcoin protocol was specified entirely by comprehensive tests. It's just really hard to get there with confidence.
By the way, UDP support isn't merged, it's just a proposal. So that isn't a great example.
Yes it is hard to get the comprehensive tests, but insisting on the entire Satoshi client as reference is not sustainable. UDP is an example of the tremendous misalignment of incentives between "core dev" and commercial use. |
|
|
|
Eventually, you come to realize - wait. We already have a very precise specification of how Bitcoin behaves. That specification has as much detail as you'd ever need, because it's written in C++ and executed directly by the CPU.
the Satoshi implementation is much much more than needed to describe the behavior crucial for consensus, worse it is a Spaghetti and gets extended with any feature the core dev team thinks fancy to ad. Just think of the latest UDP initiative of jgarzik. Satoshi client is a moving target to other implementations and even to itself as it evolves. Although it is standard by its number of installations, this does not seem to be able to hold, as requirements diverge with more advanced use. All major Bitcoin services use modifications of Satoshi, BitcoinJ (soon bitsofproof) or proprietary implementations of the protocol. I plead for a standard defined by text, code examples and extensive set of tests. That standard should be derived and often purposefully extracted from Satoshi code but even future versions of Satoshi code should be measured on that testbed. Wait - this is actually we move toward. The growing list of test cases passed by Satoshi, BitcoinJ and bitsofproof are the building blocks of that new standard! And YES, the BF should use a lion share of its resources to define the standard set as its first goal at inception. |
|
|
|
Cool though Erlang is, I'm not sure it has many benefits for something like Bitcoin. Of course you're welcome to disagree. When I look at the causes of inefficiency in the current C++ codebase, it's not clear that the language has anything to do with it. There are various things we could optimise to make propagation of data faster, although it doesn't seem to be Bitcoin's biggest problem at the moment.
I agree that it doesn't solve any efficiency issues or make anything faster (it is hard to beat C++ there). Erlang is very much aimed at reliability, so I'm more hoping for a bulletproof, crashless, seamlessly upgradable implemementation. Functional languages like Erlang or Scala are best suited to create robust multithreaded programs since their patterns avoid mutable objects and side effects. Using such language definitely helps writing thread-safe validation and service of lots of parallel requests. A Bitcoin node performance however is constrained by block storage and EC signature validation, if you use some low level implementations for those, you get best of both worlds. This is what I also did in bits of proof using LevelDB (native C++) and plan to use for EC. |
|
|
|
|
Satoshi had to implement the protocol validation, mining, wallet, payment etc. to have a proof of concept.
Now that we see the concept is working, it is natural that people want different flavors of the non-validation functions. It is not feasible that the single implementation will satisfy those often conflicting (at least in priority) needs. The Satoshi client and its maintenance model became the bottleneck for innovation the core team does not think it is fun to work on.
The solution is to isolate the protocol validation and modularize. Since the Satoshi code is badly suited for modularization and separation of validation engine, other implementations started and some are already in good shape.
The bits of proof implementation has an impressive compliance level and performance, is radically modular and comes with a list of unmatched features by the Satoshi client such as e.g. BIP32, BIP38 and colored coins. Its development is led by commercial demand while it will continue to open source the validation engine to the community.
Now you have the choice of navigating the politics of influencing the Satoshi client or simply sign a contract with bits of proof zrt. to get what you want.
|
|
|
|
Note that I incorporated bits of proof zrt. and transferred the copyright on the bits of proof implementation of the Bitcoin protocol to it. The license terms remain the same, that is Apache License, Version 2.0. bits of proof zrt. offers custom extensions and commercial support for this implementation of Bitcoin. The implementation is at beta stage, features will be further extended. See further info at: https://github.com/bitsofproof/supernode |
|
|
|
I don't know of any other proposals to use PSI protocols for crime fighting, but the general idea of taint has been around for a while. And yes this post is written and researched by me. I try and find ways extensions to Bitcoin could impact on society, in particular, to solve common objections to the concept of crypto-currency.
Thank you Mike! You addressed a very valid obstacle to adaption and present danger to our investment. We have to show the way otherwise we will be shown and possibly wont like it. Since block chain traversing algorithms are not feasible on an SPV or a server trusting client, this flagging might be service(s) that customer could consult. Mining pools might also differentiate themselves by mining "clean" blocks according to their definition of purity. |
|
|
|
I guess this is a consequence of Bitcoin development not being driven by commercial interests.
Exactly. |
|
|
|
Looks like maven would not build the right path for tests, since it can not load the log config. This could be also the explanation for not picking up the right security provider (bouncy castle). You likely have some unique environment or build of maven. Local hosted repositories or patched?
Or you are running into Windows unable to deal with paths longer than X byte or paths with space in it or similar.
General suggestion:
Install some unix based operating system before trying to build software.
i find your suggestions a bit dissatisfying from a build perspective. You are using platform independent language and a platform independent build stack and yet you are suggesting your actual build may in fact be platform dependent. I understand you have other priorities bringing up the code to a high level of quality, but you should be in the frame of mind where your code and build will be platform independent at some point. PRab swapping out versions of protoc is a perfect example of something Maven is supposed to unequivocally disambiguate. At a casual glance, everything else in the build is looks good, which is why build issue a bit confusing. I did do some research the other day, and I can see you are including protoc in your build as it has been recommended in various forums. My main issue is that the recommendation is incomplete (some posts even acknowledge this), which is why PRab and I are unable to reproduce your build without a non-trivial amount of effort. I feel I can contribute to helping you create a platform independent build or at least a clearer build path, so I will try to help you to that end. I'll need to find some more time to look into this and will contact you if I find I need any more information. You are right, ideally I would care about build process on platforms other than Linux and OS X. I do not have bandwidth. I deleted my rant above, but you managed to quote it before I recognized that it was a non-productive outbreak of my long standing hate relationship with Windows. That system did cause frustration to me every time I had to face it. Your help is appreciated. I understand your frustration (sounds familiar), but I did everything to make the build a no-brainer on any unix system. If you were figuring out build instructions for windows, that would be great to avoid similar frustration. I believe that this system will be deployed in unix like environments in virtually all cases of production. Even if production environment would be windows it could use the built artifacts without recompiling them, so the issue is really limited to developer who have to use windows for some reason. |
|
|
|
|
Looks like maven would not build the right path for tests, since it can not load the log config. This could be also the explanation for not picking up the right security provider (bouncy castle). You likely have some unique environment or build of maven. Local hosted repositories or patched?
The:
[debug] execute contextualize
lines in your maven output suggests this is some patched maven.
|
|
|
|
|
This is a service pools should provide, and I am sure they will since it is a differentiator in their otherwise commodity service.
|
|
|
|
Now it's in the early stage of development. I'm trying to implement protocol not looking into bitcoind source, ...
From this I can tell that this must be really early stage. Keep up, but be prepared for a very long trip. Unfortunately documentation available is very far from being sufficient input for an implementation, and in Bitcoin world there is no half-way compatibility. |
|
|
|
I know this discussion has been here before, but I think it is an issue that is more pressing then ever now with the new bitcoin prices. I think we should no longer deal in BTC, but in mBTC.
A notable initiative is to reserve an ISO code (like EUR, USD) for Bitcoin. BTC is apparently taken, but introducing XBT as a unit equal to 100 Satoshis seem to find support, especially since it allows representation of Bitcoin in legacy financial systems (accounting, book keeping etc that can only deal with 1/100 precision of a currency) See vote and reasoning and discussion in: https://bitcointalk.org/index.php?topic=149150.msg1630511https://bitcointalk.org/index.php?topic=149150.msg1630511#msg1630511I think mBTC and uBTC are rather engineer type solutions, alien to mainstream user whereas the XBT would foster adoption and open Bitcoin to legacy systems. |
|
|
|
|
Your remarkable contribution to the foundation of our future economy should let you feel proud and safe to be remembered by all of us.
Thank you Hal.
|
|
|
|
i'm interested in implementing this on aws and building a pristine community image and good documentation or even automated security automation on setup, and also getting running in a worker role on azure...anyone interested in collaboration?
I thought this server will be basis for unique implementations, not a commodity client for end user. Tell me a bit more about the use case you address please. |
|
|
|
What versions of Java, Maven, and protoc are required?
I just tried building ("mvn package" - Windows 7 64bit) from git and it failed. I can't see the exact message because the mvn window closes automatically. It appears to make the \api\target directory, but there are just a couple of subdirectories (no actual files). In addition, it modifies \api\src\main\java\com\bitsofproof\supernode\api\BCSAPIMessage.java by quite a bit.
Any suggestions?
Recent versions of java and protobuf, that is Java 6 or 7, protobuf 2.x are needed. The protobuf compiler generates BCSAPIMessage.java. I am sure you find better sources with google on how to install java, protobuf or use maven on windows than my answers, since I avoid using windows whenever I can. @grau I have some experience as a build manager and going to say "bad grau, bad", repeat after me "i must not include implicit external dependencies in maven builds". In maven you must be explicit in your pom files in such situations. That is the price you pay when including such dependencies, whether you use maven or something else.
You see the errors because the protobuf compiler is not installed or not in path. Let me know if protobuf compiler dependency and execution can be formulated more elegantly and I will amend. The build works as documented on https://github.com/bitsofproof/supernode/wiki/Build. Basically a one liner. I am confident that this is the case, since the build is executed on a fresh git clone with every commit using random machines supported by the travis-ci project. Also all unit test are running through there. See recent (and historic) build and test outputs here: https://travis-ci.org/bitsofproof/supernode. The travis configuration is also trivial, just asking for default protobuf installation, see here: https://github.com/bitsofproof/supernode/blob/master/.travis.yml |
|
|
|
|
Show Posts
