< esotericnonsense>
doesn't really do much yet but should be less buggy than the old gevent based thing. :)
< Sentineo>
ah!
< Sentineo>
will try esotericnonsense
< esotericnonsense>
Sentineo: it has like 15% of the features of the other one. i just got tired of trying to figure out how to maintain the mess with this global state and all sorts of nonsense like that. :P
< Sentineo>
to be honest i did not try the other one
< Sentineo>
so wkll not be biased ;)
< Sentineo>
today is my dev day, so will work on mine, too. finishing the workqueue to not kill bitcoind jn the process of fetching fee ;)
< fanquake>
achow101 is #10579 the first time you
< fanquake>
've seen the whitespace linter masking another error?
< gribble>
https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
< jl2012>
gmaxwell: "technically we could make mainnet activate segwit at the same time as p2sh" not easy since miners included witness commitment before segwit activation. Those blocks are invalid under BIP141
< boltzar>
hello guys. i have a small issue. i own an exchange website and i usually use bitcoind to send the bitcoin to my clients. With these problems in the bitcoin network sometimes i have activated these options walletrejectlongchains=false , limitancestorcount=1000 , limitdescendantcount=1000 . If i didn't activate these my api would stop working on 25 unconfirmed transactions . The issue
< boltzar>
is: on my bitcoind server after i make 25 unconfirmed transactions they stop showing on blockchain.info for example untill they confirm ( the payments are made because i can see the tx hashes ) . Now i use another bitcoin api from block.io . Using their api i can make the same a lot of unconfirmed transactions , but their transactions are showing on blockchain.info even if there are
< boltzar>
to make it short. on block.io api i can see the entire long chain of 50 unconfirmed transactions and on my bitcoind api i can see only the first 25 even if i have 50 unconfirmed transactions
< jnewbery>
boltzar: please ask at #bitcoin or https://bitcoin.stackexchange.com/ . This is a channel for discussing Bitcoin Core development
< kebman>
Can anyone guide me to good resources on how to programmatically sign messages with a Bitcoin address?
< kebman>
Or rather, I've managed to sign a message and locally validate it - but it won't validate on places like http://www.coinig.com/
< kebman>
Not sure what I'm doing wrong :p
< Dizzle>
Made sure paste didn't have newlines/whitespace?
< kebman>
pretty sure
< Dizzle>
Or HTML/rich text if pasting into the browser
< kebman>
Nope just pure text
< kebman>
Any technical documentation on how Bitcoin signs messages?
< Dizzle>
The "magic" phrase is just a salt that makes it hard for someone to trick you into signing a transaction disguised as a message.
< Dizzle>
Not especially documented as its not so much a protocol feature as it is a wallet/site/whatever implementation feature. MultiBit started adding ASCII-compatible metadata armor and a lot of people think that's neat: https://multibit.org/help/hd0.3/sign-message.html
< kebman>
Ow nice! :D
< BlueMatt>
11309 looks merge-able
< BlueMatt>
morcos: wanna close 9447 (superceded by 10984, which I'm rebasing now)
< kebman>
Dizzle, yeah those links helps a lot! Thank you!
< Dizzle>
You're welcome :)
< wraithm>
Just out of curiosity, what do people think about HD multisig? Specifically, what would you think about adding HD multisig wallet support to bitcoind? Is it a bad idea?
< sipa>
what does that even mean?
< sipa>
bitcoind supports multisig, and supports HD derivation
< sipa>
(though you need to use raw transaction api)
< sipa>
oh, you mean the ability to watch for addresses that correspond to multisig of HD chains?
< wraithm>
I mean at the same time. Specifically, imagine swaping a bunch of xpubs around, deriving the same paths, making multisig addresses for all of them (all with the same thresholds, storing the redeem scripts, etc).
< wraithm>
And yes, I'd only be interested in making these watch-only.
< wraithm>
No signing, but maybe raw transaction construction.
< wraithm>
Signing done offline and merging the signatures later
< sipa>
sounds very useful, however it's very nontrivial with how core currently determines whether outputs belong to the local wallet
< sipa>
there is a plan to significantly overhaul that, as it's getting more and more complicated
< wraithm>
I don't know about how core determines what outputs belong to the local wallet. What's complicated about it?
< sipa>
it pretty much sees if it can sign
< wraithm>
Oh
< sipa>
with various hacks... there are watch-only imported addresses
< sipa>
but also imported public keys
< sipa>
and then imported redeemscripts that are not automatically watch-only
< wraithm>
What's involved in the overhaul plan? Some sort of address cache?
< sipa>
yes, have a separated set of scriptPubKeys to watch for (perhaps using a bloom filter), independent from what we know how to sign for
< sipa>
and then known HD chains can feed both into what to watch for and what to sign for (if it's a private chain)
< sipa>
while importing watch-only keys just go into the watch set
< wraithm>
Is it possible to have a watch-only HD wallet today, or does it require the overhaul?
< sipa>
no, that's not possible
< sipa>
it's not technically necessary to overhaul things to support that, but i'm very scared about complicating the current code further
< wraithm>
Makes complete sense. It doesn't sound simple. Is anybody working on this separated set of scriptPubKeys rework?
< sipa>
no, we're focussed on 0.15.1 for now
< instagibbs>
wraithm, https://github.com/bitcoin/bitcoin/pull/9728 does hd watchonly, but as sipa said, how it interacts with stuff is non-trivial. I think a lot of the corner-cases go away post-overhaul
< bitcoin-git>
[bitcoin] mess110 opened pull request #11410: [rpc] [tests] Add minrelaytxfee to getmempoolinfo (master...add_minrelaytxfee_to_getmempoolinfo) https://github.com/bitcoin/bitcoin/pull/11410