|
I take it seriously and I think there are some very valid points here.
It all adds up - much more then the official story.
Thanks, @benjamindees
|
|
|
|
The only way to have such a piece of software, is by forking the existing bitcoind and stripping it from all the crap, without even looking at the corrupt bitcoin elite, nor letting them to waste your time. If you want to have such a piece of software, then trust me: sooner you will make it yourself. I'd help you, but I prefer to raise my own child instead  , and bits of proof, and Amir Taaki have already done that. Thanks for being so well informed, but I have also done this, so please mind not letting my fine project behind It has everything a bitcoin node needs and performs just great; I can challenge any of the software you've listed. And if anyone needs a mining API, just let me know - shouldn't be hard to add. |
|
|
|
Guys, you are talking to a wall here. I dare to state (and I am dying to be proven wrong) that making a wallet-less reference node, with minimal external dependencies will never happen - at least not made by this team. It just isn't on their employers' agenda, despite of all the rumors and gossips that you might have heard. The only way to have such a piece of software, is by forking the existing bitcoind and stripping it from all the crap, without even looking at the corrupt bitcoin elite, nor letting them to waste your time. If you want to have such a piece of software, then trust me: sooner you will make it yourself. I'd help you, but I prefer to raise my own child instead |
|
|
|
Sorry, mr polite and competent, but I did not catch that point... How exactly is the guy setting his "subVer field appropriately" going to help anyone with anything here? And what kid of DoS attacker connects to a node, just to do nothing, except listening for invs? The node staying idle looks more like it's trying to not DoS attack itself, after being connected to so many peers |
|
|
|
|
Yeah, I've seen them as well.
They do nothing except listening for invs and they never give up - when you disconnect them, they immediately try to reconnect,
The only explanation I have is that they seek to find IP addresses from which new transactions originate.
|
|
|
|
This month's update: changes up to version 0.8.0 WalletIt does not show characters on screen while a user is entering the seed-password. The solution is unfortunately platform dependent and requires MinGW in case of Windows. If you cannot compile the wallet anymore, you can switch this feature off - just delete "wallet/hidepass_*.go" ClientFrom the things that only devels care about, the structure of the code in the "client/" folder has been hugely reworked. It isn't all-in-one anymore, but contains sub-packages. As for the useful features, starting from version 0.7.6 there is a new tab on WebUI: MakeTx. MakeTx allows the user to select (in a GUI-like matter) the specific outputs that he wants to spend and produces the exact command line that shall be executed. It creates the "balance/" folder for the wallet, along with "pay_cmd.txt" file containing the command to be executed at the wallet's PC in order to sign the requested tx. An example screenshot of how the new feature looks in your browser: http://imgur.com/JyIRZJlFetchBalanceRecently I have also created quite a useful tool that can fetch a balance of your wallet from the popular block explorers. I tried to use only one of them, but could not find a fully satisfying API and ended up needing both; blockchain.info & blockexplorer.comNot every transaction can be recovered this way, but most of them should work. If any transaction cannot be fetched and decoded properly, it will inform you. I will try to add a proxy support for it later, so you could easily fetch your wallet's balance using Tor. Using this tool you do not need an online node anymore; only the small wallet app, and you have a fully functional and secure bitcoin brain/deterministic/cold wallet solution. It is a single file tools/fetchbal.go - compile it to an executable, or use "go run" on the source. Not having the client, you can just use blockchain.info/pushtx to broadcast the signed transactions coming from the wallet.
If anyone would like to try any of the pieces, but does not want to play with building the s/w himself, I can provide binaries for Windows or Linux. Also, if you built and tried it on Mac, please let me know whether it works - I am curious to know, but have no apples here. |
|
|
|
|
Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.
Instead of adding more mess to the existing one...
|
|
|
|
I am not saying it is a rocket science - I am saying that OpenSSL is a one big mess and nobody knows what it really does these days. Come on, you must know life; how much you can actually rely on any documentation? OpenSSL is surely no exception. Mind that you have just quoted "Bugs" section of the doc, to support your statement that "No attempt is made to download CRLs from the CRL distribution points extension". If my fate is about to be judged on whether you set a flag or not while calling the lib, and whether this flag actually does what the man page says it should - then I would rather stay away from such a secured payment solution. And I will be advising people to do the same, if you don't mind. |
|
|
|
Thanks Mike. I hope you don't take my comment personally and you understand that you work for Google while I work for the people. We play for different teams, but it doesn't mean we cannot play fair. So, let's get into X509_verify_certA complete description of the process is contained in the verify(1) manual page. And this is the verify(1) manual page: http://www.manpagez.com/man/1/verify/Do you still claim that there is no way that the bitcoin client can leave my IP a CA server, when you just use this function? I am not saying that it does - I am just saying that it isn't totally clear what this function actually does. And I'm betting that it's also not totally clear for you. |
|
|
|
From what I see ATM nobody seems to really know what it does.
From what I see here, there are only a few that don't know what it does, you being one of them. As for a guy who has just refereed me to a source code of ECDSA verify function, after I had asked him for the function name that verifies the SSL certificate, you seem to be pretty funny advertising your expertise in the matter |
|
|
|
And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.
What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate? Nothing. The CA has no idea what you need that certificate for. What it does - is not so important. What is important is that you have no clue what it does - and that's dangerous. For privacy, I mean. I cannot believe that I even need to explain it here From what I see ATM nobody seems to really know what it does. It needs to be established on IRC first, but we can be sure that results will be positive... |
|
|
|
Are you fucking kidding me? I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever. Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client. I was being facetious. The signature verification for an X.509 certificate is determined by the certificate itself. It's nothing more than a basic crypto function and it doesn't need to connect to any 3rd party in order to verify if a signature is produced by the private key that a specific certificate represents. see http://en.wikipedia.org/wiki/X.509 for details. Right. You know everything, except the basic function's name.. Well, thank you for sharing your valuable knowledge with me |
|
|
|
and how do you know what this function does inside?
Because we took the time to figure that out? You should try it some time. But you did not tell me which function, nor any other specifics that I asked about. Sigh. https://github.com/sipa/secp256k1/blob/master/src/secp256k1.c line 23, secp256k1_ecdsa_verify: Are you fucking kidding me? I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever. Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client. Thank you! And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server. |
|
|
|
and how do you know what this function does inside?
Because we took the time to figure that out? You should try it some time. But you did not tell me which function, nor any other specifics that I asked about. E.g.: how do you know which root certificates are installed in the system? Let's say Windows... So it's totally cool that you play a smart ass pretending that you know how it works, but before you can explain me the details, I cannot really assess if you are not just playing stupid |
|
|
|
The bitcoin client does not connect to the CA.
Stop repeating clueless people.
So it does not support a chained certificates? The bitcoin client does not need to connect to the CA. All it takes is an SSL lib connecting there, likely even on the OS level, since the root certs are installed right there. You guys obviously don't quite understand how this protocol works inside, and it's obvious since it is a one big mess and nobody does, but don't you think that merging the bitcoin client with a lib that nobody really understands might be a bit dangerous, to say the least? |
|
|
|
Read my dissemination of the relevant parts above where I quote BIP 70, or look it all through yourself.
I've read your posts several times, and I still can't figure out why you think that anything is being sent to the CA. Digital signing involves hashing the message, and OCSP involves sending the hash of the certificate issuer's DN and pubkey, but it doesn't follow that OCSP is going to throw every hash it sees into the OCSPrequest. Where do you get the root certificates from? Or let me ask otherwise, make it a simpler question: which openssl function do you use to verify a certificate and the message, and how do you know what this function does inside? |
|
|
|
It's not about OCSP. It's about the fact that you are displaying wilful ignorance.
Well, at least I'm not lying. Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA. Links? I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA. Why would he think so? Maybe because he followed your advise and educated himself... EDIT: Sorry - one of the links points to a post of a non-supporter. |
|
|
|
Go educate yourself.
I fink you meant the other verb Educating myself is exactly what I have been trying to do here, before you jumped in here, to insult me on behalf of the bitcoin elite. Even better, according to Gavin on IRC just now, OCSP is not currently scheduled for implementation. So, just to be absolutely clear to anyone reading this thread, at this time, there will be absolutely zero communication with any CA done by the bitcoind client. Oh, thank you for finally making that clear, though... At some point, some form of OCSP probably will be implemented, because it is a very useful security feature. Right. So we are going back to the entry point When that time comes, everything I said above about OCSP not leaking the transaction details will still apply, and several billion people will have the opportunity to verify on their own that the code isn't doing anything sneaky. It is not me who said in this topic that the hash is sent to CA - I only repeated it, since you were not here to state it wrong. Go educate yourself. |
|
|
|
It's not about OCSP. It's about the fact that you are displaying wilful ignorance.
Well, at least I'm not lying. Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA. |
|
|
|
Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.
How do you expect people to take you seriously with statements like these? I believe most people don't know what OCSP stands for - so why would they not take me seriously asking about it? |
|
|
|
|
Show Posts
