1 2016-10-17 20:34:01 <DanielMycelium> just for better understanding, what might be the reason that a testnet3 segwit transaction does not get mined quickly? i made one ~8h ago and its still in some mempools, but some blockexplorer dont find it at all.
 2 2016-10-17 20:34:58 <achow101> it could be the recently merged policy stuff that is preventing the transaction from being confirmed
 3 2016-10-17 20:35:33 <DanielMycelium> my understanding is, it is non-standard but valid for nodes <v0.13 (=>thus it wont get mined, but a block with it would be valid), and its standard and valid for >=v0.13 (they would mine it) --> does that mean, nobody is mining with v0.13 on testnet?
 4 2016-10-17 20:36:35 <achow101> no, it is possible that people are actually mining with 0.13.1rc1 (which was just tagged, so not actually released) and that introduced several new policy limits.
 5 2016-10-17 20:37:13 <DanielMycelium> @achow101, i thought segwit was activated on testnet long ago (block-wise)
 6 2016-10-17 20:37:59 <moli> DanielMycelium, it should , try broadcast it again
 7 2016-10-17 20:38:18 <achow101> it was. There were several local node policy changes that were recently implemented which may have (probably has) been deployed on testnet now
 8 2016-10-17 20:38:29 <achow101> these don't affect consensus rules but rather what the node accepts into the mempool
 9 2016-10-17 20:38:29 <Lightsword> I’ve been doing most of the segwit mining on testnet and I’ve been using master
10 2016-10-17 20:38:32 <DanielMycelium> i have broadcasted it with a well connected node (two different actually, and via https://testnet.smartbit.com.au )
11 2016-10-17 20:38:33 <achow101> see https://github.com/bitcoin/bitcoin/pull/8499
12 2016-10-17 20:51:47 <moli> i just sent a segwit tx and it got confirmed:  https://testnet.smartbit.com.au/tx/6673d16c8786471cdafcb95253a7f5ac751da6a8fff8db15ba6c7a2f2da5e316
13 2016-10-17 21:26:58 <moli> mega Segwit block on Testnet a few min ago:  tps://testnet.smartbit.com.au/block/0000000000000cc29b9d00ad0b5497a2be3aa00f3e93405f4e017a5ed4aaba70
14 2016-10-17 21:28:28 <Lightsword> moli, yeah that’s one I mined
15 2016-10-17 21:28:54 <moli> Lightsword, thank you :)
16 2016-10-17 22:08:18 <murch> It seems that I've just found a Coin Selection algorithm that has the UTXO footprint of Core, and costs less fees than HighestPriority. It does that by creating 40% direct matches.
17 2016-10-17 22:11:11 <murch> If I introduce an additional random element, it actually quarters the UTXO footprint of Core, and still has a lower cost than any approach I've presented
18 2016-10-17 22:11:42 <murch> And it's _fast_ in comparison. :)
19 2016-10-17 22:43:22 <instagibbs> murch, feel free to elaborate :)
20 2016-10-17 22:44:04 <murch> instagibbs: Well, I was thinking about how Core has all these steps to create Direct Matches, but in my simulation only manages 0.5% Direct Matches.
21 2016-10-17 22:45:39 <murch> instagibbs: So, I figured that I could try a depth-first-search on the UTXO set. I step down each UTXO by selecting or not selecting it.
22 2016-10-17 22:46:35 <murch> Since I know how much an input will cost, I can just tally up "effectiveValue" by reducing the UTXO value by the cost of spending it. That way, when I find a match, I immediately have also figured out the fee.
23 2016-10-17 22:47:39 <murch> I figured, I can broaden the "direct match range" by the cost of one input and one output, because the change output must first be created and then later spent. So as long as I don't exceed that cost, I'll still save money by finding a direct match.
24 2016-10-17 22:48:03 <murch> Anyway, it turns out that doing a DFS on the UTXO set is much smaller than the knapsack thing we have currently in Core.
25 2016-10-17 22:48:59 <murch> And by pruning search branches when they exceed target + one input + one output, it actually becomes a fairly small search path.
26 2016-10-17 22:51:16 <murch> instagibbs: So, it's kinda deterministic, but on the other hand any observers would usually not know what my UTXO pool is anyway.
27 2016-10-17 22:53:01 <murch> As a fall-back, if I don't find a direct match with the DFS, I just select randomly.
28 2016-10-17 22:53:53 <murch> instagibbs: And the whole thing is about 60 lines of code including finding a sufficient fee. :)
29 2016-10-17 22:53:54 <instagibbs> Not sure I totally get it (I'll wait for a more involved description) but I imagine there are ways of reintroducing some cheap randomness for privacy
30 2016-10-17 22:54:04 <instagibbs> or code even
31 2016-10-17 22:55:28 <murch> instagibbs: I've also tried it on the shuffled UTXO pool. Still does about 20% direct matches, and only slightly reduces the cost. It reduces the UTXO footprint to about a fourth of what Core achieved on the set.
32 2016-10-17 22:55:49 <murch> *increases the cost
33 2016-10-17 22:57:52 <instagibbs> why does a "structured" utxo pool increase direct matches?
34 2016-10-17 23:00:19 <murch> instagibbs: I've set a limit on the DFS as otherwise it would sometimes take multiple seconds.
35 2016-10-17 23:00:23 <murch> instagibbs: https://github.com/Xekyo/CoinSelectionSimulator/blob/fe3f6ad2e882ac68cbc122bc4813ebc5996ef105/src/BnBWallet.scala#L11
36 2016-10-17 23:05:18 <murch> sorry, I just hacked that down this evening, so it's maybe not the easiest to access.
37 2016-10-17 23:13:10 <instagibbs> ah ok, got it
38 2016-10-17 23:19:13 <murch> instagibbs: https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml ← Results of five trials in comparison to the results I presented at Scaling Bitcoin.
39 2016-10-17 23:21:14 <murch> Anyway, finally I can say something more sophisticated than "just try random selection". ;)