1 2015-12-29 00:42:45 <warren> How much bandwidth does a listening full node consume?
  2 2015-12-29 00:44:59 <sipa> 0.12 will have -blocksonly mode, which can run with avg 2 KiB/s or so
  3 2015-12-29 00:48:33 <warren> sipa: would it help the network for -blocksonly to be listening?
  4 2015-12-29 00:54:00 <sipa> warren: define "help the network"
  5 2015-12-29 00:58:13 <Dizzle> Another node running, even with -blocksonly would add to the blockchain's availability. So it would help in that sense.
  6 2015-12-29 01:00:01 <warren> Dizzle: if a great many nodes don't relay transactions, could have a negative effect, and would encourage more nodes to increase their outbound connection count.
  7 2015-12-29 01:02:20 <Dizzle> Right
  8 2015-12-29 07:55:34 <HoloIRCUser4> congrats, guys
  9 2015-12-29 09:30:33 <jl2012> my comments for sipa 's segwit commitment code: https://github.com/sipa/bitcoin/commit/86516919286c6f322df75ce770a19f4402596ccf
 10 2015-12-29 10:35:07 <Yoghur114> regarding the deployment of SW on a separate testnet (reading the capacity increase faq): why is this? Is it not valuable to see, exactly, how SW TXs and pre-SW UTXOs behave when encountered by old nodes? It would more accurately reflect what might happen on Bitcoin proper I would say.
 11 2015-12-29 10:42:15 <Luke-Jr> so my 0.10-based node has been stuck at 12 days behind (now) for about 4 days or so.. getchaintips shows the current chain as headers-only; getpeerinfo shows nothing inflight and multiple peers with synced_headers correct
 12 2015-12-29 10:42:31 <Luke-Jr> restarting the node multiple times in those 4 days has done nothing to improve the situation
 13 2015-12-29 10:43:25 <Luke-Jr> prior to this situation (and why it's clearly not an emergency), my node had segfaulted and needed to reindex
 14 2015-12-29 10:44:15 <Luke-Jr> curiously, the next block 0000000000000000077152ba5cde04dbc4afa243ad33022ab2d2cbb3c28dd9c4 is getblock-able
 15 2015-12-29 10:48:23 <Luke-Jr> aha
 16 2015-12-29 10:48:27 <Luke-Jr> 2015-12-25 01:51:39 ERROR: ConnectBlock() : inputs missing/spent
 17 2015-12-29 10:48:29 <Luke-Jr> 2015-12-25 01:51:39 InvalidChainFound: invalid block=0000000000000000077152ba5cde04dbc4afa243ad33022ab2d2cbb3c28dd9c4
 18 2015-12-29 10:48:31 <Luke-Jr> height=388736  log2_work=83.751138  date=2015-12-16 15:42:16
 19 2015-12-29 10:54:55 <Luke-Jr> hm, reconsiderblock actually worked..
 20 2015-12-29 11:52:54 <sipa> Yoghur114: of course, but how do you suppose we test that?
 21 2015-12-29 12:07:04 <Yoghur114> sipa: on the current testnet - I see no clear reason to spin off a new one other than starting off with a clean slate - admittedly, all necessary conditions can be replicated on a new testnet, but why?
 22 2015-12-29 13:08:04 <jl2012> Yoghur114 It shouldn't be tested on the current testnet until the code is stable. A lot of bug fix and reset is expected
 23 2015-12-29 13:48:03 <Yoghur114> jl2012: Why is a testnet reset expected? I mean, I'm not opposed to it - but I don't understand the reason for it.
 24 2015-12-29 13:49:28 <jl2012> Bugs in consensus code, new features, etc
 25 2015-12-29 14:05:00 <maaku> Yoghur114: it is standard practice to use a separate testnet for things which have not merged into core yet
 26 2015-12-29 14:05:15 <maaku> it keeps from disrupting people who are using testnet for other things
 27 2015-12-29 14:05:47 <maaku> but this is NOT a testnet reset; the same testnet would keep being used. and once SW merges, it will probably activate first on testnet
 28 2015-12-29 14:10:53 <jl2012> maaku, I mean reset of segwit testnet, aka segnet
 29 2015-12-29 14:36:28 <jl2012> sipa, have you completely rewritten the CHECKSIG serialization in segwit?
 30 2015-12-29 14:37:23 <sipa> jl2012: yup
 31 2015-12-29 14:37:33 <sipa> it fixes the O(n^2) sighashing
 32 2015-12-29 14:37:41 <sipa> and adds amount under signature
 33 2015-12-29 14:38:03 <jl2012> the amount is mandatory, right?
 34 2015-12-29 14:38:11 <sipa> yup
 35 2015-12-29 14:38:45 <jl2012> do you want to use another OP codes, or still the same codes?
 36 2015-12-29 14:39:01 <jl2012> e.g. CHECKSIG2 with one of the unused code
 37 2015-12-29 14:39:09 <sipa> the same ones; you don't solve a DoS attack by making it optional :)
 38 2015-12-29 14:39:28 <jl2012> you can disable the old one in segwit
 39 2015-12-29 14:39:49 <sipa> that's a possibility, indeed
 40 2015-12-29 14:39:56 <jl2012> just better for documentation
 41 2015-12-29 14:40:21 <sipa> anyway, i consider this to be a preview of sorts... it's a delicate balance between complicating segwit, and fixing problems upfront
 42 2015-12-29 14:40:33 <jl2012> yes
 43 2015-12-29 14:40:33 <Luke-Jr> sipa: is there a way to do completely malleable-proof signatures?
 44 2015-12-29 14:40:55 <sipa> Luke-Jr: you'll need to define malleability :)
 45 2015-12-29 14:41:03 <Luke-Jr> sipa: CoinJoin and RBF included
 46 2015-12-29 14:41:34 <Luke-Jr> that is, for each input sign only the scriptPubKey hash [and amount?]
 47 2015-12-29 14:41:35 <sipa> EC based signatures are always malleability
 48 2015-12-29 14:41:48 <jl2012> the random k, right?
 49 2015-12-29 14:41:49 <Luke-Jr> in terms of spending
 50 2015-12-29 14:41:50 <sipa> by those who were able to sign in the first place
 51 2015-12-29 14:42:20 <Luke-Jr> that is, as long as 1someaddress is paid 5 BTC exactly, my signature should remain valid regardless of that transaction paying it
 52 2015-12-29 14:42:21 <sipa> there are signature schemes which are unique (every message and private key combination only has one single valid signature)
 53 2015-12-29 14:43:11 <Luke-Jr> any third party can modify the transaction I signed, to update the final txid/index which paid 1someaddress
 54 2015-12-29 14:43:42 <sipa> Luke-Jr: segwit will not allow anyone to modify the transaction you signed (at least not in a way that affects its txid)
 55 2015-12-29 14:44:01 <sipa> except people who have access to the used private keys
 56 2015-12-29 14:44:05 <Luke-Jr> sigh :<
 57 2015-12-29 14:44:18 <Luke-Jr> so it actually makes malleability worse in some ways?
 58 2015-12-29 14:44:23 <sipa> i don't understand
 59 2015-12-29 14:45:20 <Luke-Jr> Joe pays me 1 BTC at 1someaddress; I want to spend that unconfirmed UTXO in such a way that Joe can RBF it with a CoinJoin without breaking my own transaction spending it.
 60 2015-12-29 14:45:47 <Luke-Jr> so my signature needs to cover *only* the sPK+amount, nothing else about Joe's transaction at all
 61 2015-12-29 14:46:11 <sipa> you need something like sighash_noinput as proposed by the lightning guys
 62 2015-12-29 14:51:37 <jl2012> sighash_noinput is not safe if an address is reused. However, if the output includes a nonce in this form: <nonce> DROP <key> CHECKSIG, and the signature could cover the nonce, that would be safe
 63 2015-12-29 14:51:54 <jl2012> assuming the nonce is not reused, of course
 64 2015-12-29 14:53:02 <sipa> it still wouldn't solve malleability, but at least it makes it harmless
 65 2015-12-29 15:01:04 <jl2012> another BIP is needed for the new CHECKSIG. I can try to do it if you don't mind
 66 2015-12-29 15:02:08 <jl2012> as an exercise for me to learning reading codes
 67 2015-12-29 15:02:27 <sipa> feel free, though i think that's a bit premature
 68 2015-12-29 15:13:02 <Luke-Jr> jl2012: any wallet implementing such signatures would need to strongly reject any ruse
 69 2015-12-29 15:13:03 <Luke-Jr> reuse*
 70 2015-12-29 15:13:41 <sipa> you can't prevent others from reusing your addresses
 71 2015-12-29 15:13:44 <Luke-Jr> ie, even if it learns about a second transaction, it should at the very least show it as never confirmed until spent
 72 2015-12-29 15:13:54 <Luke-Jr> sipa: you can refuse to honour it as a valid payment
 73 2015-12-29 15:14:04 <Luke-Jr> the sender is at fault in that case
 74 2015-12-29 15:14:47 <Luke-Jr> it's no different than them modifying the scriptPubKey in some unexpected way
 75 2015-12-29 15:42:44 <arioBarzan> how difficult would be for add a custom feature to rpc signrawtransaction, for giving specific "nonce" to be passed to secp256k1_ecdsa_sig_sign ?
 76 2015-12-29 15:44:04 <sipa> i would not accept that in bitcoin core (way to easy to shoot yourself in the foot), but you're doing it as an experiment, i'll gladly advise
 77 2015-12-29 15:44:41 <arioBarzan> sipa: just for my own personal use
 78 2015-12-29 15:45:07 <sipa> may i ask why?
 79 2015-12-29 15:48:13 <arioBarzan> I have done secp256k1 signing with the help of GNU bc calculator, just to learn the mathematics behind it.
 80 2015-12-29 15:49:48 <arioBarzan> As I understood, the random number is the most important part that people should trust
 81 2015-12-29 15:50:14 <sipa> it doesn't need to be random
 82 2015-12-29 15:50:19 <sipa> just unpredictable
 83 2015-12-29 15:50:40 <sipa> in the current implementation, we follow RFC6979, which computes the nonce deterministically from the message and the private key
 84 2015-12-29 15:57:41 <arioBarzan> sipa: for calculating r = x1 mod n    from   (x1,y1) = k {point multiplication} G
 85 2015-12-29 15:57:53 <arioBarzan> is k the nonce you used?
 86 2015-12-29 15:59:33 <sipa> arioBarzan: that k is computed as a hash of the private key and the message currently
 87 2015-12-29 15:59:42 <sipa> read rfc6979
 88 2015-12-29 16:19:03 <arioBarzan> apparently I need to pass my own noncefp to secp256k1_ecdsa_sign() and that nonce-function should directly deliver exact nonce32 from signrawtransaction. digging a tunnel through signrawtransaction secp256k1_ecdsa_sign() and probably other stuff. hopefully it would be fun ;)
 89 2015-12-29 16:20:12 <sipa> yup, you need your own noncefp
 90 2015-12-29 16:20:32 <sipa> there is one that does this in the tests
 91 2015-12-29 16:20:57 <arioBarzan> sipa: thanks a lot
 92 2015-12-29 16:21:07 <phantomcircuit> sounds like this is going to involve some pretty comical hacks
 93 2015-12-29 16:21:09 <phantomcircuit> :P
 94 2015-12-29 16:23:43 <ceejep> { return 1; }
 95 2015-12-29 16:32:01 <instagibbs> ceejep, looks random to me
 96 2015-12-29 16:32:50 <sipa> 4 would be randomer
 97 2015-12-29 16:33:52 <instagibbs> You predicted 4. It was 1. That's unpredictability right there.
 98 2015-12-29 16:36:44 <arioBarzan> imho it would be worthwhile, since attacking the nonce would be probably the only cyrptographic way of getting hand on key which is used on a secure air-gapped system.
 99 2015-12-29 16:40:49 <arioBarzan> remember geohot's success on PS3 ?
100 2015-12-29 16:41:17 <sipa> arioBarzan: what would 'attacking the nonce' mean?
101 2015-12-29 16:41:24 <sipa> read RFC6979 please
102 2015-12-29 16:48:26 <jl2012> why the nSequence of other inputs are  not signed when using SIGHASH_NONE or SIGHASH_SINGLE?
103 2015-12-29 16:52:32 <arioBarzan> jl2012: because others be able to add their own inputs and outputs with higher nSequence
104 2015-12-29 16:54:42 <arioBarzan> if you sign nSequence, you prevent it from getting updated.
105 2015-12-29 16:57:08 <jl2012> thanks
106 2015-12-29 20:49:08 <toofani> help
107 2015-12-29 20:49:41 <toofani> how to get start with minnig
108 2015-12-29 21:29:22 <t7> wrong channel ?
109 2015-12-29 21:29:31 <t7> #bitcoin