< 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?
< 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.
< 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
< 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?