During the last malleability attacks I walked a bitcoin ATM operator through doing that. Hard part was explaining the need, once they got it the actual implementation was easy. (well also the wallet they were using to fill their ATMs ..... had no sendmany support. :( )
there's an option in bitcoin core's wallet to not spend any unconfirmed outputs
which reminds me...I need to ask cfields what would he think about a consensus building module separated from util, common, etc, maybe merging with libsecp256 and crypto modules (that is not good for bitcoin-tx when we start adding non-tx stuff to the module, but verifyheader and verifyblock should be relatively light compared to verifytx and verifyscript)
jgarzik: it seems that that is not really the case; you can come up with a formula to treat bitcoin-days-destroyed as extra fee, but it's probably hard to prevent it from making miners lose large amounts in fees
but I agree that you either want bitcoin core to choose a fee for you (estimate confirm within # confirmations) or you want to set a fee/kB, which should be above what your mempool accepts at all
wumpus, about the "all fees in bitcoin core are per kB" thing:
there's one difference though: tor only authenticates on opening the connection, bitcoin http authenticates for every request. So they can use more key stretching without creating command latency issues.
Okay, I confess some paranoia here-- I don't want this to be like the rpc hangs issue. Where we pigheadily avoid improvements for some silly footgun which is making people stop using bitcoin core and switch to hosted apis.
(or #bitcoin-wizards if it is moonmath related :-) )
well definitely not here, this channel is just for bitcoin core related programming work. The proper answer to your question is stil 'the mailing list'. #bitcoin-dev is fine, but IRC discussion tends to be more ephermal than mailing lists
The usual procedure for BIP proposals is to discuss on mailing list first. But given that at least a few important reviewers/critics either have unsubscribed to the ML entirely or else just ignore it, should we discuss it here or in bitcoin-dev?
also, it may not be exploitable... the BN_sqr bug we found in OpenSSL (thanks to libsecp256k1's unit tests that compared with OpenSSL) was technically a hard fork for bitcoin when it got foxed, but an unexploitable one as far as we know
bitcoin/master e54ebbf Wladimir J. van der Laan: Merge pull request #6954...
for me bitcoin core sync runs at around 8000tx/s (with secp256k1), even though every tx is involving a non-cachable missing record check for bip30 (in addition to all the cached stuff)... thats really quite remarkable IMO.
morcos: there's also stratum proxies like bfgminer and stratum-mining-proxy which present work to downstream miners, based on either an upstream work server or a Bitcoin node. the latter was meant for use with early hardware miners which supported getwork but not stratum.
(Forrestv seems to have flamed out due to a mixture of bitcoin drama, and then donations to support p2pool being relatively low (compared to life changing amounts of income centeralized pool operators were getting), and then he got ripped off ... twice, I think, by mining hardware makers.)
Also through this time the developer burned out on Bitcoin, and only does life support maintaince on p2pool now.
P2pool is nice idea with cute features, but has always struggled with the high startup cost of having to run a bitcoin node with it; and then high latency asics showed up (in particular, some of the early BFL products had 10%+ hashrate loss from 10 second retasking)
morcos: well it's armored by bitcoin nodes in and out; not that there haven't been problems.
Yes. It is. I tried to do it for bitcoin core eons ago, but the utility library was GPLed... they since changed the licensing.
[12:41:14] <Luke-Jr>jonasschnelli: why a new key? :/ <-- the new key is not really new, It's just the one that I use for bitcoin-dev posts, etc. The "old" key is used for non-bitcoin software-projects (and sadly, i have used it for gitian signatures)