1 2015-12-07 04:22:31 <tigereye> Is something happening to testnet?
  2 2015-12-07 04:33:52 <tulip> tigereye: that's an ambiguous question.
  3 2015-12-07 04:49:01 <tigereye> sorry tulip. I just noticed a huge jump in hashrate on testnet
  4 2015-12-07 04:49:06 <tigereye> no big deal
  5 2015-12-07 04:51:30 <tigereye> looks like a fork at block 608825
  6 2015-12-07 04:51:33 <tigereye> height*
  7 2015-12-07 07:31:05 <sturles> What is this..: 2015-12-07 07:29:58 CommitTransaction: [...]
  8 2015-12-07 07:31:06 <sturles> 2015-12-07 07:29:59 AddToWallet 356f62cadf281a98af99a71539dce2b962ad236fa92c2294b522f148b87d8557  new
  9 2015-12-07 07:31:09 <sturles> 2015-12-07 07:29:59 CommitTransaction(): Error: Transaction not valid
 10 2015-12-07 07:31:40 <sturles> Looks like Bitcoin Core made an invalid transaction? o_O
 11 2015-12-07 07:35:15 <phantomcircuit> sturles, iirc you can get that from sendrawtransaction also
 12 2015-12-07 07:38:27 <sturles> I used sendmany.
 13 2015-12-07 07:38:28 <sturles> I used sendmany.
 14 2015-12-07 07:38:45 <sturles> 4 inputs, 9 recepients.
 15 2015-12-07 07:39:40 <sturles> All the inputs look good on blockchain.info.
 16 2015-12-07 07:40:16 <sturles> I wish it told me why the transaction is invalid. :-/
 17 2015-12-07 07:40:46 <sturles> Reponse from bitcoin-cli is "Commit failed".
 18 2015-12-07 07:44:39 <sturles> I run a recent version from git.  Tried to send again after a restart (untrimmed mempool), but same result.  The new tx used the same inputs in a different order.
 19 2015-12-07 07:46:31 <sturles> Can try again, and see if it chooses other inputs.  And make sure I go broke in case the old transaction somehow got broadcased and other nodes think it is valid..
 20 2015-12-07 07:48:41 <phantomcircuit> sturles, bc.i has had all kinds of insane bugs before so i wouldn't say them accepting it means anything
 21 2015-12-07 07:50:47 <phantomcircuit> sturles, which git version exactly?
 22 2015-12-07 07:51:04 <gmaxwell> "commit failed" sounds like a wallet db issue.
 23 2015-12-07 07:52:06 <sturles> Hmm.  But debug.log says: Error: Transaction not valid
 24 2015-12-07 07:52:34 <phantomcircuit> gmaxwell, nah it's from AcceptToMemoryPool returning false
 25 2015-12-07 07:53:04 <phantomcircuit> sturles, that error message literally is wrong, it actually means AcceptToMemoryPool returned false
 26 2015-12-07 07:53:12 <phantomcircuit> but there's more than one reason that can happen
 27 2015-12-07 07:54:44 <sturles> I forgot how to check which version I run..
 28 2015-12-07 07:54:50 <sturles> git version
 29 2015-12-07 07:55:10 <sturles> It is from Nov 12.
 30 2015-12-07 07:56:19 <phantomcircuit> sturles, what's the commit id?
 31 2015-12-07 07:56:21 <phantomcircuit> git log
 32 2015-12-07 07:56:23 <sipa> the wallet should not create invalid transactions
 33 2015-12-07 07:56:42 <sipa> so this does sound like a bug
 34 2015-12-07 07:57:00 <sturles> 77beab70deae8ad821cc069c1ce80fc809c89c33 + 32520bfb9e450522cc507faf30bf2eadecdf349b
 35 2015-12-07 07:57:01 <sturles> 77beab70deae8ad821cc069c1ce80fc809c89c33 + 32520bfb9e450522cc507faf30bf2eadecdf349b
 36 2015-12-07 08:00:40 <phantomcircuit> sipa, not necessarily
 37 2015-12-07 08:00:54 <phantomcircuit> sturles, bitcoin.conf (scrubbed of personally identifying info of course)
 38 2015-12-07 08:00:55 <phantomcircuit> sturles, bitcoin.conf (scrubbed of personally identifying info of course)
 39 2015-12-07 08:02:15 <sturles> Hmm.  The tx set nLockTime=387031.  That's a while ago.  Is that normal?
 40 2015-12-07 08:04:19 <phantomcircuit> sturles, sounds like the wallet created the transaction while you were updating
 41 2015-12-07 08:04:29 <phantomcircuit> and thus created a transaction with a locktime in the past
 42 2015-12-07 08:04:43 <gmaxwell> which is fine.
 43 2015-12-07 08:04:46 <phantomcircuit> neat but not actually interesting
 44 2015-12-07 08:04:47 <phantomcircuit> neat but not actually interesting
 45 2015-12-07 08:05:05 <phantomcircuit> we should probably improve the error reporting then
 46 2015-12-07 08:05:16 <sturles> phantomcircuit: http://0bin.net/paste/kA+iB0Srfb-iImjT#fffiRrTqKOIWlBqHJIM6PlqmDCvaoTF052IguZnpn1t
 47 2015-12-07 08:05:25 <sturles> It wasn't updating.
 48 2015-12-07 08:05:51 <sturles> It has been running fine all the time, and has the last block.
 49 2015-12-07 08:05:52 <sturles> It has been running fine all the time, and has the last block.
 50 2015-12-07 08:06:36 <sturles> Didn't think it was a problem, just interesting.
 51 2015-12-07 08:07:10 <phantomcircuit> sturles, seems unlikely
 52 2015-12-07 08:07:24 <phantomcircuit> possibly you had all the headers but had not validated the blocks?
 53 2015-12-07 08:07:39 <phantomcircuit> (the wallet sets nLockTime based on the height of the best valid block)
 54 2015-12-07 08:07:48 <sturles> getinfo says:   "blocks": 387127,
 55 2015-12-07 08:08:14 <sturles> This was 387125 last time I checked, just after sending the tx.
 56 2015-12-07 08:09:07 <gmaxwell> whats the immediately prior block acceptance in the log before the transaction?
 57 2015-12-07 08:09:08 <gmaxwell> whats the immediately prior block acceptance in the log before the transaction?
 58 2015-12-07 08:09:11 <phantomcircuit> wait
 59 2015-12-07 08:09:35 <phantomcircuit> nLockTime = 387031 would mean the tx was valid at 387127
 60 2015-12-07 08:10:00 <phantomcircuit> you hit the "random older locktime" thing
 61 2015-12-07 08:10:05 <phantomcircuit> but it shouldn't matter
 62 2015-12-07 08:10:25 <sturles> I can try sending it again, just to make sure I go broke if both work..  (The first and the second are mutually exclusive for using the same inputs.)
 63 2015-12-07 08:10:36 <sturles> 2015-12-07 07:20:18 UpdateTip: new best=00000000000000000751d7d93c9bb79d58c87037abfe32c0e5fd0fe225bdbace  height=387125  log2_work=83.701795  t
 64 2015-12-07 08:10:36 <sturles> Three lines above the failing tx is:
 65 2015-12-07 08:10:40 <sturles> x=96176842  date=2015-12-07 07:20:00 progress=1.000000  cache=146.5MiB(37563tx)
 66 2015-12-07 08:10:58 <gmaxwell> sturles: just sendrawtransaction the one that failed.
 67 2015-12-07 08:10:59 <gmaxwell> sturles: just sendrawtransaction the one that failed.
 68 2015-12-07 08:11:28 <sturles> How?  I can't getrawtransaction it.
 69 2015-12-07 08:11:57 <sturles> If I could, I would send it to someone for debugging.
 70 2015-12-07 08:12:50 <sturles> It may be in my wallet.dat, but I won't send my wallet.dat to anyone..
 71 2015-12-07 08:13:15 <phantomcircuit> sturles, try gettransaction
 72 2015-12-07 08:13:17 <phantomcircuit> sturles, try gettransaction
 73 2015-12-07 08:13:21 <phantomcircuit> if it's in the wallet it'll be in there
 74 2015-12-07 08:14:20 <sturles> Ah, right!
 75 2015-12-07 08:14:25 <sturles> Yes, got it.
 76 2015-12-07 08:15:03 <sturles> WTF?  256: absurdly-high-fee
 77 2015-12-07 08:15:28 <sturles> "fee": -0.00014160
 78 2015-12-07 08:16:07 <gmaxwell> lol
 79 2015-12-07 08:17:11 <phantomcircuit> attack of the fee estimator
 80 2015-12-07 08:17:13 <phantomcircuit> attack of the fee estimator
 81 2015-12-07 08:18:39 <sturles> Known bug?
 82 2015-12-07 08:18:42 <sturles> Known bug?
 83 2015-12-07 08:19:13 <gmaxwell> I don't think it's a fee estimator bug.
 84 2015-12-07 08:19:14 <gmaxwell> I don't think it's a fee estimator bug.
 85 2015-12-07 08:19:26 <sturles> $ bitcoin-cli estimatefee 1
 86 2015-12-07 08:19:27 <sturles> 0.00443225
 87 2015-12-07 08:19:27 <sturles> $ bitcoin-cli estimatefee 1
 88 2015-12-07 08:19:35 <sturles> That is a high fee!
 89 2015-12-07 08:19:36 <sturles> That is a high fee!
 90 2015-12-07 08:21:11 <gmaxwell> Whats the actual fee on the transaction in question?
 91 2015-12-07 08:21:18 <gmaxwell> Whats the actual fee on the transaction in question?
 92 2015-12-07 08:21:47 <sturles> 0.00014160 according to gettransaction.
 93 2015-12-07 08:21:48 <sturles> 0.00014160 according to gettransaction.
 94 2015-12-07 08:22:01 <sturles> Which is on the low side..
 95 2015-12-07 08:22:06 <sturles> Which is on the low side..
 96 2015-12-07 08:22:36 <gmaxwell> hm. Dunno how that would hit absurdly-high-fee... hm. have you changed any of the fee settings?
 97 2015-12-07 08:22:39 <gmaxwell> hm. Dunno how that would hit absurdly-high-fee... hm. have you changed any of the fee settings?
 98 2015-12-07 08:23:40 <sturles> confirmationtarget=4
 99 2015-12-07 08:23:58 <sturles> There are no change outputs.  Looks like it matched up the inputs well.
100 2015-12-07 08:23:59 <sturles> There are no change outputs.  Looks like it matched up the inputs well.
101 2015-12-07 08:29:45 <sturles> But..  When I sum all the inputs, I get 10.29070490 BTC.  The sum of all outputs is 10.2662 BTC.  This means the real fee is 0.02450490 BTC.  A bit much, yes.
102 2015-12-07 08:29:46 <sturles> But..  When I sum all the inputs, I get 10.29070490 BTC.  The sum of all outputs is 10.2662 BTC.  This means the real fee is 0.02450490 BTC.  A bit much, yes.
103 2015-12-07 08:30:15 <sturles> Why does gettransaction come to 0.00014160 then?
104 2015-12-07 08:34:29 <sturles> No ideas?
105 2015-12-07 08:47:27 <sturles> I need to get some breakfast.  There is clearly something wrong here.  It seems that something calculated the fee for this transaction, and got it wrong.  It decided to not add a change output.  AcceptToMemoryPool then calculated the correct fee, and caught this.
106 2015-12-07 09:33:47 <sturles> No, the fee of 0.00014160 is correct, according to https://live.blockcypher.com/btc/decodetx/
107 2015-12-07 09:33:50 <sturles> No, the fee of 0.00014160 is correct, according to https://live.blockcypher.com/btc/decodetx/
108 2015-12-07 09:34:08 <sturles> I'll try to push it somewhere else, and see if it works..
109 2015-12-07 09:34:09 <sturles> I'll try to push it somewhere else, and see if it works..
110 2015-12-07 09:44:28 <sturles> To sum up: My transaction with a fee of 0.00014160 BTC was denied by AcceptToMemoryPool due to absurdly-high-fee.
111 2015-12-07 09:56:43 <sturles> There was nothing wrong with the transaction.  It is confirmed now.
112 2015-12-07 10:01:22 <gmaxwell> Yea, I assume something is busted around absurdly-high-fee.
113 2015-12-07 11:35:36 <Lightsword> some idiot is patching p2pool to bypass the version check…https://www.reddit.com/r/bitcoinxt/comments/3vrf4e/i_made_a_fork_of_latest_version_of_p2pool_with/
114 2015-12-07 12:40:11 <Luke-Jr> Lightsword: lol
115 2015-12-07 15:24:55 <kanzure> lightning scalability matrix table from the slides http://web.archive.org/web/20151207152438/https://pbs.twimg.com/media/CVlmXyqUwAAlYfS.jpg:large
116 2015-12-07 16:53:23 <kanzure> chinese translation of common bitcoin terminology and jargon https://scalingbitcoin.org/chinese-terms
117 2015-12-07 16:53:24 <kanzure> chinese translation of common bitcoin terminology and jargon https://scalingbitcoin.org/chinese-terms
118 2015-12-07 16:53:29 <kanzure> harding: perhaps something like this should go on bitcoin.org somewhere
119 2015-12-07 17:05:03 <jl2012> kanzure: the list is optimized for simultaneous interpretation. Not very ready for written translation
120 2015-12-07 17:06:15 <kanzure> ah, i see
121 2015-12-07 17:07:27 <jl2012> and also has been created in a rush.
122 2015-12-07 17:08:37 <benjyz1> hello. I'm working with python-bitcoin and pybitcointools. any other similar libraries and efforts?
123 2015-12-07 17:10:06 <kanzure> instead of python-bitcoin please consider using python-bitcoinlib
124 2015-12-07 17:10:13 <kanzure> another related effort is pycoin
125 2015-12-07 17:10:14 <kanzure> another related effort is pycoin
126 2015-12-07 17:10:41 <benjyz1> ah right, thx. yes, I meant peter todd's python-bitcoinlib
127 2015-12-07 17:11:06 <benjyz1> I'm trying to port some or all of it to jython
128 2015-12-07 17:12:39 <benjyz1> to combine with bitcoinj. perhaps somebody is interested in that
129 2015-12-07 20:04:31 <btcdrak> Luke-Jr: ping https://github.com/bitcoin/bips/pull/252
130 2015-12-07 20:04:33 <btcdrak> Luke-Jr: ping https://github.com/bitcoin/bips/pull/252
131 2015-12-07 21:44:16 <ginseng> exit
132 2015-12-07 22:04:05 <gmaxwell> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
133 2015-12-07 22:18:33 <morcos> gmaxwell: well said, and sounds good to me
134 2015-12-07 22:26:47 <atomos> sipa, secp256k1_ge_is_valid(elem); what does it mean if an element generated by secp256k1_fe_t x; secp256k1_fe_set_b32(&x, pub+1); return secp256k1_ge_set_xo(elem, &x, pub[0] == 0x03);  etc..     if (size == 33 && (pub[0] == 0x02 || pub[0] == 0x03)) {,  fails secp256k1_ge_is_valid(elem);
135 2015-12-07 22:27:32 <atomos> should secp256k1_ge_is_valid, work for every valid 33 byte point on curve
136 2015-12-07 22:27:59 <sipa> yes
137 2015-12-07 22:28:14 <sipa> eh
138 2015-12-07 22:28:24 <atomos> because if I generate random private keys, then generate public key (point on curve) and export as 33 bytes, then import that public key, then it sometimes fails secp256k1_ge_is_valid
139 2015-12-07 22:28:25 <sipa> not sure exactly what you're asking
140 2015-12-07 22:28:34 <sipa> wow
141 2015-12-07 22:28:40 <sipa> that should not happen!
142 2015-12-07 22:28:46 <sipa> are you certain.
143 2015-12-07 22:28:49 <sipa> ?
144 2015-12-07 22:28:54 <atomos> yes
145 2015-12-07 22:29:02 <atomos> i am working on gocoin's port of your library
146 2015-12-07 22:29:02 <sipa> can i see the code?
147 2015-12-07 22:29:29 <atomos> and testing it vs my golang wrapper for your library and fuzzing it
148 2015-12-07 22:30:16 <sipa> oh, port, not wrapper?
149 2015-12-07 22:30:17 <sipa> oh, port, not wrapper?
150 2015-12-07 22:30:29 <atomos> I am wrapping your library and it works
151 2015-12-07 22:30:51 <atomos> but i am taking his port and added extra error checking and was getting crashes for certain inputs, one second
152 2015-12-07 22:31:35 <atomos> gocoin does not check that private key is less than order of curve in his library and other things like that
153 2015-12-07 22:33:43 <atomos> sipa, https://i.imgur.com/Q81SgPn.png https://i.imgur.com/EzJPTHG.png
154 2015-12-07 22:34:47 <sipa> set_xo can fail
155 2015-12-07 22:35:00 <atomos> ahhhh, he does not have a return value on that
156 2015-12-07 22:35:43 <sipa> well i don't know their code!
157 2015-12-07 22:38:36 <atomos> sipa, https://i.imgur.com/VvBh6ln.png
158 2015-12-07 22:39:17 <sipa> that looks like a port of very old code
159 2015-12-07 22:59:19 <atomos> sipa, your library works flawlessly; error does not show up, its just in his. I wonder what causes it