1 2017-04-29 15:36:56 <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?
 2 2017-04-29 15:55:30 <aantonop> anyone familiar with BIP-134 (flexible transactions)?
 3 2017-04-29 15:56:14 <goatpig> can't tell if serious o.o
 4 2017-04-29 15:56:52 <aantonop> me? yes serious
 5 2017-04-29 15:57:46 <aantonop> Trying to understand the SIGHASH_SINGLE quadratic hashing "issue" and also find out something about the proposed deployment of BIP-134
 6 2017-04-29 16:03:33 <goatpig> the BIP says HF so that much they going for
 7 2017-04-29 16:03:56 <aantonop> it can only be a HF deployment, right? I don't see anyway it could be otherwise...
 8 2017-04-29 16:04:10 <aantonop> goatpig: thanks!
 9 2017-04-29 16:05:41 <goatpig> well it's a bit ambigious
10 2017-04-29 16:06:04 <goatpig> the format is not backwards compatible since it overrides op_codes for its "tokens" system instead
11 2017-04-29 16:06:22 <goatpig> FT transactions have to signal 4 in their tx version though
12 2017-04-29 16:06:46 <aantonop> would a non-upraded client ignore v4 Tx?
13 2017-04-29 16:06:56 <goatpig> they are non standard afaik but not ignored
14 2017-04-29 16:07:04 <goatpig> but you could SF now to ignore v4
15 2017-04-29 16:07:32 <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 2017-04-29 16:07:39 <goatpig> which isn't an SF actually, just a client side upgrade
17 2017-04-29 16:07:57 <aantonop> ah, I see thanks
18 2017-04-29 16:08:18 <goatpig> basically it's a HF that does not deprecate the old tx format
19 2017-04-29 16:08:37 <goatpig> which is... ok i guess?
20 2017-04-29 16:08:47 <goatpig> if you're going out of your way to preserve the legacy format, SF makes more sense
21 2017-04-29 16:09:01 <goatpig> as for the quadratic hashing, i see now mention of it in the bip
22 2017-04-29 16:09:08 <goatpig> there is a vague description of what gets hashed
23 2017-04-29 16:09:14 <goatpig> but the bip just refers to the implementation
24 2017-04-29 16:09:24 <goatpig> and i'd have to read the code to tell you what's going on on that front
25 2017-04-29 16:09:38 <aantonop> The quadratic hashing issue was brought up by Russel Oconnor on the mailing list today
26 2017-04-29 16:10:09 <aantonop> I read the BIP and found not much to understand. Tried to read some code to see what Russel was talking about
27 2017-04-29 16:10:18 <aantonop> Was not able to understand the issue
28 2017-04-29 16:10:44 <aantonop> Also, was wondering how the SIGHASH SINGLE is different in Core, such that it doesn't have this issue?
29 2017-04-29 16:11:05 <goatpig> it does afaik
30 2017-04-29 16:11:06 <aantonop> Meaning, is it a design/architecture issue, or simply an implementation issue i
31 2017-04-29 16:11:30 <goatpig> the quadratic hash usually hinges on the what gets hashed
32 2017-04-29 16:12:01 <goatpig> point being, if you have to compute a new hash per input/sig, you're gonna run into that issue
33 2017-04-29 16:12:58 <goatpig> if you look at their description in FT
34 2017-04-29 16:13:06 <goatpig> the input script gets hashed per sig hash
35 2017-04-29 16:13:13 <goatpig> in SW you get a midstate hash
36 2017-04-29 16:13:22 <goatpig> it doesn't sound like there is a midstate to reuse in FT
37 2017-04-29 16:13:29 <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?
38 2017-04-29 16:13:33 <goatpig> you have to rehash the whole thing per tx im guessing?
39 2017-04-29 16:14:03 <aantonop> I see, so it's more like re-imlementing the legacy problem and not learning from Segwit's fix...
40 2017-04-29 16:14:20 <goatpig> SW goes out of its way to produce a mid state
41 2017-04-29 16:15:21 <goatpig> at first glance, looks like FT just uses the old approach to sighash
42 2017-04-29 16:15:27 <goatpig> create a binary blob per input
43 2017-04-29 16:15:29 <goatpig> hash and sign
44 2017-04-29 16:15:42 <aantonop> ok, I get it now
45 2017-04-29 16:15:46 <aantonop> Thank you for the help!
46 2017-04-29 16:15:52 <goatpig> don't quite me on this i have no read their code =D
47 2017-04-29 16:16:26 <goatpig> but the midstate part is a bit obvious once you implement SW support
48 2017-04-29 16:16:33 <goatpig> and im guessing from their wording they missed that part in FT
49 2017-04-29 17:24:17 <arubi> I think it's because in case sighash single is used, this is done: https://github.com/bitcoinclassic/bitcoinclassic/blob/9c688c6d3866890f16a36aaea453e8bdd43c1266/src/script/interpreter.cpp#L1126 , then eventually : https://github.com/zander/bitcoinclassic/blob/9c688c6d3866890f16a36aaea453e8bdd43c1266/src/primitives/transaction.h#L276 , where for other hash type it seems to stay the same size (but not the same sizes)
50 2017-04-29 17:25:22 <arubi> flextrans is... bleh.. who knows what's going on in there
51 2017-04-29 17:27:16 <arubi> it really seems like there's 0 innovation in there, except for wanting us all to use some shitty xml copycat
52 2017-04-29 19:37:22 <jonasschnelli> goatpig: https://bitcoin.stackexchange.com/questions/53047/cant-remove-unconfirmed-transaction
53 2017-04-29 19:37:27 <jonasschnelli> (for you) :)
54 2017-04-29 19:40:00 <goatpig> hah tanks
55 2017-04-29 21:06:20 <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
56 2017-04-29 21:06:53 <cncr04s> 0.039708 in my case
57 2017-04-29 21:30:22 <goatpig> maybe it considers the change left over is too small on its own to be spendable
58 2017-04-29 21:30:26 <goatpig> and burns it as fee instead
59 2017-04-29 23:48:59 <cncr04s> it decided to burn 0.039708 btc?
60 2017-04-29 23:56:27 <cncr04s> I don't know what to do but build transactions myself, seems odd that bitcoind can't reliably do this on its own.