1 2015-08-13 04:26:05 <xtor> How do I into multithreading in C# apps, is it mostly just adding Async to the methods I am already using and manage the flow of i/o from them?
 2 2015-08-13 04:47:51 <Luke-Jr> xtor: this is not ##windows
 3 2015-08-13 07:00:52 <warren> Is bitcoin-dev list dead, or nobody posted for 11 hours? =)
 4 2015-08-13 07:01:05 <dcousens> Ha, I think its just super quiet today.
 5 2015-08-13 07:01:20 <warren> Maybe everyone is happy now.
 6 2015-08-13 07:01:24 <warren> please let that be it
 7 2015-08-13 07:03:32 <drazisil> Someone mentioned C# and drove the devs away
 8 2015-08-13 07:11:16 <ftlio> something something cargo plane /mailinglist
 9 2015-08-13 09:38:08 <mn3monic> Hello everyone, I am coming back with my questions! I have noticed (tx e411dbebd2f7d64dafeef9b14b5c59ec60c36779d43f850e5e347abee1e1a455) that if the last byte of the stack is an empty byte, it get popped out while parsing the script. could you confirm this, and maybe link the part of codebase which do that ? Thank you very much
10 2015-08-13 10:11:10 <mn3monic> ok I have found the answer, the last 0 bytes in the transaction are a "padding", cause the script is expected as 4 more bytes longer.
11 2015-08-13 11:10:48 <joedoe-> you sure? seems borked https://blockchain.info/tx/e411dbebd2f7d64dafeef9b14b5c59ec60c36779d43f850e5e347abee1e1a455?show_adv=true
12 2015-08-13 11:50:06 <jonasschnelli> BlueMatt: how would your approach of a process separation of the wallet/GUI look like?
13 2015-08-13 11:50:28 <BlueMatt> jonasschnelli: hmm?
14 2015-08-13 11:51:01 <jonasschnelli> referring to: https://github.com/bitcoin/bitcoin/issues/6552#issuecomment-130623341
15 2015-08-13 11:53:19 <BlueMatt> I dont have a specific approach in mind, but my impression is that most people would like to split out the wallet from the core p2p and consensus process
16 2015-08-13 11:53:48 <BlueMatt> whether the gui should be split off the wallet, I dunno, but generally adding more interface code to the repo sounds like the wrong direction
17 2015-08-13 11:54:18 <jonasschnelli> BlueMatt: Yeah. Right. I just try to collect ideas because i'd like to implement towards process separation... but don't see a "perfect" solution now.
18 2015-08-13 11:54:32 <BlueMatt> nothing is perfect, there is only incremental improvement :)
19 2015-08-13 11:54:40 <jonasschnelli> Agreed.
20 2015-08-13 11:55:48 <jonasschnelli> If i got that right, most devs think the separation should end up by having the spitted off wallet that communicates with the core over P2P (SPV with a trusted node).
21 2015-08-13 11:56:04 <BlueMatt> yea, that seems like a popular option these days
22 2015-08-13 11:56:07 <jonasschnelli> Not sure if this is a good idea. Adding another protocol / API is also bad.
23 2015-08-13 11:56:25 <BlueMatt> used to be people preferred another protocol
24 2015-08-13 11:57:03 <BlueMatt> could also do spv-over-rest-api
25 2015-08-13 11:59:06 <jonasschnelli> BlueMatt: hmm... spv over rest would also require auth (+enc) and probably a reverse proxy (apache) to be save.
26 2015-08-13 11:59:22 <BlueMatt> rest is no different from p2p here
27 2015-08-13 11:59:44 <jonasschnelli> Could have (and i think there are) some DDOS attack vectors.
28 2015-08-13 11:59:56 <BlueMatt> hmm?
29 2015-08-13 12:01:03 <BlueMatt> no, I meant who cares about ddos vectors against rest for this?
30 2015-08-13 12:01:14 <BlueMatt> you're connecting to localhost
31 2015-08-13 12:01:40 <jonasschnelli> localhost is no problem. But i'm pretty sure people like to run a SPV smartphone client together with a trusted full node.
32 2015-08-13 12:02:07 <BlueMatt> well I dont think the wallet-split-out will run on android in the first version :)
33 2015-08-13 12:02:12 <BlueMatt> incremental improvements :)
34 2015-08-13 12:02:25 <jonasschnelli> Agreed. :)
35 2015-08-13 12:40:42 <pbase> why are online wallets proliferating when it is clear that- Web wallets will probably steal your money.. ?
36 2015-08-13 12:53:10 <jonasschnelli> pbase: define web wallets? Is Copay a webwallet? Most web wallets nowadays don't hold your keys... so the can't steal your money.
37 2015-08-13 12:53:19 <jonasschnelli> but probably #bitcoin
38 2015-08-13 13:22:10 <pbase> jonasschnelli: yes #bitcoin
39 2015-08-13 16:06:29 <morcos> jtimon: i don't mean to rub salt in any wounds or anything, but its getting a bit annoying that there is not a good place for me to store policy variables/attributes, now that I potentially need them in multiple files (for 6470)
40 2015-08-13 16:07:39 <morcos> i realize that i should help by reviewing policy encapsulation PR's, but i can't completely context switch out of this right now.   i think if i make these things all global vars in main, it should be relatively easy to just have a few more than we we move to policy when we finally make that happen?
41 2015-08-13 16:08:02 <morcos> does that sound reasonable?
42 2015-08-13 16:09:42 <morcos> s/than we we/ that we have to/
43 2015-08-13 16:11:00 <jgarzik> working, useful code > cosmetic changes
44 2015-08-13 16:11:14 <jgarzik> therefore, don't let policy move stuff be a barrier
45 2015-08-13 16:14:37 <Luke-Jr> policy move stuff is not cosmetic
46 2015-08-13 16:14:49 <Luke-Jr> and policy flexibility is more important than optimisation
47 2015-08-13 16:18:23 <morcos> ok well i THINK i'd be in favor of once we are all concept agreed on 6470 (and descendant state tracking and limiting) then it might make sense to before merging it try to refactor/clean up.  its a lot of added code, that we should think about what the right organization is.
48 2015-08-13 16:27:38 <toto_> hi
49 2015-08-13 16:30:25 <mjerr> btcdrak said on reddit that he thinks OP_CSV 'fully activated' within 6 months. Isn't this very optimistic? How is the voting for OP_CLTV working, is there a voting system in place at all?
50 2015-08-13 16:31:42 <btcdrak> mjerr if we had a feature-pack soft fork that included CLTV, CSV, BIP68 and median-past-timelock then we could get a lockin in 6 months. BIP66 took 4.5 months.
51 2015-08-13 16:33:22 <btcdrak> Certainly there is a lot of anticipation by the community for CLTV and from what I gather there is plenty enthusiasm for relative-CLTV which CSV+BIP68 achieves, so I think miner would be quite happy to permit the upgrade.
52 2015-08-13 16:33:41 <mjerr> oh you are here, haven't even checked that, great stuff
53 2015-08-13 16:34:56 <mjerr> yes, I don't think it is controversial at all either
54 2015-08-13 16:35:10 <mjerr> do you know how the process for cltv is currently?
55 2015-08-13 16:35:27 <mjerr> it got merged, is there any plan on how it will actually get activated?
56 2015-08-13 16:35:54 <mjerr> I feel the process is very slow, and I also read somewhere, that the voting process will only allow one feature at a time
57 2015-08-13 16:45:06 <mjerr> btcdrak, do you know anything about the current deployment status of cltv?
58 2015-08-13 16:47:11 <btcdrak> mjerr: cltv code is merged, just waiting for the launch codes which would be a soft fork... however several people are suggesting we delay CLTV in order to get CSV etc ready for a single softfork.
59 2015-08-13 16:47:31 <mjerr> ah, didnt knew that
60 2015-08-13 16:48:20 <mjerr> is the 'launch code' hardcoded already?
61 2015-08-13 16:49:00 <btcdrak> mjerr: there is a PR for it yes, https://github.com/bitcoin/bitcoin/pull/6351
62 2015-08-13 16:50:08 <mjerr> I am working on a proposal on lightning network that only depends on CLTV just now, but if cltv comes together with csv, that is nonsense of course ^^
63 2015-08-13 16:51:01 <mjerr> ah, interesting
64 2015-08-13 16:52:45 <btcdrak> mjerr: nice. in my opinion it would be a wasted opportunity to only include cltv in the softfork, especially considering how useful and widely anticipated both a/cltv and r/cltv are.
65 2015-08-13 16:53:40 <mjerr> yes, and I have yet to hear any voices against either cltv/csv. If theres no one opposing either of them, voting seperately doesn't make too much sense
66 2015-08-13 16:54:46 <mjerr> on the other hand, if we discuss code changes and testing environments for further months to come, it might be handy to have cltv sooner
67 2015-08-13 16:58:46 <Aquentin> what's the rush?
68 2015-08-13 16:59:51 <Aquentin> I don't think anyone would want to see another mess as with BIP66, I'd rather see this things go through a proper process
69 2015-08-13 17:00:00 <Aquentin> these*
70 2015-08-13 17:01:40 <btcdrak> no one is suggesting to bypass normal peer review.
71 2015-08-13 17:02:22 <Aquentin> your tone seems rushed though
72 2015-08-13 17:03:25 <Aquentin> there is this whole background debate, but lightning is a pretty complex thing and it deals with money, so it would benefit no one, and least of all the lightning proponents, to rush things and hide weakness under the carpet or not go through a proper robust process
73 2015-08-13 17:04:24 <Aquentin> and the BIP66 mess didn't happen because no peer review... it happened because people were not given sufficient notice of the upcoming upgrade
74 2015-08-13 17:06:31 <mjerr> I guess thats another benefit of waiting till csv is ready
75 2015-08-13 17:06:32 <btcdrak> bip66 issues were not an issue with bip66 itswlf and we have learned a lot about the deployment so we can avoid those particular problems in the future. noone is suggesting rushing anything. if csv etc pass peer review and are included in a single soft fork, history tells us it takes less than 6 months for miners to adopt it.
76 2015-08-13 17:06:44 <mjerr> such that we can start announcing it now
77 2015-08-13 17:14:54 <Aquentin> I'm just worried that people may start taking a biased approach and stop presenting weaknesses in fear of "strengthening" the "other" sides arguments
78 2015-08-13 17:15:52 <Aquentin> we dealing with huge value and actual money here, whatever other debate there may be, we still need to be absolutely sure that any change is as smooth as possible and as bug free as possible
79 2015-08-13 17:17:25 <Aquentin> rather than try and rush things and handwave "small" things that wouldn't be ignored otherwise
80 2015-08-13 17:18:06 <btcdrak> Aquentin: i agree with you. my observation of the core developers is they are always super cautious and wumpus doesnt merge stuff without being totally convinced of the peer review. but my comment needs to be in context. i am saying if stuff gets accepted a sf will probably take 6 months from that point.