1 2016-10-26 01:21:00 <denisx> hi, I see very strange things with 0.13.1 regarding ipv6
2 2016-10-26 01:21:09 <denisx> connect() to [b197:c656:100::]:0 failed
3 2016-10-26 01:21:27 <denisx> alot of strange addresses, always with 100 in the end
4 2016-10-26 01:21:49 <denisx> sometimes I see: connect() to [100::2001:610:600:a41]:0 failed: Can't assign requested address
5 2016-10-26 01:21:57 <denisx> with the 100 in the beginning
6 2016-10-26 01:22:09 <denisx> also connect() to [ffa5:2957:100::]:0 failed: Address family not supported by protocol family
7 2016-10-26 03:13:40 <frankenmint> maybe this is for naught but, i really need some help right now
8 2016-10-26 03:14:28 <frankenmint> how do I rebroadcast a transaction with a higher fee in bitcoin core- I need to delete the unconfirmed first transaction as well
9 2016-10-26 04:37:09 <achow101> frankenmint: abandontransaction rpc or right click the transaction and select "abandon transaction" (only for 0.13.0+). Then send another transaction
10 2016-10-26 04:37:46 <frankenmint> alright, thanks!, I figured out that this transaction from bitcoin core did go through so Im sorta sol
11 2016-10-26 14:30:53 <Bitcoin-24> will 13.1 fix the transaction queue problem?
12 2016-10-26 14:36:34 <jonasschnelli> Bitcoin-24: transaction queue problem? Can you be more specific?
13 2016-10-26 14:37:08 <Bitcoin-24> maybe it's better to ask if the blocksize will increase
14 2016-10-26 14:40:50 <jonasschnelli> Bitcoin-24: 0.13.1 includes the segwith softfork which solves different issues and increases indirectly the capacity (blocksize): https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase
15 2016-10-26 14:41:03 <jonasschnelli> s/segwith/segwit/
16 2016-10-26 14:41:49 <Bitcoin-24> thanks, thats what I asked for ;)
17 2016-10-26 16:59:02 <killerstorm> hi. bitcoind returns bad block data, have anyone seen something like that?
18 2016-10-26 17:00:36 <killerstorm> it looks like some extra bytes were prepended to transactions
19 2016-10-26 17:04:05 <killerstorm> and it's not some random glitch, I got exactly the same data after erasing data and syncing again
20 2016-10-26 17:09:12 <arubi> killerstorm, example..?
21 2016-10-26 17:09:43 <arubi> I mean.. I'm sure you realize what would happen if bitcoind suddenly started returning bad block data..
22 2016-10-26 17:12:35 <killerstorm> I got this for block 00000000000b5fd5fcada419cfa41f2d2dbbd0b74ba594edb2877f693bd328db on the testnet. first line is correct block, third is incorrect. http://pastebin.com/Nv863Fx4
23 2016-10-26 17:14:09 <killerstorm> I suspect it might be a problem with my system, but it's weird that no problems are reported and it just keeps going forward.
24 2016-10-26 17:15:57 <arubi> ah I forgot my testnet node was down, which version are you running? where is the "correct" data from?
25 2016-10-26 17:16:22 <arubi> it's starting, but will take a couple minutes or so
26 2016-10-26 17:18:51 <killerstorm> 0.13.0 Linux 64 bit. correct data is from another node run by another person.
27 2016-10-26 17:18:53 <arubi> looks like line 3 has segwit data and line 1 doesn't, at least from eyeballing it
28 2016-10-26 17:19:23 <arubi> pretty sure you'll need 0.13.1* for segwit data
29 2016-10-26 17:21:20 <arubi> well now I remember, I need to reindex testnet :\ , can't run my own node, but I'm almost positive that that's what's happening here
30 2016-10-26 17:22:16 <arubi> so killerstorm, all seems to be fine. upgrade your node and you'll get segwit data in blocks
31 2016-10-26 17:23:19 <killerstorm> hmm, so the format of data returned by getblock is changed?
32 2016-10-26 17:23:37 <killerstorm> the particular problem I'm having is that bitcore-lib cannot parse that block
33 2016-10-26 17:23:43 <arubi> line 3?
34 2016-10-26 17:23:53 <killerstorm> yes
35 2016-10-26 17:24:24 <arubi> I don't know if bitcore supports segwit or not
36 2016-10-26 17:24:45 <arubi> https://github.com/bitpay/bitcore-lib/issues/49 I guess it's here
37 2016-10-26 17:24:49 <killerstorm> well it doesn't, but I thought segwit is backwards-compatible to some extent
38 2016-10-26 17:25:43 <arubi> you can't expect old software to parse new data
39 2016-10-26 17:25:57 <arubi> give it the block from your node, it'll be the same transactions and everything
40 2016-10-26 17:26:06 <arubi> just without the witness data like scripts, signatures
41 2016-10-26 17:26:21 <killerstorm> I thought getblock will return block data without witness data
42 2016-10-26 17:26:39 <arubi> that would be quite annoying for all who do support segwit though :)
43 2016-10-26 17:28:02 <arubi> also seems like they have a segwit branch in their repo, might wanna give that a try. I gotta go afk for a bit
44 2016-10-26 17:41:28 <killerstorm> I don't see how it would be annoying to use another RPC call, say getblocksegwit, in new software
45 2016-10-26 17:41:44 <killerstorm> if getblock returns data in new format, existing software will just halt
46 2016-10-26 17:41:51 <killerstorm> after bitcoind update
47 2016-10-26 17:52:28 <arubi> having a new rpc call for the same functionality /would/ be non backwards compatible. you can continue using 0.13.0 for how long you want to using current non segwit bitcore-lib
48 2016-10-26 17:52:36 <arubi> you're not losing any security
49 2016-10-26 17:55:52 <killerstorm> I'm using 0.13.0 and the problem already exists with testnet
50 2016-10-26 17:56:22 <killerstorm> it silently returns data in different format and library just barfs during parsing. worst way to handle this, IMHO. but whatever. I'll downgrade to 0.12.1
51 2016-10-26 17:57:11 <arubi> I don't understand what's failing for you. if you use your 0.13.0 node, why does it return data in different formats?
52 2016-10-26 17:58:09 <arubi> or are both you and your friend querying the same bitcore-lib?
53 2016-10-26 17:59:26 <arubi> I mean, bitcore-lib already has an active branch, you're going to need to update it eventually
54 2016-10-26 18:03:26 <killerstorm> 0.13.0 already returns this new format on testnet.
55 2016-10-26 18:04:35 <arubi> ah, why not pull bitcore-lib segwit branch then?
56 2016-10-26 18:04:51 <arubi> it's going to end up in a release anyway
57 2016-10-26 18:10:45 <killerstorm> I'd rather wait for it to get stable, I have no immediate need for segwit stuff.
58 2016-10-26 18:11:21 <arubi> ah I see, well that's also an option
59 2016-10-26 20:35:46 <jcarter9753> Hi, would anyone mind helping me clarify BIP 0141, protocol definition of Witness TX?
60 2016-10-26 20:36:10 <jcarter9753> Sorry - BIP 0144 https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
61 2016-10-26 20:36:35 <jcarter9753> It says "The number of script witnesses is not explicitly encoded as it is implied by txin_count."
62 2016-10-26 20:36:40 <jcarter9753> Is this incorrect or am I missing something?
63 2016-10-26 20:38:32 <jcarter9753> My script processor fails if the Script is OP_FALSE <20 bytes> and no PubKey and Signature are provided in the Witness as expected, but it takes a VarInt at the start of the Script_Witness block after the Outputs, which the docs say should not be there?
64 2016-10-26 20:39:17 <jcarter9753> if (asWitness) { var witnessCount = stream.ReadVarInt(); for (int i = 0; i < witnessCount; i++) { var witnessLength = (int)stream.ReadVarInt(); tx.Inputs[i].WitnessScript = new byte[witnessLength]; stream.Read(tx.Inputs[i].WitnessScript, 0, witnessLength); } }
65 2016-10-26 20:39:21 <jcarter9753> oops, formatting
66 2016-10-26 20:40:40 <jcarter9753> Is there anyone in the channel that has implemented segwit in their clients?
67 2016-10-26 20:46:31 <jcarter9753> Is there anyone in the channel that has implemented segwit in their clients?
68 2016-10-26 20:48:20 <jcarter9753> Is there anyone who is thinking about implementing segwit, considering it will soon be live?
69 2016-10-26 20:51:18 <murch> You could try talking to jl2012
70 2016-10-26 20:51:21 <murch> or sipa
71 2016-10-26 20:51:41 <jcarter9753> Thanks, do they visit here frequently?
72 2016-10-26 20:51:50 <murch> no clue
73 2016-10-26 20:52:04 <murch> sorry
74 2016-10-26 20:52:19 <jcarter9753> Ok thanks for your response
75 2016-10-26 20:52:20 <murch> jl2012 appears to be in the channel, but I don't know whether he is afk
76 2016-10-26 20:52:45 <jcarter9753> I will wait and see if he pops up at some point.
77 2016-10-26 20:52:57 <murch> I'm sure you've already seen https://bitcoincore.org/en/segwit_wallet_dev/
78 2016-10-26 20:54:15 <jcarter9753> I have not - I will give that a read thanks. Generally the BIP documents are good enough to get going, but in this case I think the BIP is incorrect.
79 2016-10-26 20:55:15 <jcarter9753> I have run through all the Script Tests in the json file in the core github repo and they all pass, just the networking side is giving me some trouble for some reason
80 2016-10-26 20:55:24 <murch> okay, yeah well I think jl2012 is one of the principal authors of SegWit
81 2016-10-26 20:55:41 <jcarter9753> I will bear that in mind - thanks for your support
82 2016-10-26 20:55:55 <murch> sure
83 2016-10-26 21:03:07 <arubi> jcarter9753, if a segwit txo is being redeemed, then having no witness fields for each of the inputs is invalid encoding
84 2016-10-26 21:03:58 <arubi> all inputs should have a witness, 0x00 for non segwit inputs and the actual 0x<num> and stack for segwits
85 2016-10-26 21:08:26 <jcarter9753> Thanks arubi that is what I thought, but is there a VarInt at the start of that block?
86 2016-10-26 21:08:54 <arubi> yep, it says how many in the stack for that input's witness
87 2016-10-26 21:09:26 <jcarter9753> I mean [VarInt:HowManyWitnessScripts] [VarInt:StackSize] [The witness stack items] [VarInt:StackSize] [The witness stack items]
88 2016-10-26 21:09:41 <jcarter9753> Or does it not have that initial VarInt?
89 2016-10-26 21:09:51 <arubi> oh no, that's implied by the # of inputs
90 2016-10-26 21:10:05 <arubi> the number of VarInt:HowManyWitnessScripts is how many inputs
91 2016-10-26 21:10:19 <arubi> er, "VarInt:HowManyWitnessScript"'s
92 2016-10-26 21:10:53 <arubi> I'll rephrase
93 2016-10-26 21:10:53 <jcarter9753> Okay, so when we read the stack items we are not given the whole byte array of the stack items?
94 2016-10-26 21:11:50 <arubi> [VarInt:HowManyWitnessScripts] <- doesn't exist
95 2016-10-26 21:11:56 <jcarter9753> Understood
96 2016-10-26 21:12:16 <arubi> right as many VarInt:StackSize as inputs, your second question I don't understand
97 2016-10-26 21:12:33 <arubi> you're reading one stack item at a time
98 2016-10-26 21:12:47 <arubi> each has it's own size, and there are as many as varint:stacksize
99 2016-10-26 21:12:47 <jcarter9753> Thats where I've gone wrong then. I assumed each Input had a Witness Script which was a Script in the Bitcoin sense of the word, that created a Stack, like the Sig Script
100 2016-10-26 21:13:20 <jcarter9753> That is exactly what it does have, but because we are not given the whole size of the array we cannot just parse that whole Script
101 2016-10-26 21:13:45 <arubi> that's right
102 2016-10-26 21:13:54 <arubi> but I do like it better that way :)
103 2016-10-26 21:14:28 <jcarter9753> So do I! Less processing on the network side. Anyway, perhaps I will add more tests to the script_tests.json in bitcoin core as all the tests pass with in current implementation =/
104 2016-10-26 21:14:45 <jcarter9753> but the blocks do not process past 873033
105 2016-10-26 21:15:10 <arubi> is that when sw activated?
106 2016-10-26 21:15:12 <jcarter9753> I think I will pop the items, and store them locally as a standard Bitcoin script
107 2016-10-26 21:15:20 <jcarter9753> No, 834624
108 2016-10-26 21:15:46 <arubi> well I don't know about that ^. I think the beauty here is that it's much easier to "nest" stuff now
109 2016-10-26 21:16:18 <arubi> a stack item doesn't have to "relate" to other items in that witness
110 2016-10-26 21:16:30 <jcarter9753> ok, I will pop the items off and store them in a Bitcoin script format
111 2016-10-26 21:16:53 <jcarter9753> I don't understand, they are placed on the Stack when the script runs?
112 2016-10-26 21:17:47 <arubi> yea that's correct, I'm trying to explain what I mean
113 2016-10-26 21:19:24 <arubi> jcarter9753, I think you got it right there. I can't think of a way to explain what I mean. yes it's fine to read the items in there to a stack like normal script is run
114 2016-10-26 21:20:07 <arubi> be prepared for the scripts being run to get more complex, so these things in the witness might not just end up as pubkeys and sigs
115 2016-10-26 21:20:23 <jcarter9753> Okay - Just realised why my tests are passing, they don't actually do any Serialization/Deserialization, the tests construct a Transaction on the fly and populate the data from the json file. I must be creating the test wrong.
116 2016-10-26 21:20:38 <jcarter9753> Yep I have considered that when creating the Program Types
117 2016-10-26 21:20:44 <jcarter9753> P2WPKH etc
118 2016-10-26 21:21:20 <arubi> post segwit, there are new fields in the json for decoderawtransaction
119 2016-10-26 21:22:31 <jcarter9753> I am only using https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json
120 2016-10-26 21:22:56 <arubi> oh I see, so what's failing exactly?
121 2016-10-26 21:23:09 <arubi> rather, what's passing when it shouldn't?
122 2016-10-26 21:24:05 <jcarter9753> My test was set up correctly, but when I was deserializing the Tx from the network, I was assuming it was formatted differently, our above discussion.
123 2016-10-26 21:24:11 <jcarter9753> Looks like it is running again now.
124 2016-10-26 21:24:43 <arubi> ah okay, got lost in that code paste
125 2016-10-26 21:24:45 <jcarter9753> I will reset back to the block just before segwit activates and run through again.
126 2016-10-26 21:25:42 <jcarter9753> Thank you very much for your help, I did not want to get into segwit being BIP9:Started without having it implemented
127 2016-10-26 21:25:54 <arubi> welcome jcarter9753