< gmaxwell> seeing a lot of non-final txn
< GitHub74> [bitcoin] laanwj opened pull request #8227: tests: Try re-enabling RPC tests for Windows (master...2016_05_win_reenable_rpc_tests) https://github.com/bitcoin/bitcoin/pull/8227
< GitHub38> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a072d1a83787...223bf831cc81
< GitHub38> bitcoin/master 7734479 Will Binns: readme: Omit phrasing; 'new'...
< GitHub38> bitcoin/master 223bf83 Wladimir J. van der Laan: Merge #8224: readme: Omit phrasing; 'new'...
< GitHub45> [bitcoin] laanwj closed pull request #8224: readme: Omit phrasing; 'new' (master...binns-update-readme) https://github.com/bitcoin/bitcoin/pull/8224
<@wumpus> jonasschnelli: ok!
< GitHub138> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/223bf831cc81...377d1310acc7
< GitHub138> bitcoin/master 9e3ec74 Nathaniel Mahieu: Clarify documentation for running a tor node...
< GitHub138> bitcoin/master 377d131 Wladimir J. van der Laan: Merge #8203: Clarify documentation for running a tor node...
< GitHub27> [bitcoin] laanwj closed pull request #8203: Clarify documentation for running a tor node (master...master) https://github.com/bitcoin/bitcoin/pull/8203
< GitHub79> bitcoin/master 1b0bcc5 Pieter Wuille: Track orphan by prev COutPoint rather than prev hash
< GitHub79> bitcoin/master db0ffe8 Gregory Maxwell: This eliminates the primary leak that causes the orphan map to...
< GitHub79> bitcoin/master 11cc143 Gregory Maxwell: Adds an expiration time for orphan tx....
< GitHub70> [bitcoin] laanwj closed pull request #8179: Evict orphans which are included or precluded by accepted blocks. (master...reap_orphans) https://github.com/bitcoin/bitcoin/pull/8179
<@wumpus> what are we going to do for RBF in 0.13?
< btcdrak> wasnt jonasschnelli going to simplify his patch?
<@wumpus> or the bumpfee command https://github.com/bitcoin/bitcoin/pull/7865
< GitHub43> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/94ab58b5ccda...1f86d64f6d87
< GitHub43> bitcoin/master ad0752e Pieter Wuille: Stop trimming when mapTx is empty
< GitHub43> bitcoin/master 1f86d64 Wladimir J. van der Laan: Merge #8220: Stop trimming when mapTx is empty...
< GitHub160> [bitcoin] laanwj closed pull request #8220: Stop trimming when mapTx is empty (master...notrimempty) https://github.com/bitcoin/bitcoin/pull/8220
<@wumpus> or what about importmulti: https://github.com/bitcoin/bitcoin/pull/7551 ? also still has the 0.13 milestone, and pedrobranco did a lot of work on it the last week
<@wumpus> nah probably just too late
<@wumpus> kind of unfortunate the things that almost made it into 0.13, on the other hand, at least 0.14 will have some useful featurs
< instagibbs> I assume there's a function to parse unsigned char array into hex string in Core? Can't think of it at the moment.
< sipa> yes, it's called ParseHex :)
< sipa> in utilstrencodings
< sipa> wumpus: agree, importmulti is late
< sipa> too bad :(
< instagibbs> ParseHex goes hex str to bytes
< instagibbs> I need the opposite :P
< instagibbs> ill look around there though
< Chris_Stewart_5> instagibbs: Possibly some where around here? https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L510
< instagibbs> HexStr maybe
< sipa> HexStr indeed
< instagibbs> thanks
< sipa> instagibbs: i wouldn't call that parsing, though :)
< sipa> but that's a semantics discussion
< instagibbs> eh true enough
< pedrobranco> wumpus: yes, unfortunately i was late in importmulti :(
< pedrobranco> will need some help in adding some features, and how importmulti should work in some situations
< pedrobranco> look forward to finish the importmulti :)
< jonasschnelli> wumpus: btcdrak: I have plans to split the bumpfee PR into two parts (one to add opt-in feature to CreateTransaction() another for the bumpfee).
< jonasschnelli> Both parts needs review and are not ready for 0.13
< jonasschnelli> We could merge petertodds global RBF opt-in PR though
< jonasschnelli> But 0.13 will have no bump feature.
< jonasschnelli> (only over rawtx)
< Chris_Stewart_5> cfields_: If you could take a look at the question and give me some insight it would be much appreciated https://bitcoin.stackexchange.com/questions/46062/add-dependency-bitcoin-core
< jonasschnelli> Chris_Stewart_5: cfields_ is currently away (for multiple days)
< jonasschnelli> But I'm familiar with the dependencies build system... I'll have a look
< Chris_Stewart_5> jonasschnelli: It would be much appreciated :-)
< sipa> i assume that you'll need autoconf magic to find the library
< Chris_Stewart_5> Ooh, things happening 'auto-magically'
< jonasschnelli> Chris_Stewart_5: I'm not very familiar with cmake...but I guess sipa is right
< jonasschnelli> You need to find the library in configure.ac
< jonasschnelli> Otherwise you don't have the corresponding -I and -L CXXFLAG
< jonasschnelli> adding the library to the depends/ system alone is not sufficient.
< jonasschnelli> Chris_Stewart_5: you need something like https://github.com/Christewart/bitcoin/blob/master/configure.ac#L551
< sipa> it will first need to work when just building normally
< sipa> depends is to make it work deterministically
< Chris_Stewart_5> sipa: What is the difference? I'm not super familiar C++ build systems
< sipa> Chris_Stewart_5: forget depends
< Chris_Stewart_5> Ok, and just try and link the file from the command line or something?
< sipa> Chris_Stewart_5: no, i mean, first make things work the normal way (add source files to makefile.am, make configure.ac find the dependency, ...)
< jonasschnelli> Agree with sipa.
< sipa> so autogen & configure & make work
< sipa> depends is the step afterwards, you don't need depends when just building through makr
< sipa> *make
< Chris_Stewart_5> Ok, i'll start off in that direction then. Thanks
< GitHub130> [bitcoin] thelazier opened pull request #8230: Fix LogPrint to LogPrintf (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/8230
< rubensayshi> sipa, wumpus recall the discussion about bare multisig
< rubensayshi> I have some1 with BTC in an actual bare multisig which is now essentially unspendable :(
< gmaxwell> How'd they even create the txouts?
< rubensayshi> from before v0.21.1
< rubensayshi> 12
< gmaxwell> rubensayshi: no version of bitcoin core will ever create bare multisig outputs.
< rubensayshi> yea, so it was created with counterwallet, which does bare multisig
< rubensayshi> didn't really expect people to use it, but they do xD
< btcdrak> rubensayshi: maybe create a signed tx spending it and ask a pool to mine it kindly.
< rubensayshi> there's probably other people outside of counterparty users with the same issue .. though I agree it's rare
< gmaxwell> large ones aren't even IsStandard to pay to.
< gmaxwell> Whats the txid:vout?
< rubensayshi> c6d964ea9a27e125c1b40188e9aee191aac03adc4c53ec811d9d2ce74c380768:2
< rubensayshi> there's a release scheduled with P2SH support for the counterparty backend, I guess I should double down on adding it to the wallet and making something to migrate
< gmaxwell> rubensayshi: that havs value 0.00635110
< rubensayshi> and poke around pools to find one that's willing to mine the TXs
< gmaxwell> and was created 16 days ago.
< rubensayshi> if there's 1 then there's others ...
< gmaxwell> rubensayshi: I misread your earlier text and thought you said "some 1 BTC".
< rubensayshi> nah, this case is just a fraction
< rubensayshi> though there's counterparty tokens bound to it
< rubensayshi> I can probably find a miner to fix this for counterparty
< rubensayshi> I'm just brining it up cause there's probably more, let me query the blocktrail DB to see how much value there's stuck in bare multisig
< gmaxwell> rubensayshi: probably your time would be better spent helping to get counterparty onto it's own network instead of trying to steganographically hide data in Bitcoin transactions.
< btcdrak> ^
< gmaxwell> (Though I do wish we'd followed my suggestion of size=max(size, (sigops*MAX_BLOCK_SIZE+MAX_SIGOPS-1)//MAX_SIGOPS) ).
< rubensayshi> gmaxwell, wouldn't that result in non-full blocks again?
< rubensayshi> I thought the fix was about the blocks not being full, not about the fee per block earned?
< gmaxwell> I don't give a shit if the block is full or not, rational behavior for the miner is to maximize income, even if it doesn't fill the block. Ignorant people may howl about something not being full, but the only real issue in my mind was that the block would end up massively under full and not even making the expected income for the miner due to cheap attack transactions.
< gmaxwell> The attack was paying very low fees, and blocking out a whole block with it. What I suggested would end up making them have to pay roughly as much to fill the block with txdata or sigops, so why bother using sigops to fill it?
< gmaxwell> luke's argument was just that the transactions were clearly abusive and should be filtered even if they pay high fees. Which is a reasonable argument.
< gmaxwell> but not strictly needed to fix the problem.
< rubensayshi> hmm, your suggestion seems reasonable and not as complex as coding up a way to only add high sigops/byte txs if it doesn't push it over the limit
< gmaxwell> Seperately, bare multisig should become non-standard-- if for nothing else because it seriously burns up sigops space--, but that should happen on the creating it side first.
< rubensayshi> I agree
< Chris_Stewart_5> What is the reasoning behind requiring standard transactions? Security? DOS prevention?
< Chris_Stewart_5> for relaying txs
< gmaxwell> Preserving forward compatiblity and reducing varrious abuse vectors.
< midnightmagic> \o/
< btcdrak> 25 blocks to go for CSV point of no return
< spudowiar> btcdrak: CSV?
< btcdrak> spudowiar: the current softfork bundle of BIP68,112,113.
< spudowiar> More confused but OK
< spudowiar> I'll check them BIPs out
< spudowiar> *dashes to GitHub*
< spudowiar> Anyway, I'm just dumb
< spudowiar> Wow, that's cool
< spudowiar> btcdrak: is this the same as segwit?
< spudowiar> I'm dumb no need to answer if you don't want to
< spudowiar> I'm just curious :)
< btcdrak> no this is a different set of protocol changes. tldr allows for timelocking bitcoins relative to when they are first confirmed in a block
< spudowiar> I get that
< btcdrak> see BIP112
< spudowiar> But what's segwit then?
< btcdrak> BIP141
< spudowiar> Thanks :)
< spudowiar> Thanks for wasting your time with me :)
< btcdrak> (together with 143 and 144 also)
< spudowiar> I'm just an annoyance but a curious annoyance who's just trying to learb
< spudowiar> *learn
< btcdrak> spudowiar: :)
< spudowiar> I wish I was more mature and less annoying :/
< spudowiar> Maybe when I'm an adult? :/
< spudowiar> :(
< * owowo> thinks many ppl wonder if it's Comma Separated Value
< owowo> is it now 19 blocks left? I lost track...
< btcdrak> 18
< molz> btcdrak, how do you get that number?
< btcdrak> 1916-numberofcsvsignals
< molz> 1916-1898.. but where do you get 1916?
< molz> "sincePeriodStart": {
< molz> "total": 1968,
< btcdrak> BIP9 spec
< btcdrak> prolly should be asking in #bitcoin or #bitcoin-dev
< _anthony_> what version number will the current version of core start using once CSV is activated?
< btcdrak> 0x20000000
< _anthony_> will any version number >=4 be valid?
< btcdrak> yes
< _anthony_> cool thanks