1 2015-09-14 00:13:16 <rusty> kanzure: thanks!
  2 2015-09-14 00:39:14 <Enmx> best bitcoin machine?
  3 2015-09-14 03:39:18 <bedeho> can there be multiple valid signatures for the same transaction ?
  4 2015-09-14 03:46:47 <kanzure> bedeho: http://bitcoin.stackexchange.com/questions/36127/problems-with-deterministic-ecdsa-based-on-rfc6979-in-bitcoin
  5 2015-09-14 03:48:46 <bedeho> kanzure, bah, great, spent all day on failing assert due to changing txid... which I now know is due to resigning creating changing sigs :/
  6 2015-09-14 03:49:16 <dcousens> bedeho: what are you using that doens't use RFC6979?
  7 2015-09-14 03:49:21 <kanzure> why were you checking the txid?
  8 2015-09-14 03:49:33 <kanzure> txid is malleable anyway
  9 2015-09-14 03:53:12 <bedeho> kanzure, both txs are generated client side in a test... was meant as a bug catching assert, but was based on assumption that sigs are deterministic
 10 2015-09-14 03:53:45 <bedeho> dcousens, not sure what underlying signing routine is being used, think its openssl based
 11 2015-09-14 04:19:05 <dcousens> is there any way to make sure the blocks are stored in order?
 12 2015-09-14 04:19:16 <dcousens> (in order of block height)
 13 2015-09-14 04:19:19 <dcousens> on disk, that is
 14 2015-09-14 04:27:25 <maaku> dcousens: sync with earlier bitcoind
 15 2015-09-14 04:27:28 <maaku> run linearize.py
 16 2015-09-14 04:28:07 <dcousens> maaku: and if I've already sync'ed with a new build?
 17 2015-09-14 04:28:12 <dcousens> (aka, latest)
 18 2015-09-14 04:28:27 <dcousens> or did you mean just checkout an earlier build?
 19 2015-09-14 04:28:29 <maaku> run linearize.py and use the resulting bootstrap.dat
 20 2015-09-14 04:36:21 <jgarzik> dcousens, maaku: linearize-*.py
 21 2015-09-14 04:36:42 <jgarzik> dcousens, no need for earlier builds
 22 2015-09-14 04:37:52 <gmaxwell> I am guessing maaku's answer above was intended as an OR. :P
 23 2015-09-14 04:38:27 <maaku> yes, sorry. enumerated two possibilities: sync with pre-headers-first, OR run linearize-*.py and use the resulting output
 24 2015-09-14 04:54:15 <bedeho> can anyone confirm if txids are big endian internally and little endian when displayed in text? or is it other way around? internet is saying contradictory things
 25 2015-09-14 04:54:43 <dcousens> bedeho: they are neither, txIds are just the reversed transaction hash
 26 2015-09-14 04:55:09 <dcousens> SHA256 output is not classified as big-endian or little-endian, if you start making those assertions, you're going to find contradictions everywhere in the core code
 27 2015-09-14 04:55:34 <dcousens> Technically, for consistency,  SHA256 writes out big-endian 4 byte integers in its finalization step
 28 2015-09-14 04:55:40 <dcousens> But, that is for byte order consistency
 29 2015-09-14 04:55:45 <dcousens> Not an actual formalized endianness of the output
 30 2015-09-14 04:56:32 <bedeho> dcousens, ok whatever SHA spits out, this is what appears directly in outpoints?
 31 2015-09-14 04:56:43 <dcousens> yup
 32 2015-09-14 04:56:55 <bedeho> ok, and what is displayed, is reverse of this
 33 2015-09-14 04:57:04 <dcousens> yup
 34 2015-09-14 04:57:42 <bedeho> dcousens, thank you
 35 2015-09-14 04:59:10 <dcousens> bedeho: no worries
 36 2015-09-14 05:00:02 <bedeho> I presume SHA256 format is also what goes into merkle trees and bloom filters also, and same for block ids?
 37 2015-09-14 05:00:17 <dcousens> AFAIK yes
 38 2015-09-14 05:00:31 <dcousens> its only when they are displayed in hex are they reversed
 39 2015-09-14 05:00:35 <dcousens> typically.
 40 2015-09-14 05:04:06 <bedeho> ok, ty
 41 2015-09-14 13:17:52 <jtimon> jonasschnelli: yep, I just don't know where that is yet
 42 2015-09-14 14:36:48 <atgreen> quick question... I'm building bitcoin-core on RHEL7, and it complains at runtime about the lack of EC in the system openssl. Is it not the case that libsecp256k1 replaces the EC routines that were formerly required from openssl?
 43 2015-09-14 14:38:16 <wumpus> atgreen: only for signing at the moment
 44 2015-09-14 14:38:43 <gmaxwell> Perhaps the next release will change that; it's waiting on the libsecp256k1 release.
 45 2015-09-14 14:38:48 <wumpus> libsecp256k1 is not 'cleared' for validation yet, but that will be at some point in the near future
 46 2015-09-14 14:39:08 <atgreen> Ok.  I guess I'll build openssl then.
 47 2015-09-14 14:43:58 <jcorgan> just curious--do you forsee libsecp256k1 in use by other projects besides bitcoin related ones?
 48 2015-09-14 14:46:46 <therealplato1> whats the most authoritative place for bitcoin:// uri scheme spec? has there been any discussion of requesting and verifying signatures under the uri?
 49 2015-09-14 14:48:27 <gmaxwell> jcorgan: it's already being used in other things (though we advise against it!)
 50 2015-09-14 14:48:35 <gmaxwell> (at the moment because we're not released)
 51 2015-09-14 14:49:30 <moa> atgreen: ironically an ssl with secp256k1 support is in the testing pipeline to be released for RH derivatives now
 52 2015-09-14 14:49:53 <moa> look under a "Testing" repo
 53 2015-09-14 14:50:15 <gmaxwell> moa: I suspect he knows.
 54 2015-09-14 14:50:17 <wumpus> therealplato1: BIP20 BIP72
 55 2015-09-14 14:51:06 <jonasschnelli> jcorgan: we just started using libsecp256k1 for a hardware wallet mcu code: https://github.com/digitalbitbox/mcu/pull/62
 56 2015-09-14 14:55:54 <jcorgan> that's great.  but i was thinking more about non-bitcoin specific apps.  i'm not aware of secp256k1 used for anything else, but if one were starting a new project that wanted to incorporate ECDSA, it seems like a good way not to reinvent the wheel (heh, now that libsecp256k1 reinvented it better :-)
 57 2015-09-14 14:59:37 <jonasschnelli> jcorgan: the hardware wallet above has a bitcoin usecase. But it's more a "signing device", you give in a hash with metadata and get back a signature (after a 2fa of the metadata over a smartphone)
 58 2015-09-14 15:03:39 <wumpus> but does anything besides bitcoin/cryptocurrency use the secp256k1 curve?
 59 2015-09-14 15:05:16 <wumpus> I'm not sure in which usecases it is the best choice of a curve for something new
 60 2015-09-14 15:14:29 <gmaxwell> wumpus: none of the trendy curves (e.g. ed25519) have prime order groups; which makes any kind of fancy zero-knoweldge proofs with them problematic (either much harder to make or not obviously possible)
 61 2015-09-14 15:14:48 <gmaxwell> but thats not a libsecp256k1 use argument. But who knows.
 62 2015-09-14 15:16:31 <gmaxwell> libsecp256k1 now has the only available implementation of ec-schonrr multisignature that I'm aware of... when I merge my blind signing module it'll have the only implementation of blind signing. I dunno if we'll ever integrate it as a module but the CT range proofs stuff is the only EC ZKP range proof code that I'm aware of. So even if perhaps people might as well use another curve, they might end up
 63 2015-09-14 15:16:37 <gmaxwell> stuck with libsecp256k1 simply because we've done more stuff than others.
 64 2015-09-14 15:17:21 <gmaxwell> (if one of the newer trendy curves had a prime order group I'd be interested in creating a lib<that thing> but so far no, and I'm not interested in playing the curve drafting game myself :) )
 65 2015-09-14 15:19:33 <moa> could be a fun game to get into
 66 2015-09-14 15:19:36 <wumpus> gmaxwell: that's a good point. I wasn't trying to argue against using secp256k1, I was just wondering
 67 2015-09-14 15:24:02 <gmaxwell> wumpus: yup. I understand. :)  I'm actually frutrated that the trendy stuff isn't strictly superior.
 68 2015-09-14 15:43:14 <atgreen> moa: thanks!  I've already built it, but good to know
 69 2015-09-14 17:22:37 <bad_duck> Hi, I would like to submit an idea to the community (URL scheme for signing / verifying messages), here is a draft I'm planning to send to the bitcoin-dev list -> http://pastebin.com/XtKUEx8q
 70 2015-09-14 17:23:31 <bad_duck> Did I miss something? Should I add something else before sending this?
 71 2015-09-14 18:32:14 <bedeho> in scriptSigs, is the sighash code pushed together with the signature on the stack?
 72 2015-09-14 18:32:59 <gmaxwell> bedeho: it's one push, yes.
 73 2015-09-14 18:33:46 <bedeho> gmaxwell, thanks!
 74 2015-09-14 18:49:35 <gmaxwell> bad_duck: No reason not to post that, though I would currently want to discourage the wider deployment of the 'signmessage' functionality for a couple reasons, including that it doesn't work with multisig.
 75 2015-09-14 18:51:53 <bad_duck> gmaxwell: thx for your feedback
 76 2015-09-14 18:52:48 <gmaxwell> I'd like to propose we spec a new sinmessage which uses script.. though sipa wrote this and we discovered a design challenge.
 77 2015-09-14 18:56:31 <bad_duck> it could be nice to have multisig "signmessage" features..
 78 2015-09-14 19:06:50 <gmaxwell> bad_duck: I agree, just haven't figured out the design challenge. :(  Perhaps pieter should open the script-signing as a PR on bitcoin core to get more ideas.
 79 2015-09-14 19:09:37 <sipa> Duly noted.
 80 2015-09-14 19:11:17 <GAit> nice, i had many people asking for support for that
 81 2015-09-14 19:17:05 <gmaxwell> https://github.com/ElementsProject/elements/pull/49 is the prior attempt.
 82 2015-09-14 19:18:12 <bad_duck> I sent my email about my sign url scheme, feel free do comment on the mailing list or on bitcointalk -> https://bitcointalk.org/index.php?topic=1180572.0 , thx!
 83 2015-09-14 21:51:11 <bsm1175321> Sipa's version bits didn't get assigned a BIP number yet, did it? https://gist.github.com/sipa/bf69659f43e763540550
 84 2015-09-14 22:00:54 <gmaxwell> bsm1175321: it hasn't requested one. It's still being drafted.
 85 2015-09-14 22:09:31 <jtimon> cfields: could you comment on https://github.com/bitcoin/bitcoin/pull/6672#commitcomment-13223254 ?
 86 2015-09-14 22:09:48 <cfields> jtimon: thinking on it
 87 2015-09-14 22:09:55 <jtimon> ok, sorry
 88 2015-09-14 22:10:02 <dcousens> jtimon: I'm guessing 6672 was just a consolidation of all those similar PRs?
 89 2015-09-14 22:10:58 <jtimon> dcousens: yes, plus I got many reviewers in the same room so hopefully it can be merged soon
 90 2015-09-14 22:11:15 <dcousens> same room?
 91 2015-09-14 22:11:33 <dcousens> (Montreal?)
 92 2015-09-14 22:11:36 <jtimon> little hackaton after the scaling bitcoin conference
 93 2015-09-14 22:11:38 <jtimon> yep
 94 2015-09-14 22:12:32 <jtimon> dcousens: #6654 is also being extensively reviewed
 95 2015-09-14 22:12:59 <dcousens> ok, jtimon i'll read through it now
 96 2015-09-14 22:59:17 <dcousens> jtimon: the doc blocks padded line is a standard used throughout hte codebas
 97 2015-09-14 22:59:20 <dcousens> the codebase*
 98 2015-09-14 22:59:46 <dcousens> It makes it easier to see blocks
 99 2015-09-14 22:59:51 <dcousens> Rather than just 1 contiguous piece of code
100 2015-09-14 23:03:31 <jtimon> dcousens: this "standard" is not documented in the style guide and it's not followed in many places (for example, main.h)
101 2015-09-14 23:03:54 <dcousens> jtimon: I only opened 3-4 files before I said that,  maybe my sample size was too small
102 2015-09-14 23:04:29 <dcousens> even in main.h, its pretty consistently there except for the 1 liners
103 2015-09-14 23:04:48 <dcousens> I'd say its 50/50 in that file, with a higher prevalance in other files
104 2015-09-14 23:06:14 <jtimon> we should document this if it's part of the style (unfortunately I don't think clang-format can enforce it)
105 2015-09-14 23:06:48 <dcousens> jtimon: maybe just be consistent with what is already in the file
106 2015-09-14 23:07:02 <dcousens> jtimon: i've lost the PR link, but, I'll leave that up to you
107 2015-09-14 23:07:07 <dcousens> its a nit anyway
108 2015-09-14 23:07:41 <jtimon> not opposing to it, but some people are already verifying the move-only commit and I would prefer not to modify the hash of the commit unless I need to for some other reason
109 2015-09-14 23:08:08 <jtimon> well, there's not much in consensus/consensus.h before this PR...
110 2015-09-14 23:08:22 <dcousens> :thumbs_up:, just mention that, the inconsistencies and that at some point we should unify it
111 2015-09-14 23:08:34 <dcousens> its not relevant to your PR if its inconsistent elsewhere
112 2015-09-14 23:09:06 <jtimon> ok, I'll copy this conversation into the PR for future reference
113 2015-09-14 23:10:03 <dcousens> on another topic, it'd be great if you could quickly diff between rebases
114 2015-09-14 23:10:35 <dcousens> I guess all I'd have to do is grab the commits and run the normal github diff, right?
115 2015-09-14 23:11:05 <dcousens> haha, jtimon that conversation reads backwards
116 2015-09-14 23:11:30 <dcousens> because we both reference each other,  it reads like I'm you, and you're me etc
117 2015-09-14 23:11:40 <jtimon> dcousens: solved, markdown hides the names betwee <>, just added a space in every name
118 2015-09-14 23:34:39 <dcousens> jtimon: so how goes the hack-room
119 2015-09-14 23:34:55 <jtimon> we're actually wrapping up
120 2015-09-14 23:35:05 <jtimon> we have to leave the room :(
121 2015-09-14 23:35:34 <dcousens> naw, should make a note to allow for that at the next conference
122 2015-09-14 23:35:50 <dcousens> (HK)