1 2015-05-16 05:20:47 <ginseng> hello testnet uses a different blockchain right? if so is there a torrent file for it somewhere
 2 2015-05-16 05:26:13 <gmaxwell> ginseng: there is no torrent for it; really torrents are not useful any more (for most people most of the time the process of torrenting and syncing is slower than just syncing)
 3 2015-05-16 05:28:42 <ginseng> i see. do you any idea of the approx size of testnet blockchain atm? ty
 4 2015-05-16 05:31:01 <gmaxwell> about 2.5GB.
 5 2015-05-16 07:47:31 <wumpus> looks like 0.10.2rc1 tested succesfully in #6078, going to tag it as final unless anyone protests
 6 2015-05-16 08:38:17 <wumpus> * [new tag]         v0.10.2 -> v0.10.2
 7 2015-05-16 09:43:05 <wtm_> Can anyone tell me how miners receive user's transaction? What file can I found those code?
 8 2015-05-16 09:44:20 <wumpus> transactions are gossiped through the network, nodes will relay transactions that are valid and pass their standard rules to other nodes they are connected to
 9 2015-05-16 09:45:36 <wumpus> code is in main.cpp mainly, see e.g. ProcessMessage for "tx"
10 2015-05-16 09:47:49 <wtm_> Thank. But how do message send to them? Would a normal client (not miner) receive message?
11 2015-05-16 09:52:23 <wtm_> Does clients send the message to multi miners? How clients decide which miner to send?
12 2015-05-16 09:56:56 <gmaxwell> wtm_: they are flooded in the network, all nodes recieve them and process them.
13 2015-05-16 09:57:24 <gmaxwell> Miners are not special in their handling of transactions; they just also produce blocks, but they learn about them the same as all other nodes.
14 2015-05-16 09:57:31 <gmaxwell> You'll likely get better help in #bitcoin.
15 2015-05-16 09:58:28 <mjerr> Hey gmaxwell, you'll probably know, didnt got a response so far ^^ is there any active discussion about SIGHASH_NOINPUT?
16 2015-05-16 09:59:15 <gmaxwell> There was some traffic on the list, most people who would be are busy with other things at the moment.
17 2015-05-16 10:00:14 <wtm_> thk, btw how they know each others?
18 2015-05-16 10:01:37 <mjerr> Are I see, would starting a BIP help to push the discussion a little bit? Many core devs are against the block size solution, especially since they want other solutions to emerge first, but I can't see anything like Lightning happening, before implementing anything like new SIGHASHES
19 2015-05-16 10:06:19 <mjerr> I started working on a implementation, but an absolute no-trust-solution is not possible IMO with the current setup.. I guess in the meantime such a low-trust solution can work pretty well, but NOINPUT would solve so many problems and make everything much more efficient aswell
20 2015-05-16 10:12:35 <gmaxwell> I suspect you do not yet adequately understand the subject if you are saying "make everything much more efficient aswell", as simply omitting inputs creates a massive replay vulnerability-- its not something you'd want to do for ordinary transactions.
21 2015-05-16 10:14:05 <gmaxwell> Probably the best thing to move things forward is building up the use cases, flags improvements will probably merge in with an improved checksig operator proposal sometime in the next couple months.
22 2015-05-16 10:15:27 <mjerr> I know, it's specifically for Lightning, I meant not everything as every transaction there is, but everything revolving around these payment channels
23 2015-05-16 10:15:52 <mjerr> Currently you would need to resign all open HLTCs when adding a new one
24 2015-05-16 10:16:20 <mjerr> As all previous ones would have an now invalid input TX+
25 2015-05-16 10:16:22 <mjerr> TX#
26 2015-05-16 10:18:45 <mjerr> As a large receiver of payments, you could easily get multiple thousands of micro transactions in a short time.. While there is an incentive to close those asap aswell, it does scale very bad traffic-wise when these stay open
27 2015-05-16 10:22:02 <mjerr> And this is just a minor improvement compared to the trust issue that it will fix, as it's possible to mitigate the malleability completely..
28 2015-05-16 10:22:48 <mjerr> But it's nice to hear that it might merge in 6-12 months..
29 2015-05-16 10:26:14 <mjerr> I will continue implementing it then, as you said, as soon as there is a system that is usable, people might consider the replay vulnerability an adequate risk compared to the benefits
30 2015-05-16 15:04:39 <dhill_> +/win 10
31 2015-05-16 15:04:42 <dhill_> fail
32 2015-05-16 15:06:31 <arubi_> 8 char password? are you my bank?
33 2015-05-16 15:07:25 <dhill> no, banks don't allow + or /
34 2015-05-16 15:07:29 <dhill> :)
35 2015-05-16 15:07:35 <arubi_> true :)
36 2015-05-16 17:35:48 <syawal> hy
37 2015-05-16 17:35:54 <syawal> ds
38 2015-05-16 18:03:37 <michagogo> wumpus: is there a mac sig yet?
39 2015-05-16 18:03:47 <michagogo> Or does that wait for 3 unsigned builders
40 2015-05-16 18:03:48 <michagogo> ?
41 2015-05-16 18:31:37 <michagogo> What's 2015_05_schedule_test_fix?
42 2015-05-16 18:32:28 <michagogo> Oh, I see, a branch for https://github.com/bitcoin/bitcoin/pull/6145
43 2015-05-16 18:32:38 <michagogo> Aren't PR branches usually on personal forks?
44 2015-05-16 18:35:11 <maaku> michagogo: they should be
45 2015-05-16 18:35:16 <maaku> but github doesn't require that
46 2015-05-16 20:41:46 <fanquake> ;;blocks
47 2015-05-16 20:41:47 <gribble> 356724