Transcript for #bitcoin-dev 2017/04/29

15:36 rugu Hey, I can't seem to find the RPC call that lets me view the pending transactions. Once I broadcast a transaction, before it gets mined, what call will let me view all of them?
15:55 aantonop anyone familiar with BIP-134 (flexible transactions)?
15:56 goatpig can't tell if serious o.o
15:56 aantonop me? yes serious
15:57 aantonop Trying to understand the SIGHASH_SINGLE quadratic hashing "issue" and also find out something about the proposed deployment of BIP-134
16:03 goatpig the BIP says HF so that much they going for
16:03 aantonop it can only be a HF deployment, right? I don't see anyway it could be otherwise...
16:04 aantonop goatpig: thanks!
16:05 goatpig well it's a bit ambigious
16:06 goatpig the format is not backwards compatible since it overrides op_codes for its "tokens" system instead
16:06 goatpig FT transactions have to signal 4 in their tx version though
16:06 aantonop would a non-upraded client ignore v4 Tx?
16:06 goatpig they are non standard afaik but not ignored
16:07 goatpig but you could SF now to ignore v4
16:07 goatpig and then SF FT maybe a year or 2 down the road when the majority of the network has moved to that previous SF
16:07 goatpig which isn't an SF actually, just a client side upgrade
16:07 aantonop ah, I see thanks
16:08 goatpig basically it's a HF that does not deprecate the old tx format
16:08 goatpig which is... ok i guess?
16:08 goatpig if you're going out of your way to preserve the legacy format, SF makes more sense
16:09 goatpig as for the quadratic hashing, i see now mention of it in the bip
16:09 goatpig there is a vague description of what gets hashed
16:09 goatpig but the bip just refers to the implementation
16:09 goatpig and i'd have to read the code to tell you what's going on on that front
16:09 aantonop The quadratic hashing issue was brought up by Russel Oconnor on the mailing list today
16:10 aantonop I read the BIP and found not much to understand. Tried to read some code to see what Russel was talking about
16:10 aantonop Was not able to understand the issue
16:10 aantonop Also, was wondering how the SIGHASH SINGLE is different in Core, such that it doesn't have this issue?
16:11 goatpig it does afaik
16:11 aantonop Meaning, is it a design/architecture issue, or simply an implementation issue i
16:11 goatpig the quadratic hash usually hinges on the what gets hashed
16:12 goatpig point being, if you have to compute a new hash per input/sig, you're gonna run into that issue
16:12 goatpig if you look at their description in FT
16:13 goatpig the input script gets hashed per sig hash
16:13 goatpig in SW you get a midstate hash
16:13 goatpig it doesn't sound like there is a midstate to reuse in FT
16:13 aantonop yes, but it's purely an implementation decision - meaning that it doesn't matter how you do the hash, as long as it commits the right data and everyone does it the same. So why would Flex-trans have implemented it in a quadratic-order algo?
16:13 goatpig you have to rehash the whole thing per tx im guessing?
16:14 aantonop I see, so it's more like re-imlementing the legacy problem and not learning from Segwit's fix...
16:14 goatpig SW goes out of its way to produce a mid state
16:15 goatpig at first glance, looks like FT just uses the old approach to sighash
16:15 goatpig create a binary blob per input
16:15 goatpig hash and sign
16:15 aantonop ok, I get it now
16:15 aantonop Thank you for the help!
16:15 goatpig don't quite me on this i have no read their code =D
16:16 goatpig but the midstate part is a bit obvious once you implement SW support
16:16 goatpig and im guessing from their wording they missed that part in FT
17:24 arubi I think it's because in case sighash single is used, this is done: , then eventually : , where for other hash type it seems to stay the same size (but not the same sizes)
17:25 arubi flextrans is... bleh.. who knows what's going on in there
17:27 arubi it really seems like there's 0 innovation in there, except for wanting us all to use some shitty xml copycat
19:37 jonasschnelli goatpig:
19:37 jonasschnelli (for you) :)
19:40 goatpig hah tanks
21:06 cncr04s there seems to be a bug with sendmany, in some cases, it will not send change to a change address, instead it opts to include it with the transaction fee
21:06 cncr04s 0.039708 in my case
21:30 goatpig maybe it considers the change left over is too small on its own to be spendable
21:30 goatpig and burns it as fee instead
23:48 cncr04s it decided to burn 0.039708 btc?
23:56 cncr04s I don't know what to do but build transactions myself, seems odd that bitcoind can't reliably do this on its own.