#bitcoin-core-dev

/

      • Luke-Jr
        is there a way to get [skip ci] without polluting the commit message?
      • sipa
        ask a maintainer to kill the travis job :p
      • Luke-Jr
        sipa: are you okay with me asking people to remove it from commit messages and ask maintainers instead? :P
      • seems like a waste of time
      • sipa
        yeah :)
      • challisto has quit
      • i just wouldn't bother
      • Ylbam has quit
      • challisto joined the channel
      • challisto has quit
      • challisto joined the channel
      • challisto has quit
      • belcher has quit
      • PaulCape_ joined the channel
      • PaulCapestany has quit
      • molly joined the channel
      • moli has quit
      • d_t has quit
      • d_t joined the channel
      • CodeShark
        hmm, SoftForkMajorityDesc needs to be moved into the soft forks unit as well...
      • d_t has quit
      • would be nice to define the validation rules for each soft fork in its own module as well...so then the entire soft fork can be specified as a unit that just needs to be added and linked to Bitcoin Core
      • no more need for PRs for that :)
      • other than the trivial link
      • totally doable, too
      • I know how to do it...but it would require moving a few things around in main.cpp
      • hopefully can be done without being too extremely invasive
      • the only real question I have is whether this is desirable...should we make it *that* easy to define and deploy a soft fork?
      • would require some changes to script/interpreter.cpp as well
      • but I think that it could be done in a minimally invasive way...keeping what's already there more or less in tact
      • *intact
      • jgarzik joined the channel
      • jgarzik joined the channel
      • GitHub142
        [13bitcoin] 15dgenr8 opened pull request #6785: Backport to v0.11: In (strCommand == "tx"), return if AlreadyHave() (060.11...06already_have_0.11) 02https://github.com/bitcoin/bitcoin/pull/6785
      • moli joined the channel
      • molly has quit
      • jgarzik has quit
      • d_t joined the channel
      • da2ce7 has quit
      • paveljanik has quit
      • d_t has quit
      • PaulCapestany joined the channel
      • PaulCape_ has quit
      • d_t joined the channel
      • Ylbam joined the channel
      • epilido joined the channel
      • n0n0__ joined the channel
      • Squidicuz has quit
      • GitHub108
        [13bitcoin] 15Diapolo closed pull request #6288: [Qt] fix debug console window handling when e.g. minimized (06master...06show-rpconsole) 02https://github.com/bitcoin/bitcoin/pull/6288
      • n0n0__ has quit
      • randy-waterhouse joined the channel
      • da2ce7 joined the channel
      • fkhan has quit
      • da2ce7 has quit
      • wumpus
        Luke-Jr: [skip ci] only works in the commit message, not the pull title?
      • Luke-Jr
        wumpus: ?
      • fkhan joined the channel
      • wumpus
        Luke-Jr: I mean - what does travis look at, the pull request title or the commit message?
      • Luke-Jr
        no idea, I just don't like it in the commit message :p
      • wumpus
      • but it *doesn't have* to be in the first part
      • Luke-Jr
        moving it to the long description would be an improvement at least
      • rubensayshi joined the channel
      • wumpus
        you can just [skip ci] hide it somewhere in the description
      • GitHub84
        [13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d4...
      • 13bitcoin/06master 14b2af29b 15Pavel Janík: Ignore bench_bitcoin binary.
      • 13bitcoin/06master 14a99b6cb 15Wladimir J. van der Laan: Merge pull request #6770...
      • GitHub12
        [13bitcoin] 15laanwj closed pull request #6770: [Trivial] Ignore bench_bitcoin binary [skip ci] (06master...06bench_gitignore) 02https://github.com/bitcoin/bitcoin/pull/6770
      • da2ce7 joined the channel
      • ParadoxSpiral joined the channel
      • GitHub52
        [13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a9...
      • 13bitcoin/06master 1434754ce 15Chris Kleeschulte: [Trivial] Fixed typo when referring to a previous section in...
      • 13bitcoin/06master 14c82ea8b 15Wladimir J. van der Laan: Merge pull request #6783...
      • GitHub66
        [13bitcoin] 15laanwj closed pull request #6783: [Trivial] Fixed typo in depends/README.md [skip ci] (06master...06depends_readme_typo) 02https://github.com/bitcoin/bitcoin/pull/6783
      • GitHub28
        [13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c8...
      • 13bitcoin/06master 14b22692c 15Cory Fields: build: Make use of ZMQ_CFLAGS
      • 13bitcoin/06master 146cf73b0 15Wladimir J. van der Laan: Merge pull request #6779...
      • GitHub61
        [13bitcoin] 15laanwj closed pull request #6779: build: Make use of ZMQ_CFLAGS (06master...06fix-zmq-cflags) 02https://github.com/bitcoin/bitcoin/pull/6779
      • aj
        wumpus, Luke-Jr: am i completely off-base think bip68/nSequence for relative locktime will cause SPV clients to see bad confirmations on about 5% of blocks for a while after activation? cf http://lists.linuxfoundation.org/pipermail/bitc...
      • s/think/in thinking/
      • fkhan has quit
      • Luke-Jr
        aj: just the usual softfork expectations given SPV limitations
      • 1-block confirmation is never secure for SPV anyway
      • aj
        Luke-Jr: afaics for softforks that upgrade OP_NOP's SPV clients won't have that problem
      • Luke-Jr: (or won't have it any worse than normal anyway)
      • Luke-Jr
        aj: I don't follow then.
      • aj
        Luke-Jr: (1) afaics, apart from elegius, 99.9% of existing hashpower won't mine OP_NOP txns but will mine nSequence transactions
      • Luke-Jr
        oh, I see what you mean
      • aj
        Luke-Jr: (2) post softfork, 5% of miners haven't upgraded. but eligius has, so no one will mine OP_NOP stuff, but 5% will mine bad nSeq/relative-timelock txns
      • Luke-Jr: so SPV clients go from .1% (made up number) of hashpower being a problem to 5% of hashpower being a problem
      • Luke-Jr
        aj: I don't think there's ever been a softfork without this "problem"
      • well, except BIP66 I guess
      • not even that actually
      • because older block versions were disallowed
      • anyway, 5% of hashpower won't get more than a block or two deep
      • aj
        Luke-Jr: afaik SPV clients don't check block versions generally anyway
      • Luke-Jr: OP_CLTV won't have that problem, afaics
      • Luke-Jr
        perhaps not. but it will be the first not to.
      • aj
        Luke-Jr: (wow)
      • Luke-Jr
        and SPV 1-block confirmation is not secure regardless
      • aj: the versionbits stuff does improve on this
      • after the softfork goes active, there is a difficulty-adjustment period (2 weeks) before it is enforced
      • so other miners can upgrade
      • aj
        Luke-Jr: versionbits maybe makes it a little harder, in that after activation the bit's not set anymore, so you can't even compare the nVersion of the latest block to see that something odd's happening?
      • Luke-Jr
        aj: SPV nodes need the full header-history anyway, so they can implement versionbits
      • aj
        Luke-Jr: i think, without a soft-fork upgrade, to exploit a SPV client, you need to use your own hashpower to mine a will-be-orphaned block to trick SPV clients; but immediately after soft-fork activation, you have 5% of other people's (ie *free*!) hashpower that will mine will-be-orphaned blocks for you?
      • Luke-Jr
        aj: only if 5% got left behind
      • aj: the expectation is not that those 5% continue mining invalid blocks
      • aj
        Luke-Jr: hmm, is there any way to tell how much hashpower dropped off in previous upgrades?
      • Luke-Jr
        dunno, probably just Deepbit
      • aj
        Deepbit
      • ?
      • oh that was a mining pool, not a stats site? :)
      • Luke-Jr
        aj: a mining pool that once had over 50% ;)
      • CodeShark
        two things: 1) clients that do not recognize the version can (and *should*) warn the user that something might be up. 2) 1-confirmation reorgs are typical in the daily course of business...around soft fork activations, thin clients (that don't validate blocks) should be even more careful
      • Luke-Jr
        CodeShark: will versionbits impl kill mining when it detects it is being softforked out?
      • ie, getblocktemplate should probably fail if some activated softfork is unsupported
      • CodeShark: btw, I was thinking of the softfork plugin thing a bit ago also, so sounds good to me :P
      • CodeShark
        :)
      • fkhan joined the channel
      • Luke-Jr
        maybe harder than it seems though in practice
      • CodeShark
        I have some ideas for how to do it...but if we're going to be doing a bunch of refactors after 0.12 is released, I figure this is a good area on which to focus :)
      • we don't want to have to backport each individual soft fork perpetually...and it might actually be easier to backport the plugin thing
      • aj
        be easier to backport pluggable soft forks once the plugin thing exists too, presumably
      • CodeShark
        yes, of course
      • sipa
        what do you mean by plugin system?
      • CodeShark
        I posted something on the mailing list - but I'm guessing you unsubscribed :)
      • sipa
        yes
      • CodeShark
        I can forward it to you if you want
      • or you can look for the link on linuxfoundation.org :)
      • aj
      • sipa
        shouldn't need any changes in primitives... that's only for data types, their construction, and serialization... softforks can't change those
      • CodeShark
        CBlock needs a new default version
      • or could be implemented in getblocktemplate, I suppose
      • in principle I agree
      • CBlock should not be where the default version gets set
      • fkhan has quit
      • sipa
        yes, indeed
      • those default versions there don't belong
      • you say "easily merged units"... that's pretty vague
      • CodeShark
        right - primitives should just handle data access and serialization
      • sipa
        what do you mean specifically?
      • btcdrak
        sipa: will you consider joining again after we get the new list and push offtopic stuff to the new list?
      • sipa
        btcdrak: maybe
      • CodeShark
        sipa: by adding two lines to the makefile and one line to an init function
      • and two files to the repo :)
      • at least for starters
      • long-term it would even be possible to deploy at runtime
      • sipa
        CodeShark: so you pretty much mean... changing the code location organizatiin so that soft forks are the top level?