Transcript for #bitcoin-dev 2017/04/27

01:41 mchrosto Trying to build master, Ubuntu 16.04, I've had to compile my own Boost to avoid undefined __cxx11::string references. Looks like I have to do the same for ZMQ. Have I made a mistake somewhere or might it make sense to update the for more recent Ubuntu.
02:15 Rozal So is this vitamin thing bad for bitcoin
10:11 edcba rescan is that slow ??
10:12 edcba oh no ok progress=0.02 means 2% not 0.02% :)
10:12 edcba well it's still not that fast
11:08 czaanja_ Hello, please is there a way to tell bitcoind to store transactions with unconfirmed inputs in the memory pool? For example this transaction . I can see that transaction on, but can not see it with bitcoin-cli getrawtransaction <txid> on my local bitcoin core ( even with with txindex=1 )
11:58 afk11 czaanja_, your node might not have observed it over the p2p network. one reason it mightn't propagate is the awfully low fee paid on that transaction
12:08 edcba fee are required to propagate now ?
12:18 afk11 edcba, he paid 8sat/b, most other txs are paying around 100
12:22 edcba but for propagation you don't really need fee ?
12:22 edcba i mean it may never be mined but still seen by network ?
12:22 edcba mined/validated
12:25 afk11 hmm, actually, it looks like that transaction is also a part of a chain of unconfirmed transactions. it's highly likely that's part of the reason.
12:37 edcba why did i get some btc on old addr ?
12:37 edcba is that part of a privacy attack ?
12:38 czaanja_ afk11: Yes, thanks for the reply, actually I realized it was discovered by my node, but i think i restarted it later, so it wanished from the mempool.
12:39 edcba ok looks like it
12:40 czaanja_ afk11: But some transactions does not really get to my node. Is there any solution to make the chance of geting note of it higher? Raising the connections?
12:48 edcba is your node 24/7 ?
13:34 edcba about merge avoidance, currently if i have 3 addr with 10 10.0001 and .1 COIN, will sending 10.0001 result in picking all from same addr ?
13:41 instagibbs edcba, depends on the coin selection strategy. There are lots of factors. But the smart thing would be to just use the exact-matching one(assuming fees are 0 or included)
13:43 edcba well i mean using latest bitcoin core
13:43 edcba reading SelectCoinsMinConf right now but i'm not sure yet
13:48 instagibbs so the first iteration will assume no fee(hahaha) and do an exact match first
13:48 instagibbs it will then do a fee estimation for that size and try again
13:48 instagibbs will very likely end up picking 2 inputs that suffice
13:50 edcba well my example was with fee included of course lol
13:50 instagibbs ah ok, then it should exact match
13:51 edcba how the fuck there are still a lot of magic values in that source code
14:02 inersha If hard forking wasn't an issue, would it have been a lot easier to fix transaction malleability by ignoring all the scriptSig fields in transactions when creating the TXID?
15:57 czaanja_ edcba: Yes, the node is 24/7. Now for example this transaction I can not see either. I guess it is due to the unconfirmed inputs, since the fee seems to be average.
16:00 abpa Too-long chains aren't allowed
16:18 czaanja_ abpa: So am i getting it right that the transaction is not being re-broadcasted and does not even get to my node? Or it got to my node, but it ignores it?
16:19 abpa Actually it looks like another issue
16:20 abpa These all build on an unconfirmed 3 sat/byte tx
16:20 abpa That won't relay well
16:21 edcba how much time that addr has been reused ?
16:22 edcba 9429 transactions ?
16:23 czaanja_ abpa: So the transaction is not even being relayed and can see it only because it is connected to to huge amount of nodes?
16:23 abpa Probably
16:23 czaanja_ edcba: Which address do you mean?
16:23 abpa Relayed is not a black/white thing
16:23 abpa Many nodes will just ignore super low fee transactions because they don't have space in memory for all of them
16:23 edcba wait i'm lost in blockchain UI
16:24 czaanja_ abpa: Ok, I got this. I am jsut wondering if there is anything I can do about beeing able to know about such a transactions.
16:24 abpa You can rebroadcast yourself and add more fees but then you pay for the entire chain
16:24 edcba
16:25 czaanja_ edcba: Yes I can see that, but I dont know.
16:26 czaanja_ Oh, jsut to make myself clear. I did not made that transaction. Im just wondering how to get known about the transaction.
16:26 edcba so it's a transaction of unconfirmed input * 2 ?
16:27 edcba i wonder if clients retransmit all needed transactions for his addr or just those done by himself
16:27 abpa I think it's just their own ones
16:27 abpa And they will be re-transmitted every x hours
16:28 czaanja_ edcba: Yes it seems to be a chain of unconfirmed transactions as abpa mentioned. And so i see that this might be the reason why I can not see it.
16:28 abpa You can manually re-broadcast someone else's tx
16:28 czaanja_ But anyway thank you guys a lot for your help.
16:28 czaanja_ abpa: Yes I can, but I can not if I am not even notified that some transaction arrived, which is the issue I am having.
17:18 rugu Hey, I am using bitcoin-cli to get the transaction details which shows me the outputs, but now I am not sure how to figure out which UTXOs were actually consumed to produce that transaction. Could someone help me out please?
17:31 arubi rugu, it also shows you the input txids and indexes, so getrawtransaction one of those input txids and at that index you will have the output that was redeemed
17:31 rugu can I see this on a block explorer?
17:32 arubi I don't like the way block explorers show stuff, but I guess you can sort of figure it out from a block explorer, yea
17:32 rugu i am writing a custom script to index UTXOs by address
17:32 rugu I know there are other options, but wanted to do it myself
17:33 arubi okay, I never tried doing that myself
18:08 mappum it has been 20 mins and my email to the mailing list hasn't gone through. does it have to be approved by a moderator first?
18:10 abpa Maybe it was flagged as spam
18:10 mappum nvm, just went through
18:16 arubi mappum, nice :) I'm half way, looks very cool. might be even a bit cheaper with a 0 amount output for the assertion
18:22 mappum arubi: true, but if Output 1 of the Funding tx is 0 amount then it would be nonstandard and not get relayed. and it's small enough not to be a big deal (it could be even smaller, i just couldn't remember what the dust amount was)
18:23 arubi mappum, no outputs is invalid in itself (for the assertion redemption)
18:23 arubi but still, I think there's another issue
18:23 arubi I mean, anyone could just double spend the bounty before it's claimed
18:23 arubi segwit or not
18:23 arubi (err, the signer. not anyone)
18:23 arubi any signer, or contributor
18:24 mappum oh really? wouldn't using CHECKLOCKTIMEVERIFY in the outputs prevent that?
18:25 arubi oh I think I thought you meant using nlocktime for locking it, not cltv. will re-read.
18:25 arubi s/I think//
18:26 mappum the contributor can't spend from the Funding TX until H, and the miner of block H can ensure their bounty payout gets included instead of some other tx signed by the contributor
18:26 mappum the funding tx is broadcast at setup time, the others are locked until H
18:26 arubi I mean, something is a bit off for me, but I might just be confused here. some non segwit output is signed along a segwit one. in case segwit doesn't go through, the signature from the segwit output isn't really important
18:27 mappum since the signature given to the miner uses SIGHASH_ALL, the sig for the non-segwit input is invalid if the segwit input is invalid
18:27 arubi yes but that output is spendable without that segwit sig if it doesn't go through
18:30 arubi again, I might be confused. it's been a long day and I only read your post once. I'll try it out locally and see :)
18:31 mappum i'll double check to make sure i'm understanding the BIP 143 stuff correctly
18:31 arubi cheers, I'll do some more reading here
18:40 mappum crap, i think you're right. the segwit output will be anyone-can-spend, so the non-segwit sig is still valid
18:41 arubi right, seems so
18:41 mappum idk how i missed that :(
18:41 arubi as long as you're frowning, the checksigverify would also fail :(
18:41 arubi use checksig if it's the final op being done. you want a TRUE on stack
18:42 mappum ah, right
18:43 arubi I think it's a cool concept though. it's ironic that with segwit, these kind of clever scripts and transactions would work out of the box
18:44 arubi I mean eventually, when we get an upgrade to sighash :)
19:01 praxeology Did I come here at the right time to witness a meeting?
19:02 arubi looking for #bitcoin-core-dev ?
19:02 arubi it's starting now
19:03 jonasschnelli praxeology: yes. #bitcoin-core-dev
19:03 edcba i didn't know about this one
20:53 mchrosto Hi, I'm trying to compile master on Ubuntu 16.04 and am finding I need to recompile many dependencies to avoid 'defined reference to __cxx11' namespace errors. Does it sound like I missed something or is this expected?
20:53 mchrosto s/defined/undefined
20:58 mchrosto omfg, Ubuntu was grabbing GCC 5.x from while I had 4.x in /usr/local... nevermind