1 2016-01-27 00:31:00 <Chris_Stewart_5> Luke-Jr: How is '' interpreted by Bitcoin core? For example this test case '' 1 IF SHA1 ENDIF
  2 2016-01-27 00:32:20 <kadoban> Chris_Stewart_5: It's an empty push I believe, like PUSHDATA1 0, which pushes an item on the stack with no content
  3 2016-01-27 01:13:05 <cluelessperson> Question, under "Keys and BIP32"  it describes:
  4 2016-01-27 01:13:07 <cluelessperson> If someone has access to a private wallet key P, of course they have access to all descendent wallet keys of P. But if they also have access to a public wallet key K where P is a subkey of K, you can actually work your way up the tree to determine the private key that corresponds to the public wallet key K
  5 2016-01-27 01:14:09 <cluelessperson> So if you have a child public key, and a parent public key,   you can determine the parent's private key?
  6 2016-01-27 01:14:16 <cluelessperson> Is that what I'm understanding here?
  7 2016-01-27 01:14:44 <gmaxwell> that incorrect. If you have an extended public key, and any private key in the tree, you can derrive the rest of the private keys.
  8 2016-01-27 01:15:05 <cluelessperson> https://github.com/richardkiss/pycoin
  9 2016-01-27 01:15:32 <cluelessperson> gmaxwell,   Any private key from the tree?
 10 2016-01-27 01:15:53 <cluelessperson> gmaxwell, What's the definition of "extended public key" you just used?
 11 2016-01-27 01:20:13 <cluelessperson> That language is confusing and unclear, I feel.
 12 2016-01-27 01:25:00 <cluelessperson> http://i.imgur.com/bRYgmhe.png
 13 2016-01-27 02:04:12 <AdrianG> what is the reason some bitwise logic op codes are disabled? (xor/and/or)
 14 2016-01-27 02:11:45 <gmaxwell> AdrianG: because they had remotely exploitable vulnerabilities.
 15 2016-01-27 04:10:14 <arioBarzan> one question regarding this statement:
 16 2016-01-27 04:10:17 <arioBarzan> "Transaction replacement was introduced by Satoshi in the first release of the Bitcoin software, but later removed due to denial-of-service problems. Opt-in RBF solves this issue by requiring transaction replacements to pay a higher fee."
 17 2016-01-27 04:11:33 <denisx> hmm, any changes in sendtoaddress in 0.12.0.
 18 2016-01-27 04:11:42 <denisx> my script is now throwing “Invalid amount”
 19 2016-01-27 04:12:06 <arioBarzan> if such transaction is still unconfirmed, so there would be zero fee paid. how would that prevent DOS problem?
 20 2016-01-27 04:15:14 <arioBarzan> it seams that Opt-in RBF transactions could still cause DOS problem for mempool database.
 21 2016-01-27 04:21:22 <phantomcircuit> denisx, the json parser was switched to univalue which strictly enforces correctness of the values
 22 2016-01-27 04:21:39 <phantomcircuit> typically you get that error because you're sending more than 8 places after the decimal
 23 2016-01-27 04:22:06 <phantomcircuit> arioBarzan, the fee being paid by the transaction is encoded in the transaction...
 24 2016-01-27 04:22:11 <denisx> phantomcircuit: ok, thanks. that could be it
 25 2016-01-27 04:26:28 <arioBarzan> phantomcircuit: obviously. but the fee payment is not confirmed while transaction itself is not confirmed. the attacker still could send thousands of versions of one transactions, and increase the fee by minimum required for each consecutive one.
 26 2016-01-27 04:28:32 <arioBarzan> eventually he pays some fee, but that transaction consumes significant bandwidth and validation resources up until confirmation.
 27 2016-01-27 04:35:19 <maaku> arioBarzan: but each one had to increase the fee. eventually you run out of coins
 28 2016-01-27 04:35:39 <moli> if he keeps doing that, wouldn't miners know those tx's are spams and just ignore them?
 29 2016-01-27 04:36:21 <denisx> phantomcircuit: thanks, that was it. is this in the readme of 0.12.0?
 30 2016-01-27 11:06:07 <zbbix> Does core relay orphan transactions to other nodes?
 31 2016-01-27 11:06:56 <phantomcircuit> zbbix, no
 32 2016-01-27 11:07:48 <zbbix> phantomcircuit: Yesterday there was a pretty massive attack where the attacker relayed lots of orphan txs to my node. I thought this was only my node but after talking to other node operators I saw that they are experiencing the same behavior
 33 2016-01-27 11:08:12 <zbbix> phantomcircuit: if they are not relayed, how does the attacker achieves this? Is his node connected to multiple nodes and therefore I'm not the only one suffering from this?
 34 2016-01-27 11:08:35 <wumpus> probably connects to lots of nodes then blasts to all of them
 35 2016-01-27 11:09:01 <phantomcircuit> zbbix, there's a huge about of garbage in various nodes mempools from the spam attack thing
 36 2016-01-27 11:09:12 <phantomcircuit> the transactions pay a very very small fee
 37 2016-01-27 11:09:30 <phantomcircuit> which means they are not and will likely never be mined
 38 2016-01-27 11:09:46 <zbbix> OK but if a tx spends a utxo that is not known to my client it's considered an orphan tx. Why does core even store these?
 39 2016-01-27 11:09:48 <wumpus> note that *former* orphan transactions are relayed as soon as their dependencies are satisfied in the mempool
 40 2016-01-27 11:09:50 <phantomcircuit> so until more people move to 0.12 with mempool limiting you can expect to randomly get hit with a bunch of garbage
 41 2016-01-27 11:10:57 <gmaxwell> zbbix: "why does it store"  because transactions can arrive out of order.
 42 2016-01-27 11:11:04 <phantomcircuit> zbbix, it keeps... 100? something like that around in memory if you're seeing lots of memory usage then it means the missing dependencies are being fulfilled in later transactions
 43 2016-01-27 11:11:06 <wumpus> zbbix: it stores a limited number of them, to aid when transactions are somehow broadcasted out of order
 44 2016-01-27 11:11:23 <zbbix> I understand, thanks a lot for the answers.
 45 2016-01-27 11:11:26 <wumpus> zbbix: the limit is fairly small so it shouldn't be a problem in memory use compared to say, the mempool
 46 2016-01-27 11:12:03 <gmaxwell> I was working on some changes to the trickle logic that largely would have eliminated most out of order transactions but ran out of time before 0.12. ... the way nodes currently behave, in my view, is kind of dumb and result in poor propagation for chains of unconfirmed txn.
 47 2016-01-27 11:12:15 <gmaxwell> (because they get set out of order and the orphan pool is so small they just end up lost)
 48 2016-01-27 11:13:00 <zbbix> Is there a mechanism for nodes to 'blacklist' another node? Are they relaying that blacklist to other nodes?
 49 2016-01-27 11:13:30 <gmaxwell> Why do you ask?
 50 2016-01-27 11:14:02 <zbbix> I'm asking because if there is a mechanism to blacklist a node, why wasn't that spamming node was blacklisted by my node?
 51 2016-01-27 11:14:05 <wumpus> yes, nodes can ban other nodes, you can do so manually using setban... and no, that's a strictly personal list
 52 2016-01-27 11:14:09 <gmaxwell> Nodes will ban peers that misbehave in a subset of clear, fairly inexcusable ways. The baning is not transitive to other nodes.
 53 2016-01-27 11:14:55 <zbbix> Does that mechanism currently takes into consideration that sort of attacks of orphan txs?
 54 2016-01-27 11:14:56 <gmaxwell> Currently the software doesn't ban things for behavior which a node could honestly perform-- e.g. sending you transactions which you don't know the parents for.
 55 2016-01-27 11:15:21 <zbbix> maybe adding some limits can benefit, not sure if that's feasible.
 56 2016-01-27 11:15:58 <zbbix> something like, ban peer if it sent over 100 orphan txs in the past minute
 57 2016-01-27 11:16:24 <wumpus> the problem is that that it shouldn't be possible to exploit it to break up the network or isolate nodes
 58 2016-01-27 11:16:44 <wumpus> so automatic banning has to be really carefully considered
 59 2016-01-27 11:16:52 <zbbix> I understand
 60 2016-01-27 11:19:32 <wumpus> using setban and some other RPC plumbing you can implement your own banning policies as external script, then there is only a risk of isolating yourself if you do it wrong
 61 2016-01-27 11:21:08 <zbbix> Interesting suggestion wumpus, I'll have a look.
 62 2016-01-27 15:06:30 <Chris_Stewart_5> Does an OP_RETURN stop script execution once it is encountered?
 63 2016-01-27 15:07:31 <instagibbs> it immediately fails
 64 2016-01-27 15:08:32 <instagibbs> Chris_Stewart_5, you can do quick checks in src/scripts/interpreter.cpp
 65 2016-01-27 15:13:14 <Chris_Stewart_5> stacktop(-1) is popping off the stack right?
 66 2016-01-27 15:13:51 <Chris_Stewart_5> or is that just indexing into the stack, not popping anything?
 67 2016-01-27 15:19:43 <Chris_Stewart_5> trying to figure out how OP_IFS and OP_ELSES are matched with this https://gist.github.com/Christewart/381dc1dbbb07e62501c3
 68 2016-01-27 15:20:08 <Chris_Stewart_5> using identations to represent the OP_IF & OP_ELSES that match
 69 2016-01-27 15:21:58 <thermoman> block pruning is still not compatible with running a wallet, right?
 70 2016-01-27 15:59:00 <xabbix> How do I define multiple debug categories in core? for example, alert and mempool? tried using alert,mempool but it didn't work :(
 71 2016-01-27 16:04:06 <helo> xabbix: try -debug=alert -debug=mempool
 72 2016-01-27 16:04:55 <xabbix> helo: Thanks, I'll try.
 73 2016-01-27 16:06:57 <wumpus> thermoman: in 0.12 it is
 74 2016-01-27 16:18:47 <wumpus> thermoman: see https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md#wallet-pruning
 75 2016-01-27 19:04:28 <tobyirc> All, I've been working on a PR/BIP would love to get more feedback on it.
 76 2016-01-27 19:04:34 <tobyirc> There have been plenty of comments around the use of OP_RETURN, but I'd like to hear some non-OP_RETURN related feedback if anyone has some:
 77 2016-01-27 19:04:39 <tobyirc> https://github.com/bitcoin/bitcoin/pull/7376
 78 2016-01-27 19:08:34 <tobyirc> BIP Draft: https://gist.github.com/toby/9e71811d387923a71a53
 79 2016-01-27 19:19:59 <gijensen> tobyirc, what kind of feedback are you looking for? The PR and BIP seem to more-or-less revolve around OP_RETURN
 80 2016-01-27 19:20:41 <tobyirc> gijensen well, I'm happy to hear even more feedback on OP_RETURN I'd also like to get more in to vetting the Specification
 81 2016-01-27 19:21:00 <tobyirc> if the changes proposed to BIP70 make sense, don't break anything...
 82 2016-01-27 19:35:22 <Luke-Jr> cheaper spam = breaking something
 83 2016-01-27 19:36:01 <tobyirc> Luke-Jr as we've covered, we have very different definitions of spam :)
 84 2016-01-27 19:38:54 <gijensen> I don't really understand why you want to remove the ability to burn via RBF.
 85 2016-01-27 19:39:51 <gijensen> s/RBF/OP_RETURN
 86 2016-01-27 19:40:02 <gijensen> Dunno where my head's at
 87 2016-01-27 19:40:48 <tobyirc> I think a case could totally be made for allowing the burning to ensure backward compatibility but my main case is that zero value OP_RETURNs should be supported in Payment requests
 88 2016-01-27 19:41:03 <tobyirc> they're supported outside of payment requests
 89 2016-01-27 19:41:34 <Luke-Jr> they're not supported, merely tolerated.
 90 2016-01-27 19:41:58 <tobyirc> in my mind that's not how software works :)
 91 2016-01-27 19:42:01 <tobyirc> it either works or it doesn't
 92 2016-01-27 19:42:07 <Luke-Jr> I wonder if that should change. I'm not sure there's a reason to tolerate it with zero-value now that we have dust rules..
 93 2016-01-27 19:42:32 <tobyirc> I actually think disallowing zero value OP_RETURN every would be a better solution
 94 2016-01-27 19:42:34 <tobyirc> since it's consistent
 95 2016-01-27 19:42:42 <tobyirc> even though it's not good for me :)
 96 2016-01-27 19:43:11 <gijensen> I'm on the fence on how I feel about allowing 0 or enforcing a burn. I don't want enforced 0 though.
 97 2016-01-27 19:43:11 <Luke-Jr> maybe we should require a normal value on OP_RETURN unless it's somehow identified as Counterparty or something
 98 2016-01-27 19:43:15 <tobyirc> I'm genuinely curious about your position though, 40 bytes of data is almost nothing
 99 2016-01-27 19:43:37 <tobyirc> gijensen very interesting, and exactly the kind of feedback I was looking for
100 2016-01-27 19:43:59 <Luke-Jr> tobyirc: I wonder if you might be just as well with a pay-to-contract
101 2016-01-27 19:44:09 <gijensen> :)
102 2016-01-27 19:44:38 <Luke-Jr> tobyirc: have you looked into https://github.com/Blockstream/contracthashtool ?
103 2016-01-27 19:45:06 <tobyirc> I had been thinking about something like that
104 2016-01-27 19:45:36 <tobyirc> it's an interesting idea, but if I understand correctly you could match the address to a hash value if you have it but the hash itself isn't stored on the blockchain?
105 2016-01-27 19:46:45 <Luke-Jr> tobyirc: that's kindof inherent to what a hash does..
106 2016-01-27 19:46:50 <Luke-Jr> you need the input data, period.
107 2016-01-27 19:47:12 <Luke-Jr> so one extra step of turning it into address form is no difference
108 2016-01-27 19:47:39 <tobyirc> right, but the address is itself a hash so the has I want is plain text so to speak
109 2016-01-27 19:48:06 <tobyirc> it may not always be a hash
110 2016-01-27 19:48:16 <tobyirc> I had also thought about a user registration system that works like this
111 2016-01-27 19:48:22 <tobyirc> username stored in plain text OP_RETURN
112 2016-01-27 19:48:34 <tobyirc> whoever is controlling the server defines the fee to register the name
113 2016-01-27 19:49:17 <tobyirc> Luke-Jr something I totally agree with you about is not serializing data to the blockchain. I'm always talking about pointers (hashes, names...) that need to be associated with a monetary transaction
114 2016-01-27 19:52:58 <maaku> I'm getting ZMQ build errors on Ubuntu 15.10 from the latest 0.12 stable branch:
115 2016-01-27 19:52:58 <maaku> (other related errors)
116 2016-01-27 19:52:58 <maaku> zmq/zmqnotificationinterface.cpp:15:73: error: ‘zmq_strerror’ was not declared in this scope
117 2016-01-27 19:53:29 <Luke-Jr> maaku: ZMQ 4.x?
118 2016-01-27 19:55:43 <Luke-Jr> (note that ZMQ breaks compatibility quite often, sometimes in subtle ways that only show up in the form of "random" network disconnections)
119 2016-01-27 20:17:54 <Lightsword> Luke-Jr, I’m seeing submitblock responses of {"error": null, "result": null, "id": null} on segnet, is this a proper response?
120 2016-01-27 20:18:11 <Lightsword> not sure if it’s a generic 0.12 issue or segwit specific
121 2016-01-27 20:18:36 <Lightsword> note that that’s the response I’m getting for a valid submission
122 2016-01-27 20:21:24 <denisx> is the stricter json checking also true for submitblock?
123 2016-01-27 20:22:17 <Luke-Jr> Lightsword: that's a successful response.. see the BIP
124 2016-01-27 20:22:34 <Luke-Jr> https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki#Block_Submission
125 2016-01-27 20:22:41 <Luke-Jr> This method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.
126 2016-01-27 20:25:18 <Lightsword> Luke-Jr, it seems to have changed from a reasponse of true to null though for the “result” key
127 2016-01-27 20:25:33 <Luke-Jr> Lightsword: no, true would have always been invalid
128 2016-01-27 20:27:19 <Lightsword> Luke-Jr, this isn’t for shares this is for blocks though, does that make a difference?
129 2016-01-27 20:28:38 <Luke-Jr> Lightsword: same thing
130 2016-01-27 20:28:54 <Luke-Jr> blocks are just shares on the main chain
131 2016-01-27 20:34:40 <Lightsword> Luke-Jr, so ckpool has been checking for “result” being set to true and has worked fine on mainnet with 0.11.2 it seems, are you sure it didn’t change?
132 2016-01-27 20:36:12 <Lightsword> https://bitbucket.org/ckolivas/ckpool/src/aee476272183ac9531d40d4abbfd1b5c59e6d911/src/bitcoin.c?at=master&fileviewer=file-view-default#bitcoin.c-408
133 2016-01-27 20:39:16 <denisx> Lightsword: is there a problem with 0.12.0 and ckpool?
134 2016-01-27 20:40:19 <Lightsword> denisx, there’s a regression somewhere when sipa’s segwit tree(0.12.0 based) with ckpool master
135 2016-01-27 20:41:52 <Lightsword> I get [2016-01-27 10:35:16.573] SUBMIT BLOCK GOT NO RESPONSE!
136 2016-01-27 20:41:58 <Lightsword> and then [2016-01-27 10:35:16.573] Submitted, but had block 16705 rejected
137 2016-01-27 20:42:04 <wallet42> tbtc.blockr.io is behind :(
138 2016-01-27 21:36:08 <mnk> maybe it is a dumb question and the answer is no, but i am not sure: would it be theoretically possible to implement PoS in bitcoin?
139 2016-01-27 21:36:41 <mnk> found answer in #bitcoin
140 2016-01-27 23:40:40 <Guest52239> s
141 2016-01-27 23:40:43 <Guest52239> helo
142 2016-01-27 23:40:57 <Guest52239> where can i buy shingles medication for my wife with bitcoins
143 2016-01-27 23:41:15 <Guest99986> #bitcoin-otc
144 2016-01-27 23:41:36 <Guest52239> thank you
145 2016-01-27 23:44:28 <Guest52239> hi
146 2016-01-27 23:44:31 <Guest52239> no one is there
147 2016-01-27 23:50:33 <brand0> most specific troll ever