1 2017-12-26 02:51:28 <vinnix> https://gist.github.com/vinnix/dd6eea7ce5d938c752166d3faebd7663 (bitcoind running with valgrind result)
2 2017-12-26 07:29:27 <weiyang> And I replace the 127.0.0.1 with an address found on https://bitnodes.earn.com/nodes/?q=Satoshi:0.15.1, but prompt to input password. Hmm⦠I am not sure what should I do next
3 2017-12-26 07:29:27 <weiyang> I am trying to use curl for experience the rpc method. Not sure which user/password should I try.
4 2017-12-26 07:29:27 <weiyang> the command I found looks like this: curl --user user --data-binary â{âjsonrpcâ: â1.0", âidâ:âcurltestâ, âmethodâ: âgetinfoâ, âparamsâ: [] }â -H âcontent-type: text/plain;â http://127.0.0.1:8332/
5 2017-12-26 07:41:53 <DSidH> question re. segwit: "For receiving payments, the wallet must be able to create a P2SH address based on a P2WPKH script (defined hereinafter), and be able to recognize payment to such addresses."
6 2017-12-26 07:41:57 <DSidH> from the docs.
7 2017-12-26 07:42:14 <DSidH> what does it mean "able to recognize payment to such addresses." ?
8 2017-12-26 07:58:50 <arubi> able to watch the p2sh scriptpubkey for incoming payments and then solve the p2sh and p2wpkh to redeem
9 2017-12-26 07:59:26 <arubi> a lot of wallets watch just one script type for a pubkey. core watches a bunch by default and can be taught to watch more
10 2017-12-26 12:16:09 <vinnix> it seems like leveldb has some memory leaks
11 2017-12-26 12:16:53 <vinnix> at least that is what I am observing when using "-reindex" (after reindexed and reading again all blocks)
12 2017-12-26 12:17:14 <vinnix> https://gist.github.com/vinnix/dd6eea7ce5d938c752166d3faebd7663 (bitcoind running with valgrind result)
13 2017-12-26 19:00:46 <DSidH> arubi "a lot of wallets watch just one script type for a pubkey. core watches a bunch by default and can be taught to watch more"
14 2017-12-26 19:01:44 <DSidH> that would make sense if the only payment it expects is of that script type. So each wallet should watch for payments to all addresses it owns
15 2017-12-26 19:36:46 <DSidH> arubi nvm I understand, someone can send to my P2PKH address once he knows my public key without me ever giving them the address, so I need to watch all address types
16 2017-12-26 19:40:56 <arubi> ah just caught the highlight. it all depends on how many scriptpubkey programs the wallet can solve by itself right
17 2017-12-26 19:42:40 <arubi> so yes knowledge of a bare pubkey allows some person to send you coins to whichever script, but mostly you'll watch the standard scripts. core can pick up on bare scriptpubkeys where it knows the private key, so something like a 1-of-1 multisig with a pubkey of your would be picked up
18 2017-12-26 19:43:54 <arubi> maybe it can pick up on multisigs with more keys if it knows privkeys for all pubkeys used, actually I haven't tried
19 2017-12-26 19:45:00 <arubi> basically you wouldn't expect someone to just randomly pay an address or script you didn't specifically give out to them, but knowing to watch for and solve the scripts is quite useful
20 2017-12-26 20:05:08 <buffalobill33> If I want to write a bitcoin payment system for a site, what is the best way of doing it? Should I write my own wrapper for bitcoin RPC calls?
21 2017-12-26 20:07:23 <arubi> you could. just generate a huge keypool in the wallet first then call getnewaddress for payment addresses
22 2017-12-26 20:07:56 <arubi> but it's not easily used for multiple customers without more tools, maybe for donation addresses that's enough
23 2017-12-26 20:08:35 <buffalobill33> what would be the suggested way of designing such a system? One that could scale to say tens of thousands of users easily
24 2017-12-26 20:09:04 <arubi> not sure, sounds out of my reach
25 2017-12-26 20:09:22 <arubi> I mean, it sounds like a full fledged enterprise product right
26 2017-12-26 20:14:17 <buffalobill33> The end product would be. The reason I ask is because experienced bitcoin developers with availability are hard to find, and I'm wondering how difficult it would be to develop the experience myself
27 2017-12-26 20:16:41 <Randolf> buffalobill33: Well, you'll obviously need a good database to keep track of your users, and excellent security practices for handling passwords, 2FA, etc. Fortunately there are many high quality, free, and open source databases you could use (e.g., PostgreSQL.org is my favourite).
28 2017-12-26 20:17:44 <Randolf> buffalobill33: You'd also need someone to develop the software for you. There are many options, and you can combine multiple languages together, but it would be smart to choose a language that your web server software has good support for (e.g., with Apache HTTPd there's mod_perl2, Python, Java
29 2017-12-26 20:17:44 <Randolf> Server Pages, PHP, etc.).
30 2017-12-26 20:18:29 <Randolf> buffalobill33: I agree with arubi that you'd be developing something in the realm of a full-fledged enterprise product.
31 2017-12-26 20:18:53 <Randolf> buffalobill33: If I were to embark on such a project, I would hire a team of good developers to build it in-house.
32 2017-12-26 20:19:26 <arubi> and these are just the things that you'll need for just any major online service. add cryptocurrency to that and you have all the issues that come with that
33 2017-12-26 20:20:12 <arubi> mostly you'll see that no matter what technology services build on, they always end up getting hacked or lose a bunch of coins somehow
34 2017-12-26 20:20:47 <buffalobill33> Randolf: I have most of the backend developed (rails with postgres) with security features such as 2FA, tokens etc in addition to distributed locks and rabbitmq as a messaging system. I am looking to get people to help me develop the bitcoin functionality and want to get a rough idea of how much work needs to be done and how difficult it is conceptually
35 2017-12-26 20:23:24 <buffalobill33> I plan on having a full third-party security audit at the end. How difficult is it for an experience programmer with a reasonably good conceptual knowledge of bitcoin to develop a backend api to process payments securely?
36 2017-12-26 20:24:40 <arubi> maybe look into btcpay, it's software for transaction clearance
37 2017-12-26 20:26:37 <arubi> many different results on google, https://github.com/btcpayserver/btcpayserver is what I mean
38 2017-12-26 20:26:49 <buffalobill33> thanks, having a look now
39 2017-12-26 20:30:19 <DSidH> [01:13] <arubi> maybe it can pick up on multisigs with more keys if it knows privkeys for all pubkeys used, actually I haven't tried
40 2017-12-26 20:30:50 <DSidH> Hmmm I dont think its possible because core would need to know all pub keys used in the script.. else it won't know
41 2017-12-26 20:30:58 <buffalobill33> Right now I have an experience blockchain dev with a small team offering to build a btc and ethereum payment processing backend for $70k. Is this a reasonable price? How long would such a project normally take a team to do
42 2017-12-26 20:31:16 <DSidH> oops u said all
43 2017-12-26 20:31:21 <DSidH> I read some :P
44 2017-12-26 20:32:05 <echeveria> buffalobill33: if you're asking that question, you clearly haven't evaluated the risks in handling other people's money.
45 2017-12-26 20:32:36 <buffalobill33> echeveria: can you clarify that please?
46 2017-12-26 20:32:48 <DSidH> would core be able to handle say a million watch only addresses?
47 2017-12-26 20:35:03 <echeveria> buffalobill33: you asked for an evaluation of cost for a system that handles other people's money, you should be able to answer that.
48 2017-12-26 20:35:25 <echeveria> DSidH: it's not designed for that. many things in the wallet are inefficient.
49 2017-12-26 20:39:01 <buffalobill33> echeveria: I don't know enough about the specifics of how a bitcoin node works to answer it correctly. I guess to rephrase the question: does it take 700 hours billable at $100/hour to write a btc payment processor which can send, receive and notify of incoming payments? The rest of the logic (coin selection, address tracking etc) will be written be a separate team.
50 2017-12-26 20:39:01 <DSidH> echeveria: I see, so best would be to use bitcoind to get blocks and parse them myself
51 2017-12-26 20:40:27 <DSidH> Can someone help in understanding the test vectors at https://bitcoin.stackexchange.com/a/22881/2075 ? The private key hex seems to be much larger (38 bytes)
52 2017-12-26 20:41:35 <DSidH> what encoding is the private key? Example: 79186670301299046436858412936420417076660923359050732094116068951337164773779
53 2017-12-26 20:41:46 <echeveria> .. integer.
54 2017-12-26 20:41:51 <arubi> it seems to be in decimals?
55 2017-12-26 20:41:57 <DSidH> is it just int? But its much larger than 256 bits
56 2017-12-26 20:42:30 <DSidH> also the op says "Private as hex "
57 2017-12-26 20:42:34 <arubi> ;;calc log(77359564092138606367423909782286964438584967790833203478204963256314910737690)/log(2)
58 2017-12-26 20:42:35 <gribble> 255.418114877
59 2017-12-26 20:42:52 <arubi> ;;calc log(23984934282846201135004307705980641080962872643161302353166056218330425914143)/log(2)
60 2017-12-26 20:42:52 <gribble> 253.728663698
61 2017-12-26 20:43:00 <arubi> all fine :)
62 2017-12-26 20:43:39 <DSidH> oh ok so he says hex but its not
63 2017-12-26 20:43:58 <echeveria> buffalobill33: I was saying that's a problem in itself. if you're handling other people's money you need to be able to independently evaluate that.
64 2017-12-26 20:44:19 <DSidH> thx. stupid thing, should have spotted myself.
65 2017-12-26 20:45:46 <DSidH> all tests pass.. so vectors are good
66 2017-12-26 20:45:52 <DSidH> these are some edge cases
67 2017-12-26 20:45:57 <arubi> nice
68 2017-12-26 21:02:40 <arubi> ohh I just noticed you're doing recoverable sigs DSidH
69 2017-12-26 21:03:50 <arubi> DSidH, https://gist.github.com/fivepiece/4b5a026c6f74a47162fe1198e19838ee
70 2017-12-26 21:05:51 <DSidH> arubi: which signatures are you referring to? In this post? https://bitcoin.stackexchange.com/a/22881/2075
71 2017-12-26 21:05:53 <arubi> there are usually 2 pubkeys and 4 addresses recoverable per signature, and sometimes it can be 4 pubkeys and 8 addresses, but only if the "signer" sets it on purpose :)
72 2017-12-26 21:06:12 <arubi> yea
73 2017-12-26 21:07:43 <DSidH> ok thats some other user but this is interesting fact
74 2017-12-26 21:08:06 <arubi> ah I see you were just using the numbers to test your output
75 2017-12-26 21:08:15 <DSidH> (s)he is not using deterministic ECDSA as the sigs dont match mine
76 2017-12-26 21:08:19 <DSidH> yup
77 2017-12-26 21:08:50 <DSidH> [02:35] <arubi> there are usually 2 pubkeys and 4 addresses recoverable per signature, and sometimes it can be 4 pubkeys and 8 addresses, but only if the "signer" sets it on purpose :)
78 2017-12-26 21:08:58 <DSidH> please give some more references/details
79 2017-12-26 21:09:17 <DSidH> key recovery is complex topic so I am not sure I'll get it
80 2017-12-26 21:09:53 <DSidH> How do I know they are recoverable sigs?
81 2017-12-26 21:09:54 <arubi> in core there's a feature called "signmessage"
82 2017-12-26 21:10:18 <arubi> where you sign some text message and send the verifier your address and that message
83 2017-12-26 21:10:32 <DSidH> yup but I could never find documentation of this
84 2017-12-26 21:10:50 <DSidH> what encoding does it use?
85 2017-12-26 21:10:59 <arubi> there are very good comments about it in libsecp256k1
86 2017-12-26 21:11:21 <arubi> the encoding is just r and s as 32 bytes, and the recid byte encoded as in my paste, but it's not so simple
87 2017-12-26 21:11:21 <DSidH> ok let me read. I assumed its simply DER encoded as in tx
88 2017-12-26 21:11:36 <arubi> oh no, this one is much more fun :)
89 2017-12-26 21:11:50 <echeveria> bitcoin doesn't really use DER anymore.
90 2017-12-26 21:12:34 <arubi> it's all over the signatures
91 2017-12-26 21:12:38 <arubi> err, transactions
92 2017-12-26 21:13:05 <arubi> it doesn't use anything else in transactions.. yet. hopefully soon we'll just have 64 bytes constant length..
93 2017-12-26 21:13:05 <echeveria> the format is far more restricted than DER
94 2017-12-26 21:13:14 <arubi> oh yes, that's true.
95 2017-12-26 21:13:55 <echeveria> DER allows unclear amounts of recursion, has dependancies on the underlying CPU integer sizes, all sorts of crazy you don't want.
96 2017-12-26 21:14:24 <arubi> cool, in fact I don't want DER at all :)
97 2017-12-26 21:14:34 <DSidH> arubi: does the "sign message" feature also use RFC6979?
98 2017-12-26 21:14:41 <arubi> yep
99 2017-12-26 21:15:21 <echeveria> I was more surprised to learn that there was more acceptable formats for public keys in bitcoin than 04,03,02.
100 2017-12-26 21:15:34 <arubi> but the message hash is something you'll need to implement too. there is a header added, varints for lengths of the header and message..
101 2017-12-26 21:15:44 <arubi> oh yea, the all elusive hybrid keys
102 2017-12-26 21:15:59 <echeveria> there's supposedly one in testnet.
103 2017-12-26 21:16:42 <arubi> would be cool if there's one on mainnet hiding behind p2pkh heh :)
104 2017-12-26 21:38:23 <DSidH> arubi: can you please point me to the github link for the source code with comments for "sign message". I want to replicate those signatures (claimed to be from core)
105 2017-12-26 22:00:56 <arubi> DSidH, for signmessage message format it's in bitcoin core repo and for recoverable signatures it's in the libsecp256k1 repo. I gotta go to sleep so can't search for it now, but probably tomorrow :)
106 2017-12-26 22:01:03 <arubi> /night
107 2017-12-26 22:01:23 <DSidH> no worries I found some links referring to magic bytes
108 2017-12-26 22:01:30 <DSidH> I'll try those in the meantime
109 2017-12-26 22:41:35 <DSidH> How do I use recoverable signatures? do I just send the signature and the address, using which the receiver can decide the right key?
110 2017-12-26 23:49:44 <spectra> |Satoshi wanted us to increase the block size
111 2017-12-26 23:50:02 <spectra> |many of the core developers sold out to Block Stream are the ones who vote against it
112 2017-12-26 23:51:27 <spectra> |the lightning network will inevitably lead to centralized hubs with large liquity which whom we open accounts - banks