1 2015-09-27 00:00:51 <jgarzik> cfields, also, focusing on correctness and security, so moving the codebase to C++ as well as O_DIRECTORY etc.
  2 2015-09-27 00:01:17 <jgarzik> most current GNU utils still turn up buffer overruns and such
  3 2015-09-27 00:01:59 <cfields> i see
  4 2015-09-27 00:02:14 <midnightmagic> I like the /w 16
  5 2015-09-27 00:28:21 <ploopkazoo> bitcoind is, apparently randomly, taking anywhere from ~0 to ~90 seconds to respond to rpc requests. could this be related to the fact that it's still downloading and verifying the blockchain?
  6 2015-09-27 00:28:58 <ploopkazoo> (namecoind always responds instantly but is not catching up)
  7 2015-09-27 00:38:37 <pigeons> ploopkazoo: yes
  8 2015-09-27 00:42:11 <ploopkazoo> pigeons: I don't really know what I'm talking about, but given my limited intuition, that means that the p2p and web server portions of bitcoind are running in the same process, which might not be a good idea?
  9 2015-09-27 05:20:57 <ProfMac> Is there a tool that dumps peers.dat?
 10 2015-09-27 06:46:03 <maaku> ploopkazoo: what is happening is that you are downloading blocks out of order, and then when a sequence of blocks is ready a lock is taken
 11 2015-09-27 06:46:27 <maaku> and that's causing your rpc requests to lag. totally normal
 12 2015-09-27 06:56:19 <maaku> rusty: re: BIP 9 -- am I correct in inferring that both lock-in and activation only happen on (height % 2016 == 0) blocks?
 13 2015-09-27 06:59:59 <rusty> maaku: yes.
 14 2015-09-27 07:01:59 <maaku> rusty: looks better than prior drafts, only the most trivial of nits that might not even be worth fixing
 15 2015-09-27 07:02:39 <maaku> e.g. it is technically possible to have 30 bits (via high-order bits 01), which the BIP claims is impossible
 16 2015-09-27 07:03:16 <rusty> maaku: high order bits are 001 though?
 17 2015-09-27 07:03:50 <rusty> maaku: yeah, it got pared back; it's much closer to the original now.  The main differences are the activation pause, the removal of the 75% threshold, and more rigor around timeouts (though obviously, you can't force anyone).
 18 2015-09-27 07:04:23 <maaku> "Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible"
 19 2015-09-27 07:04:36 <maaku> maybe I'm misinterpreting some abiguity on what that final "that" means
 20 2015-09-27 07:05:11 <maaku> I'm happy that we're only testing every 2016 blocks
 21 2015-09-27 08:33:13 <sipa> maaku: agree, should be 30
 22 2015-09-27 09:15:48 <ProfMac> is the locktime parameter ignored by createrawtransaction
 23 2015-09-27 10:18:47 <btcdrak> rusty: is anyone working on a versionbits implementation yet?
 24 2015-09-27 10:26:17 <wumpus> ProfMac: createrawtransaction does not have a locktime parameter at this moment; there is a pull adding it AFAIK
 25 2015-09-27 10:31:48 <ProfMac> I'm drinking beer and crafting raw transactions.  I may cry later.  I did hex edit a transaction before signing and created a sequence number and locktime.  I was able to submit it.
 26 2015-09-27 10:32:39 <wumpus> the bitcoin-tx utility does offer a way to add an nlocktime, by the way
 27 2015-09-27 10:33:08 <wumpus> drinking and crafting raw transactions, living on the edge eh
 28 2015-09-27 10:37:14 <wumpus> https://github.com/bitcoin/bitcoin/pull/5936 "[RPC] Add optional locktime to createrawtransaction"
 29 2015-09-27 10:39:21 <ProfMac> thanks for the link.
 30 2015-09-27 10:48:41 <wumpus> cfields petertodd: hahha, I only noticed now, don't tell me people are grinding gpg signatures to end up with that ;-)
 31 2015-09-27 11:07:32 <sipa> btcdrak: CodeShark
 32 2015-09-27 11:55:16 <btcdrak> sipa:
 33 2015-09-27 12:04:20 <sipa> btcdrak:
 34 2015-09-27 12:14:44 <btcdrak> this could go on forever
 35 2015-09-27 12:15:01 <btcdrak> sipa: you pinged me?
 36 2015-09-27 12:16:01 <btcdrak> sipa: ah, ok I think I get it, CodeShark is implementing versionbits
 37 2015-09-27 16:37:39 <ProfMac> I'm building transactions and reading web documentation instead of code this weekend.  I ran across https://bitcointalk.org/index.php?topic=244656.0   Was locktime implemented at one time, then de-comissioned?
 38 2015-09-27 16:39:40 <maaku> ProfMac: not understanding the question. lock-time is a consensus rule in bitcoin...
 39 2015-09-27 16:43:19 <ProfMac> My first attempts at crafting a transaction and using locktime and sequence numbers to update a transaction lead to rejected transactions.  This is all first exploration stuff, so anything could be wrong.
 40 2015-09-27 16:44:10 <sipa> locktime has a consenus effect
 41 2015-09-27 16:44:36 <sipa> sequence numbers not really (apart from setting them all to max causes locktimes to be ignored)
 42 2015-09-27 17:37:31 <maaku> BIP 68 relative lock-time is not yet consensus rules
 43 2015-09-27 17:38:10 <maaku> for regular absolute lock-time, you can create transactions but they will not be relayed by the network until the lock-time is reached
 44 2015-09-27 17:51:28 <ProfMac> I have two signed raw transactions for testnet :-)  Each spends the same vout, and some relevant details are {sequence":2, "locktime": 574729} and {"sequence":1, "locktime": 574730}  I sendrawtransaction on  {1, 574730} and it shows up in getrawmempool.  I then sendrawtransaction on {2, 574729} and I get an error (-25) and getrawmempool does not change.
 45 2015-09-27 17:51:41 <ProfMac> I can post the hex here if that is not offensive.
 46 2015-09-27 17:56:20 <arubi> er, sorry to barge,if you broadcasted the first, and it's in your mempool, then the second, then core would error because of a double spend. am I correct?
 47 2015-09-27 17:56:55 <ProfMac> not as I understand it.  The 1st is not in a block because of locktime and sequence number, and the 2nd can replace it.
 48 2015-09-27 17:57:35 <arubi> doesn't have to be in a block for it to cause an error, though there are more knowledgeable folks here who can tell for sure
 49 2015-09-27 17:57:35 <ProfMac> There is a whole sequence of web articles on micropayments using this off-blockchain.
 50 2015-09-27 17:58:21 <ProfMac> Well, it clearly does cause an error, but as I read the use of seq # and locktimes, I think the design is that it doesn't.  So I don't understand something.
 51 2015-09-27 17:58:43 <arubi> I specifically think this is the case because of the '-25' code.
 52 2015-09-27 18:00:00 <ProfMac> That is my interpretation.  So I'm hoping a dev will jump in and clarify if this is a bug, an unimplemented feature, a change in behavior for some reason (security?) or whatever.
 53 2015-09-27 18:01:06 <ProfMac> 00
 54 2015-09-27 18:01:06 <ProfMac> Here is the first transaction:  sendrawtransaction  010000000147d9018ee1db7ab1e9d9fa950a0bf897bb8b42fea621e60fa656469b0cbbc00a000000006a47304402206ff524dae9dd639a3b3a190784545f948ec17dc6bd9ad095b43f2cfd705a998f022075704524afc5752082943ecdebcddb25e9fdf3691beb678acac528d2a12472e901210236bb73b0ad2f00716b391faa3bf1f67e9b9c49fe00e079ed99fe8d71d0011d6d0100000001f0ca052a010000001976a914e768ffdf27eeb1d790eeaf002d9ebb777d4cf15488ac0bc508
 55 2015-09-27 18:01:37 <arubi> you can try doing it the other way while keeping both locktimes way ahead of the next block, just to have more data to look at
 56 2015-09-27 18:01:38 <ProfMac> Here is the 2nd:
 57 2015-09-27 18:01:39 <ProfMac> 
 58 2015-09-27 18:01:39 <ProfMac> sendrawtransaction 010000000147d9018ee1db7ab1e9d9fa950a0bf897bb8b42fea621e60fa656469b0cbbc00a000000006b483045022100d242cc922a10c2405c90d4fc193e36b9bcc0e8bcf378a6328f0b3bbcb5fa65dd022068dc7809c8fca18a346f54d9a06467120a0ad348fc1e974aa251d38e31df1a2f01210236bb73b0ad2f00716b391faa3bf1f67e9b9c49fe00e079ed99fe8d71d0011d6d0200000001f0ca052a010000001976a914e768ffdf27eeb1d790eeaf002d9ebb777d4cf15488ac0ac50800
 59 2015-09-27 18:03:14 <Yoghur114> fyi http://srv1.yogh.io/#tx:raw:010000000147d9018ee1db7ab1e9d9fa950a0bf897bb8b42fea621e60fa656469b0cbbc00a000000006a47304402206ff524dae9dd639a3b3a190784545f948ec17dc6bd9ad095b43f2cfd705a998f022075704524afc5752082943ecdebcddb25e9fdf3691beb678acac528d2a12472e901210236bb73b0ad2f00716b391faa3bf1f67e9b9c49fe00e079ed99fe8d71d0011d6d0100000001f0ca052a010000001976a914e768ffdf27eeb1d790eeaf002d9ebb777d4cf15488ac0bc50800
 60 2015-09-27 18:04:27 <ProfMac> Hey, that's cool.
 61 2015-09-27 18:11:38 <maaku> ProfMac: there is no transaction replacement implemented in bitcoin core
 62 2015-09-27 18:12:01 <maaku> so once the first is in you mempool, the second will be rejected as a double-spend
 63 2015-09-27 18:12:43 <ProfMac> That is consistent with what I see.  There is a lot of web page out there that disagrees, however.
 64 2015-09-27 18:15:13 <maaku> ProfMac: the code is correct, not the interwebs
 65 2015-09-27 18:15:32 <maaku> there is no documentation source which accurately describes how bitcoin core operates
 66 2015-09-27 18:15:42 <maaku> although the developer guide on bitcoin.org comes close
 67 2015-09-27 18:20:17 <ProfMac> I started on https://bitcoin.org/en/developer-documentation and took a hop to the micropayment channel example from there, over to https://bitcoinj.github.io/working-with-micropayments, so it looked pretty safe to trust what it said.  The "Prof" in ProfMac thinks documentation should stay close to field truth...
 68 2015-09-27 18:21:03 <ProfMac> Anyway, if it in fact does not work, and I am not misunderstanding something fundamental, I'm off to other things in my day at this point.
 69 2015-09-27 18:24:58 <maaku> ProfMac: it's not clear to me wha tyou are trying to do
 70 2015-09-27 18:25:17 <maaku> for micropayment channels, you don't broadcast to the chain until you are ready to close
 71 2015-09-27 18:25:38 <maaku> and on production bitcoin, no transaction is accepted into the mempool until it is spendable
 72 2015-09-27 18:26:18 <maaku> what are you trying to accomplish where you are sending two transactions to the network and expecting one to replace the other?
 73 2015-09-27 18:31:13 <btcdrak> Yoghur114: that's pretty cool.
 74 2015-09-27 21:30:34 <maaku> anyone wliling to ACK or NAK #6312?
 75 2015-09-27 21:39:41 <maaku> sipa: for some reason I've not been getting notificaion emails about your reviews
 76 2015-09-27 21:40:02 <maaku> nor are they showing up in the pull request after I fixed & pushed the first few fixes
 77 2015-09-27 21:44:34 <sipa> maaku: can you search your spam mailbox or something :)
 78 2015-09-27 21:44:53 <maaku> sipa: zero messages
 79 2015-09-27 21:45:10 <maaku> sipa: I'm not sure what you are considering to be ugly about LockTime()
 80 2015-09-27 21:45:13 <sipa> maaku: so i commented that you're mixing data from pindexBestHeader (which is a global) and a passed pcoinsView
 81 2015-09-27 21:45:24 <sipa> which are not necessarily consistent with eachother
 82 2015-09-27 21:45:54 <maaku> well can I get height of tip from pcoinsView?
 83 2015-09-27 21:46:10 <sipa> yes
 84 2015-09-27 21:46:49 <sipa> pcoinsView is consistent with pindexBestBlock, and pindexBestHeader is always ahead of pindexBestHeader
 85 2015-09-27 21:47:03 <sipa> but the mempool isn't, and the wallet isn't
 86 2015-09-27 21:47:12 <sipa> and that incocnsistency may increasy in the futute
 87 2015-09-27 21:47:15 <maaku> sipa: do you know the commit has that you reviewed? maybe I can get your review messages that way
 88 2015-09-27 21:47:34 <sipa> if we do.more processing asynchronously
 89 2015-09-27 21:48:22 <sipa> (which isn't a concern now, but it's a nice extra)
 90 2015-09-27 21:49:05 <sipa> i really think you should just pass in a vector with heights and times of the input coins; you can still use a wrapper that fetches from the coinstip for consensus cases
 91 2015-09-27 21:49:13 <sipa> but for wallet and mempool, there are better ways
 92 2015-09-27 21:49:42 <sipa> and that way you're not relying on the assumed "the coin will never be missing when used in consensus cases"
 93 2015-09-27 21:49:50 <sipa> the code should just always work
 94 2015-09-27 21:52:02 <maaku> so views only expose GetBestBlock that returns a hash
 95 2015-09-27 21:52:39 <sipa> and it's sort of meaningless for the mempool
 96 2015-09-27 21:52:49 <sipa> because there is no block yet associated with that view
 97 2015-09-27 21:53:42 <maaku> so you assume the inputs made it into the next block. but you're calling that ugly
 98 2015-09-27 21:55:04 <sipa> how do you mean?
 99 2015-09-27 21:56:13 <sipa> if you're special cases the code on MEMPOOL_HEIGHT, you're putting knowledge on GetLockTime that makes assumptions about which possible inputs it can get
100 2015-09-27 21:56:24 <sipa> *casing
101 2015-09-27 21:57:23 <sipa> furthermore, it is wrong. spending a locktimed input from the mempool should not ignore anything
102 2015-09-27 21:57:37 <maaku> well IMHO using MEMPOOL_HEIGHT is the mistake
103 2015-09-27 21:58:05 <sipa> perhaps, but it wouldn't make the existing code less buggy
104 2015-09-27 21:58:11 <sipa> and it's still wromg
105 2015-09-27 21:58:49 <maaku> then what? not have mempool check lock-time via LockTime()?
106 2015-09-27 21:58:54 <maaku> what's the solution here?
107 2015-09-27 21:59:20 <sipa> have the mempool pass in current time and height + 1 as height/time for unspent inputs
108 2015-09-27 21:59:48 <sipa> have the wallet pass in the known time and height of inputs
109 2015-09-27 21:59:57 <sipa> have the consensus code fetch it from pcoinstip
110 2015-09-27 22:00:02 <maaku> so now everything calling LockTime() has to do the work of fetching inputs and constructing a map of intputs -> height,time?
111 2015-09-27 22:00:09 <maaku> what's the point of having a view then?
112 2015-09-27 22:01:35 <sipa> another solution may be to make the mempool construct a fake block, with a height and time that makes assumptions
113 2015-09-27 22:01:42 <sipa> and report that via a view
114 2015-09-27 22:01:50 <sipa> but that still isn't a solution for the wallet
115 2015-09-27 22:02:26 <sipa> the view wasn't designed to have height and time be consensus critical, except for coinbase transactions
116 2015-09-27 22:04:27 <sipa> maaku: well another way of looking at it... you're not just using data from the view, but also fetching the time of coins by looking them up in the block index... which doesn't work for mempool transactioms
117 2015-09-27 22:05:05 <maaku> sipa: yes I get that, but the solution isn't "don't fetch the time"
118 2015-09-27 22:05:21 <maaku> BIP 68 makes time-based age of inputs consensus critical
119 2015-09-27 22:05:23 <sipa> perhaps CCoinsView needs to get extra methods to fetch the getmediantimepast of a coins
120 2015-09-27 22:05:37 <sipa> which then can be overridden by the mempool
121 2015-09-27 22:06:08 <sipa> so LockTime doesn't need pindexBestHeader either
122 2015-09-27 22:06:31 <sipa> and instead of MEMPOOL_HEIGHT, report current height + 1
123 2015-09-27 22:06:41 <sipa> in the coins
124 2015-09-27 22:06:56 <sipa> still not a solution for the wallet, though :)
125 2015-09-27 22:07:21 <maaku> by which you meaning missing dependencies right?
126 2015-09-27 22:07:24 <sipa> but having a walletcoinsview would be nice, and probably doable
127 2015-09-27 22:07:37 <maaku> those simply fail & return numeric_limits::max
128 2015-09-27 22:07:48 <sipa> no, i mean for old spent transactions
129 2015-09-27 22:08:03 <sipa> i guess it doesn't matter for them
130 2015-09-27 22:08:26 <maaku> a walletcoinsview would be good, but not release blocker imho
131 2015-09-27 22:08:32 <sipa> fair enough
132 2015-09-27 22:08:43 <maaku> because yes, doesn't actually matter. just not as helpful an output as it could be..
133 2015-09-27 22:10:10 <maaku> the segfault is obviously more of an issue. I was hoping we could get agreement that what is there now (after special casing MEMPOOL_HEIGHT) is at least safe with present bitcoin, then do a separate PR to modify how views work to clean it up
134 2015-09-27 22:10:10 <sipa> are you ok with adding a GetCreationTime method to CCoinsView, taking a CCoins as parameter?
135 2015-09-27 22:10:25 <maaku> but if that's not possible I suppose I could work this week to change views
136 2015-09-27 22:10:47 <maaku> yes i'm ok with that, just want clarity on whether this is a requirement for #6312
137 2015-09-27 22:10:53 <sipa> well, at least none of the MEMPOOL_HEIGHT stiff os consensus critical
138 2015-09-27 22:10:56 <sipa> by definition
139 2015-09-27 22:11:03 <sipa> stuff is
140 2015-09-27 22:11:27 <sipa> how about special casing on GetAncestor returning NULL?
141 2015-09-27 22:11:39 <maaku> right ok that's probably cleaner
142 2015-09-27 22:11:45 <sipa> and interpreting that as "future"
143 2015-09-27 22:12:06 <maaku> and adding a note about how this should be done via GetCreationTime on View (and add that to my todo list...)
144 2015-09-27 22:12:38 <sipa> i agree that's probably too invasive for a soft forl
145 2015-09-27 22:12:48 <sipa> because we also want to be able to backport those
146 2015-09-27 22:14:13 <sipa> having CCoinsView return a CBlockIndex* instead of a hash would also be better; those are immutable anyway
147 2015-09-27 22:14:37 <sipa> and the mempool would just return NULL because there is no block associated with it
148 2015-09-27 23:47:15 <OxADADA> bloodmoon
149 2015-09-27 23:47:18 <OxADADA> tonight.
150 2015-09-27 23:48:31 <ReconCat> hi, does anyone here have a link to good resources on how to create an altcoin? I realize theres no support for alts here but the inner workings are really what im looking for.
151 2015-09-27 23:48:50 <ReconCat> hence start with the OG
152 2015-09-27 23:49:04 <sipa> ReconCat: ##altcoin-dev
153 2015-09-27 23:49:30 <ReconCat> ah, thanks much. i dont know why i didnt try that one but i tried crypto-dev lol