1 2015-08-25 01:15:25 <xulf> hey
  2 2015-08-25 01:15:44 <xulf> things are all screwed up PR wise
  3 2015-08-25 01:19:02 <wumpus> where?
  4 2015-08-25 01:19:59 <xulf> people don't understand the xt debate
  5 2015-08-25 01:20:18 <wumpus> oh please #bitcoin not here
  6 2015-08-25 01:21:50 <xulf> That's part of the problem right there
  7 2015-08-25 01:22:19 <Adlai> xulf: this channel is for discussion of technical issues, XT (ie blocksize and consensus) are out of that scope
  8 2015-08-25 01:29:11 <leakypat> I am investigating the possibility of using planet lab to run propagation tests on various blocksizes
  9 2015-08-25 01:29:42 <leakypat> In order to get time on the network you need to be a member of the consortium
 10 2015-08-25 01:30:21 <leakypat> If anyone has strong connections with any of these institutions , please ping me:
 11 2015-08-25 01:30:24 <leakypat> https://www.planet-lab.org/db/pub/sites.php
 12 2015-08-25 01:55:06 <leakypat> gavinandresen: this might be of particular interest for testing of your BIP proposal
 13 2015-08-25 01:55:38 <leakypat> Not sure if you have contacts at MIT ( I assume labs are affiliated in some way)
 14 2015-08-25 09:15:20 <gmaxwell> Whats the current blocker on starting to phase in C++11?  Sorry I haven't kept track of it...
 15 2015-08-25 09:20:41 <wumpus> gmaxwell: https://github.com/bitcoin/bitcoin/issues/6211
 16 2015-08-25 09:23:51 <phantomcircuit> gmaxwell, gcc stability mostly
 17 2015-08-25 09:24:53 <wumpus> gcc stability? not so much, gcc's c++11 support works great. There is a challenge is chossing what minimum versions to adopt?
 18 2015-08-25 09:25:36 <wumpus> "Some C++11 features have been finalized for some time, some are still experimental even in recent versions. What we should do is make a list of C++11 features we agree to use and add that to the coding standard, then set the minimum gcc and clang version based on that."  that was my last comment on it, since then, dragons happened
 19 2015-08-25 09:26:36 <wumpus> oh and there was an issue with gcc 5.x and gcc 4.x binary compatibility on some distros, but I'm no longer sure how it's related to c++11 specifically
 20 2015-08-25 09:29:07 <gmaxwell> phantomcircuit: there is no issue with respect to GCC statbility that I'm aware of it.
 21 2015-08-25 09:29:43 <phantomcircuit> gmaxwell, various c++11 features are unstable in various otherwise stable gcc versions
 22 2015-08-25 09:29:45 <gmaxwell> yea, I don't think the binary compat is related to C++11 at all, esp I think the major incompat change is the in memory structure for std::strings I thought (e.g. everything impacted)
 23 2015-08-25 09:29:48 <phantomcircuit> because fun
 24 2015-08-25 09:32:27 <wumpus> so to go forward with C++11 we need to document what features we want (sipa made a start in that issue) and base minimum clang/g++ versions on that that supports those features (robustly)
 25 2015-08-25 09:33:14 <gmaxwell> luke gave this table:
 26 2015-08-25 09:33:14 <gmaxwell> RHEL 7: GCC 4.8
 27 2015-08-25 09:33:15 <gmaxwell> Debian 8: GCC 4.8, 4.9
 28 2015-08-25 09:33:15 <gmaxwell> Gentoo stable: GCC 4.8
 29 2015-08-25 09:33:15 <gmaxwell> Ubuntu 14.04: GCC 4.8
 30 2015-08-25 09:33:17 <gmaxwell> Fedora 22: GCC 5.1
 31 2015-08-25 09:33:50 <gmaxwell> Man 4.8 also means usable, stable LTO, which is nice. And in general my confidence in the reliablity of >=4.8 is much higher than prior versions.
 32 2015-08-25 09:34:29 <wumpus> yes 4.8 would be ok
 33 2015-08-25 09:38:38 <wumpus> I'm pretty sure it gives us "move semantics, rvalue references, auto variables, and range loops"
 34 2015-08-25 09:38:45 <robbak> FreeBSD can use whatever. We already flag C++11 to keep away from really old compilers.
 35 2015-08-25 09:38:50 <wumpus> as those are very base C++11 things
 36 2015-08-25 09:42:59 <b-itcoinssg> Anyone know of any good merkle tree libraries in js, specifically one that has the ability to generate paths to leaves?
 37 2015-08-25 11:24:37 <jonasschnelli> b-itcoinssg: what about https://github.com/keybase/node-merkle-tree?
 38 2015-08-25 11:26:55 <b-itcoinssg> jonasschnelli: thanks, i did come across that, but sadly it doesn't provide functionality for the merkle proof/path. this one seems to provide basic proof/path functionality that I'll be building upon https://github.com/ethers/bitcoin-proof
 39 2015-08-25 11:27:46 <jonasschnelli> b-itcoinssg: Use https://code.google.com/p/crypto-js/ and create your own functions?
 40 2015-08-25 11:28:56 <b-itcoinssg> sure that's always an option. There's always a trade off between how much work I have to do vs how fast I can start using it.
 41 2015-08-25 13:19:03 <wumpus> jonasschnelli: that'd be very cool!
 42 2015-08-25 13:22:58 <morcos> jonasschnelli: That would be great!
 43 2015-08-25 13:24:48 <jonasschnelli> Not sure if i can contribute that much... maybe after the 2nd workshop there are things to do (that's more my part)
 44 2015-08-25 13:59:20 <GAit> jonasschnelli: would be great to have you there (and to meet you!)
 45 2015-08-25 14:00:12 <jonasschnelli> GAit: likewise
 46 2015-08-25 14:36:34 <jonasschnelli> No boost1.50 for Debian wheezy... need to find a way to use the just merged boost reverse_lock
 47 2015-08-25 14:37:06 <chester`> would larger block size also mean faster transactions/confirmations ?
 48 2015-08-25 14:38:42 <jonasschnelli> chester`: difficult to say. Depends on your given fee and on the current amount of unconfirmed transaction.
 49 2015-08-25 14:39:11 <chester`> on average
 50 2015-08-25 14:39:30 <jonasschnelli> chester`: If your fee target is confirmation within the next block, it will not be faster IMO
 51 2015-08-25 14:40:08 <jonasschnelli> chester`: it might be faster if you give low fees like 0.0001 (or similar).
 52 2015-08-25 14:40:37 <chester`> i was hoping larger block size could lead to instant confirmations like VISA/MASTERCARD
 53 2015-08-25 14:40:58 <chester`> at least for small buys
 54 2015-08-25 14:41:24 <jonasschnelli> please continue this discussion in #bitcoin (this is the development channel)
 55 2015-08-25 16:56:14 <tromp__> if a block has txB listed before txA, and txB has an txA output as input, can that be valid?
 56 2015-08-25 17:09:34 <Luke-Jr> tromp__: no
 57 2015-08-25 17:19:20 <tromp__> that's what I expected. thx, Luke-Jr
 58 2015-08-25 17:55:28 <runeks> Is there any form of ordering for the transactions in a block? I mean, can a transaction later in the list of transactions be redeemed by a transaction earlier in the list? I assume so, but I want to know.
 59 2015-08-25 17:55:47 <runeks> Within a single block, I mean.
 60 2015-08-25 17:56:33 <runeks> tromp__: I guess that's what I'm asking ?
 61 2015-08-25 17:56:36 <runeks> Too
 62 2015-08-25 18:00:21 <runeks> So, in other words, if I want to include two transactions in a block, one of which spends an output from the other one, I definitely need to think about ordering?
 63 2015-08-25 18:01:23 <runeks> When creating the block containing those two transactions
 64 2015-08-25 18:13:15 <nwilcox> runeks: I don't know Bitcoin (implicit, implementation defined) consensus here, but logically they should work in the same block in any order, afaik.
 65 2015-08-25 18:13:54 <nwilcox> Because TxIns refer to outpoints by hash, there's no possibility of cycles (assuming collision resistance).
 66 2015-08-25 18:16:52 <nwilcox> Hey runeks, these kinds of questions/topics ("how does Bitcoin do X?") might be better in #bitcoin.
 67 2015-08-25 18:17:03 <nwilcox> Do you mind asking your question there? I'm interested to hear the answer(s).
 68 2015-08-25 18:18:47 <runeks> nwilcox: thanks. I will try asking there too.
 69 2015-08-25 18:21:28 <runeks> This says intra-block transaction ordering matters: http://bitcoin.stackexchange.com/questions/23035/order-of-transactions-within-a-block (without any source though)
 70 2015-08-25 18:21:40 <rodarmor> I'm trying to understand issue #6586, 'automatically create hidden service, listen on tor', opened by wladimir
 71 2015-08-25 18:22:04 <rodarmor> This would create .onion hidden services, but how would those services be discovered?
 72 2015-08-25 18:24:40 <rodarmor> wumpus: ping
 73 2015-08-25 18:24:51 <nwilcox> runeks: Thanks for the reference!
 74 2015-08-25 18:24:57 <runeks> I would assume ordering does matter. bitcoin-qt was very sequential in its implementation. I assume it starts with the UTXO set and validates one transaction at a time, modifying the UTXO set along the way, starting from the first in the list. Thus making ordering a part of the protocol.
 75 2015-08-25 18:25:37 <runeks> nwilcox: Luke-Jr said yes in Bitcoin-dev as well. Fwiw.
 76 2015-08-25 18:26:34 <Luke-Jr> wouldn't it be fun if you could make TxnA spend a UTXO from TxnB, and TxnB spend a UTXO from TxnA? :P
 77 2015-08-25 18:27:03 <jouke> rodarmor: it publishes it to other nodes, just like it does now if you set up a bitcoin node as a hidden service
 78 2015-08-25 18:27:40 <rodarmor> jouke: What's the publication mechanism? Is there a good place (docs or code) to read up on how that works?
 79 2015-08-25 18:31:32 <jouke> rodarmor: https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery is a start
 80 2015-08-25 18:31:43 <rodarmor> jouke: Thanks!
 81 2015-08-25 18:34:12 <rodarmor> jouke: But doesn't that only cover sharing ip addresses, not .onion addresses?
 82 2015-08-25 18:34:18 <nwilcox> runeks: So if I understand correctly, to verify a block, a node can maintain an intrablock UTXO set, then play through txns in the serialization order, at each step immediately/locally verifying all input txns are already valid...
 83 2015-08-25 18:37:20 <jouke> rodarmor: it is a bit old, but afaik it works the same as sharing ip addresses
 84 2015-08-25 18:38:50 <runeks> nwilcox: That would be able to verify a transaction that redeems only outputs that have been created within the same block, yes.
 85 2015-08-25 18:39:48 <gmaxwell> rodarmor: the bitcoin network already has a mechenism to share and discover hidden services (using the same mechenism it uses for IPs)
 86 2015-08-25 18:40:25 <rodarmor> gmaxwell: So nodes can gossip about peers running as hidden services by sharing the .onion address, which will then be propagated around the network like an IP address?
 87 2015-08-25 18:41:38 <gmaxwell> rodarmor: yes.
 88 2015-08-25 18:41:51 <gmaxwell> This has worked for a couple years now.
 89 2015-08-25 18:41:57 <rodarmor> Gotcha
 90 2015-08-25 18:44:16 <nwilcox> runeks, I'm learning more about the codebase (if this is off-topic, let me know), and...
 91 2015-08-25 18:44:19 <nwilcox> Checking a block involves checking transactions in a loop: https://github.com/bitcoin/bitcoin/blob/0.11/src/main.cpp#L2706
 92 2015-08-25 18:44:26 <nwilcox> -but I don't see any order constraint in CheckTransaction: https://github.com/bitcoin/bitcoin/blob/0.11/src/main.cpp#L2706
 93 2015-08-25 18:44:48 <nwilcox> Oh... sorry, for the second link I meant https://github.com/bitcoin/bitcoin/blob/0.11/src/main.cpp#L799
 94 2015-08-25 18:45:31 <nwilcox> It looks like a CTransaction contains prevout hashes in memory, but not direct pointers (so their representation doesn't reify the graph in memory).
 95 2015-08-25 18:45:52 <nwilcox> So I'm not sure yet, where in the code, that ordering requirement is verified.
 96 2015-08-25 18:50:16 <tromp__> txs are checked in order,  and each one updates the state
 97 2015-08-25 18:50:44 <tromp__> with the wrong order, the state will be wrong
 98 2015-08-25 18:53:15 <tromp__> hmm, except  idon't see where state is updated in CheckTransaction:(
 99 2015-08-25 18:53:28 <nwilcox> tromp__: Thanks. I'll take your word for it. (I still don't see where the state is updated, starting from ConnectBlock and reading down the call stack, but I'll leave that as personal homework.)
100 2015-08-25 18:53:46 <nwilcox> tromp__: I expected state to be updated there, and I'm actually happy it isn't given the name. ;-)
101 2015-08-25 18:54:05 <tromp__> but then it should be a const argument
102 2015-08-25 18:54:52 <nwilcox> tromp__: Good call.
103 2015-08-25 18:55:27 <nwilcox> Hm, I see a CBlockUndo declaration in ConnectBlock, so presumably state modifications "should" occur below that?
104 2015-08-25 18:58:20 <tromp__> i think this state has nothing to do with UTXO
105 2015-08-25 18:58:52 <nwilcox> Ok.
106 2015-08-25 18:59:09 <tromp__> i guess CheckTransaction only does some basic sanity checks
107 2015-08-25 22:52:23 <jtimon> cfields: did you had a chance to review #6235 ?
108 2015-08-25 22:52:51 <cfields> jtimon: sorry, i have a few of yours in the queue. I'll get to that one and the other tonight for sure
109 2015-08-25 22:54:02 <jtimon> cfields: great thanks
110 2015-08-25 23:40:08 <jtimon> cfields: by "the other" you mean #6068 , #6382 or something else?