Hey Core. Just a thank you message for your all your work. Keep doing what you guys are doing. Ignore the outside pressures, and keep bitcoin from becoming centeralised. All of the fear mongering ignores the simple fact that the bitcoin network would be near impossible to replicate from scratch. Any transitional periods may have some discomfort, but compromising the network for short term bandaides is for fools.
bitcoin/0.13 a32d7c2 Cory Fields: release: bump required osx version to 10.8. Credit jonasschnelli....
the ancient wallet message I was talking about still exists, but apparently I closed the issue: https://github.com/bitcoin/bitcoin/issues/211 "Error: This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds!"
gmaxwell: After Scaling Bitcoin I came up with a new algorithm. I'm still running experiments on it (and writing my evaluation chapter, thesis is due next week), but it looks pretty promising in all aspects.
Hey gmaxwell, I was missing you at Scaling Bitcoin. :)
nibor: majority hashpower can make their new commitment say that a million bitcoin that wasn't theirs is now theirs. Then all newly joining nodes will get the new chainstate, and eventually all old nodes will think they've hit a reorg larger than people have blocks available, and so they'll do a chainstate sync too...
The other important thing about this proposal is that it needs to be very upfront about this being a signficant change to the Bitcoin security model, and justify it. I believe it is a nessary one.
namecoin did fairly recently rebase on top of newer bitcoin core (not sure what version). But yes most coins do not, it's not like they're a big target for attacks, nor actively maintained. The only way we notice is that sometimes people file bugs/build system issues against bitcoincore that have been fixed years ago, not realizing we've moved on since
for a long time most alt coins were, and still are 0.6 based branches. the original proof of stake patches were never rebased onto modern Bitcoin Core until quite late in the crazy. the original lfnet IRC channels still have hundreds of alt coin nodes (but only 2-3 wxBitcoin).
seems like jessie; the bitcoin.org binaries seemed to work fine for me in a chroot
for the latter, I'm not sure what the answer is.. one option is "use bitcoin.org binaries" but if you have to compile perhaps there is a newer compiler you can install out of the next distro version without breaking things?
there was an argument proposed where instead of only making libconsensus, someone (sipa?) said libconsensus + also some other library, and bitcoin core and also libconsensus consume from the other library.
I believe some code duplication is unavoidable once bitcoin core only talks to libconsensus' C API, for example, the primitives
I think this is typical bitcoin scope creep
kanzure: I highly doubt libbitcoin will ever use a libconsensus that's coupled to bitcoin's storage and concurrency, for example
conclusion, nobody seems to want the libconsensus I've been trying to move towards to, and as an external caller I wouldn't want a libconsensus++ (coupled to bitcoin core's storage and concurrency)
BlueMatt: an interface for CBlockIndex wouldn't requiore a ton of review, just some review. Remember you can use wrappers for the old stuff and only libconsensus needs to use the interface (uppper layers can remain using CBlockIndex directly), please see https://github.com/bitcoin/bitcoin/pull/8493
cfields_: right, so it's possible to fork bitcoin core but still use the same libconsensus, for example
sorry, went to sleep during API discussions. I agree that the library should be used by bitcoin core if it is to exist. :)
btw: I've had, out of many 'no' responses, only two people admitting they're still running bitcoin core on windows 32-bit. Both expect to stop doing so in the next 6 months.
<*highlight>[20:37:05] <sipa:#bitcoin-core-dev> jonasschnelli: ah, clocking on the warning icon. that took me a while - isn't there a way to make it more obvious, like adding another top bar with "You're currently out of sync with the network. Click here for more information' ?
sipa: yea, I don't mean that in a dogmatic sense. And I think in bitcoin core things are usually sensible. But I've had too much exposure to codebases where novices overuse these really exotic tools.
cfields_: oh, so we only need to wait until 2022 until we can use it in Bitcoin Core?
we *don't * want to support half of bost as part of bitcoin core
achow101: thanks, will put that on a bitcoin block so everybody knows ;)
[bitcoin] laanwj closed pull request #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (master...compat_importmulti_oldboost) https://github.com/bitcoin/bitcoin/pull/8980
bitcoin/master 0e22855 Wladimir J. van der Laan: Merge #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions...
bitcoin/master 7942d31 Luke Dashjr: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions
it's a valid way to do things, but that means targetting open source to windows is hard, ideally we should sell bitcoin core on windows instead of offer a free download :-)
there's nothing bitcoin specific about not being able to execute the right executable
[bitcoin] jonasschnelli opened pull request #8985: Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (master...2016/10/fix_gui_overlay) https://github.com/bitcoin/bitcoin/pull/8985
NicolasDorier: there are good uses for a very powerful script interoreter that does more than consensus too... for example a debugger or execution inspector, or something that supports signing some general class of signatures, maybe not specific to bitcoin transactions, ...
[bitcoin] luke-jr opened pull request #8980: RPC: importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (master...compat_importmulti_oldboost) https://github.com/bitcoin/bitcoin/pull/8980
No Bitcoin private keys in there, but gpg, probably ssh, and also token for github, chrome, etc.
michagogo: you could turn your working system into an appliance (including your bitcoin private keys)
[bitcoin] jonasschnelli closed pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
[22:07:48] <wumpus:#bitcoin-core-dev> jonasschnelli: could you elaborate in #8546 what you mean with " I think its acceptable if it breaks wallets used back in 0.3.x in conjunction with IP transaction". I don't think it'd be acceptable if the client suddenly crashes if someone happens to be using a wallet that still has a pay-to-IP transaction in it.