For creating the signatures, I guess it can be a third party tool.. don't need to be part of Bitcoin-Core
we provide the verification-feature in Bitcoin-Qt and in the new cli only verify tool
Yes, but using a web wallet because bitcoin core install required an extra, foreign, step would not be. :)
I mean the bitcoin core update and the signatures for it should be a single file. The download/verifying tool can both be included in it, and available seperately (for the first time user).
By two files I mean "bitcoin" and "the witness" if there are two files someone watching the network can tell which users check and which don't, and someone checking on an offline computer has two files to download and copy across, so they won't.
it's important that its also easy to use the tool without it making network connections, so that it can be used on offline hosts, and also not "phone home" every time bitcoin is installed, which would make it easy to track who is using it. (both who is using bitcoin and who is using it with/without verifying-- we want a network attacker to not be able to tell users who verify from users who don'
(for core, except your using -server/d with bitcoin-cli
They should wake up indeed. But I lost a bit of confidence in "people" to be able to do so since I started with Bitcoin. On the other hand, a police officer once told me: "These people are allowed to vote".
that's a much bigger problem than just bitcoin
stupid fuckers, sometimes I'm about to believe the story that bitcoin is just making it easy for people to be scammed out of their money
And perhaps a topic message in #bitcoin that states to be cautious when people try to "help" you through pm's
of course, then people may get users to run bitcoin-qt with -server...
<gmaxwell> Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey. :(
jonasschnelli we need a constant 'Project CN', so that somebody doesn't release 'bitcotn-core' and project will ignore all the signing policies. - The verify app should also spit out warnings: "bitcotn-core" is very similar to "bitcoin-core".
then your clients should hire people of their own to work as Bitcoin Core developers; off-topic anyway, #bitcoin
signing key. During this "unofficial" meeting in #bitcoin, there were a minimum of 123 lines of comment from Wladimir van der Laan, all of which are not included in the "official" meeting log. Given the recent advisory on the website, regarding "state actors", there is speculation amoung my clients that conflict of interest disclosure and transparency may be insufficient amoung the Bitcoin Core developers.
catsAREnotSECURE, well, I'm sorry for your mistake, please move it back to #bitcoin, or elsewhere.
This question was intended for midnightmagic. The conversation began in #bitcoin, but for transparency reasons, I sought to move it to this channel.
Is there public disclosure of bitcoin holdings / wallets associated with specific developers?
sipa, gmaxwell: about the binary ecdsa signing. We could create a standard ecdsa sig along with the GPG assets sig. Something like bitcoin-osx-0.13-build.assert.ecsig, where we just place a 64byte compact sig. ecdsa(sha256(sha256(<filecontent>)), P)
Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey. :(
Kanzure, achow101. Regarding your public comments on the bitcoin.org notice.
So part of why I was deflecting on the endless rathole of the bitcoin.org stuff is because I had more to say that that I didn't fit in the scope of the meeting, and we had other things to accomplish that unfortunately we didn't have time for. :(
And store ECDSA pubkeys of each gitian builder in our bitcoin/bitcoin git
For the binary verification problem, we should have a verification process in Bitcoin-Qt/bitcoin-cli (or maybe an additional tool) that can verify a downloaded binary by downloading the gitian.sigs
In the bitcoin developer reference, when decoding a partial merkle tree it says: Fail if there are unused flag bits—except for the minimum number of bits necessary to pad up to the next full byte.
By the way, while there are still lots of well-informed people reading this. Does anyone else have another list of realistic spending values for Bitcoin Nodes? I'd love to have a second scenario to test my coin selection simulation on.
i asked before too, got answers about gavin making changes for CIA, "only real bitcoin address starts with a 1", etc
jtimon: to answer your earlier question best I can: I think they perceive 0.5.3 as the last release before the Bitcoin Foundation "got involved" (I know the BCF was never involved, but they're conspiracy nuts)
e.g. if you update your bitcoin node and then days/weeks later it starts doing thing with segwit commitments that breaks your miners or pooling software, that is preferable. You would prefer the break to happen at upgrade time.