1 2016-02-23 01:36:54 <kanzure> https://github.com/droark/bitcoin-dev-notes/blob/master/Bitcoin_Core_source_breakdown.md
 2 2016-02-23 01:49:24 <kanzure> btcdrak: are the sf seminars streamed anywhere by any chance?
 3 2016-02-23 04:02:45 <warren> kanzure: not streamed but they typically post the video a few days later
 4 2016-02-23 06:40:40 <btcdrak> kanzure: yes here https://www.youtube.com/channel/UCREs0ConyCR2sEFf-DrLRMw/videos
 5 2016-02-23 09:18:42 <execute> this is probably a stupid question, but what is wrong with BIP20's send parameter? why was that removed on BIP21?
 6 2016-02-23 09:44:58 <wumpus> BIP20 was considered overly complex and feature-burdened for an initial URI proposal
 7 2016-02-23 09:46:36 <wumpus> things like that could be proposed as an extension, though bitcoin URI usage has mostly been subsumed by the payment protocol
 8 2016-02-23 09:52:08 <execute> i see. so there isn't any security flaw or anything of that sort? because to me this seems like a great way to support pull transactions
 9 2016-02-23 09:53:42 <wumpus> well apart from the obvious drawbacks of sending someone a private key; someone intercepting the URI can claim the payment at any time (sensitive to passive MITM instead of active)
10 2016-02-23 09:56:27 <wumpus> also there is some complexity with regard to handling of this private key in the wallet, it needs to have a special status, it would be a disaster if eg. change was accidentally sent to it, or it was dealt out as a receiving address
11 2016-02-23 09:56:43 <wumpus> (on both the sender and receiver side)
12 2016-02-23 10:00:20 <Lauda> ping wumpus
13 2016-02-23 10:04:52 <execute> yes, but theoretically, a printout of a QR code that directs to a URI can be given as gift, to be loaded with a wallet that's specifically designed to empty out the wallet
14 2016-02-23 10:05:20 <execute> empty out the address in the URI
15 2016-02-23 11:18:30 <btcdrak> https://bitcoincore.org/en/2016/02/23/release-0.12.0/
16 2016-02-23 11:21:42 <jonasschnelli> \o/
17 2016-02-23 11:21:46 <Lauda> +1
18 2016-02-23 12:05:53 <TZander> congrats, guys
19 2016-02-23 12:16:10 <JWU42> did something change in the build instructions from RC5 to final ?
20 2016-02-23 12:16:58 <JWU42> two boxes that are running rc5 - trying to upgrade them - make yields a Nothing to be done for 'all-am'
21 2016-02-23 12:17:31 <JWU42> I am an idiot
22 2016-02-23 12:17:33 <JWU42> too early
23 2016-02-23 12:17:35 <JWU42> :/
24 2016-02-23 12:26:51 <wumpus> no, nothing changed from rc5 to final at all (as should be the case)
25 2016-02-23 12:28:57 <wumpus> I guess all make should do is rebuild clientversion etc as it includes the commit hash
26 2016-02-23 13:04:20 <michagogo> JWU42: did you `git checkout v0.12.0`?
27 2016-02-23 13:08:48 <JWU42> michagogo: failed to realize that both the RC5 and FINAL were untar'ing to the same 0.12.0 dir
28 2016-02-23 13:09:19 <JWU42> was thinking the rc5 was ina  dir like 0.12.0rc5/
29 2016-02-23 13:09:30 <JWU42> and I knew better - just no coffee yet ;)
30 2016-02-23 13:10:05 <JWU42> keeping other boxes on rc5 and then upgrade whenw e get to 0.12.1
31 2016-02-23 13:28:52 <btcdrak> .
32 2016-02-23 13:29:10 <slackircbridge> <btcdrak> .
33 2016-02-23 13:32:51 <btcdrak> .
34 2016-02-23 13:41:30 <aschildbach> Hi there, I've got a question about the Version, VersionAck handshake at the beginning of a P2P connection. Are the two directions of the handshake supposed to run in parallel, or is it ok for the node that was accepting the connection to defer his Version message until he sent his VersionAck (in response to the Version of the connecting node)?
35 2016-02-23 13:52:03 <mesmer> aschildbach: current logic is the later, since it'll disconnect first without replying if the node is too old.
36 2016-02-23 13:54:34 <aschildbach> mesmer: thanks
37 2016-02-23 13:54:58 <aschildbach> mesmer: With "replying" I guess you mean the VersionAck message?
38 2016-02-23 13:55:08 <mesmer> it'll send REJECT message
39 2016-02-23 13:55:14 <mesmer> and will not reply to verack
40 2016-02-23 13:55:48 <mesmer> see https://github.com/bitcoin/bitcoin/blob/8b70a64d62c6e64288762d062414cc979f880c54/src/main.cpp#L4402
41 2016-02-23 13:57:53 <aschildbach> The code shows it replies to the Version message, rather than the VersionAck.
42 2016-02-23 13:58:24 <aschildbach> So it receives Version, and replies with either VersionAck or Reject.
43 2016-02-23 14:00:11 <aschildbach> mesmer: But the interesting question is: When will it send its own Version message?
44 2016-02-23 14:04:27 <mesmer> the way I understand it is it doesn't send version message unless you are creating an outbound connection.
45 2016-02-23 14:04:51 <mesmer> so unless you are connecting to new nodes, it won't
46 2016-02-23 14:45:08 <kanzure> slackircbridge: @kanzure test
47 2016-02-23 14:45:16 <kanzure> notifications work
48 2016-02-23 16:55:28 <Lauda> Does anyone know what is going on here: http://i.imgur.com/6rEAUhp.png ?
49 2016-02-23 16:55:53 <Lauda> Trying to create and verify the signed binaries.
50 2016-02-23 18:45:47 <bittrex-richie> can anyone explain the wallet prune mode in bitcoin .12?
51 2016-02-23 18:48:35 <Lauda> ^You are able to run a pruned node with X amount of last blocks. The minimum amount is 500 or 550 blocks IIRC.
52 2016-02-23 18:49:16 <Lauda> Actually 550 MiB for raw block & undo data.
53 2016-02-23 18:49:31 <Lauda> Disk usage drops from 60 GB to ~2GB.
54 2016-02-23 18:49:43 <bittrex-richie> so it prunes the blockchain ... not the wallet
55 2016-02-23 18:50:03 <bittrex-richie> it makes references of forgeting about spent outputs
56 2016-02-23 18:50:12 <bittrex-richie> but its not very clear how
57 2016-02-23 18:51:28 <Lauda> https://bitcoin.org/en/release/v0.11.0
58 2016-02-23 18:51:40 <Lauda> There a longer explanation here that might help.
59 2016-02-23 18:52:07 <bittrex-richie> ok yeah.. that helps alot.. ty
60 2016-02-23 19:12:02 <Lauda> <Lauda> Does anyone know what is going on here: http://i.imgur.com/6rEAUhp.png ? Trying to create and verify the signed binaries.
61 2016-02-23 19:12:20 <Lauda> Small bump.
62 2016-02-23 19:19:07 <arubi> Lauda, a sanity check of $SIGNER and ${VERSION} would be useful.
63 2016-02-23 19:20:23 <arubi> since it seems we're having a "look at the bottom of my stack and tell me what's wrong!" day today
64 2016-02-23 19:27:02 <Lauda> there was a problem with signer, thank you arubi.
65 2016-02-23 19:28:18 <arubi> welcome Lauda
66 2016-02-23 19:53:37 <raedah> "the wallet in Bitcoin Core 0.12 does not yet have support for creating transactions that would be replaceable", is there a git issue for this feature?