< wannabecoder>
hello, i am new to coding in bitcoin. I literally can't figure anything out.
< wannabecoder>
I am given an assignment to create a transaction to deposit 0.01 btc to a 2 of 3 multisig script. I have the public keys of three addresses and private keys of three. I have installed Bitcoin Core and configured it to a testnet. question 1: where do i write the code?
< wannabecoder>
question 2: is there a language in which the code is written?
< sipa>
1) you don't; you invoke RPCs to accomplish it
< sipa>
2) C++
< sipa>
this probably belongs on #bitcoin
< wannabecoder>
oh so the RPC's are written in the console in the bitcoin core app?
< wannabecoder>
oh i am so sorry, thanks though
< sipa>
in bitcoin-qt you can type RPC commands in the console, yes
< sipa>
you can also use bitcoin-cli to send commands to a running bitcoind process
< wannabecoder>
oh okay. thanks a ton.
< promag_>
sounds more "i am new to coding"
< gwillen>
achow101: (et al): I need to pull analyzepsbt out of rpc into a more generic useful place
< gwillen>
this is a little awkward because of the pervasive use of UniValue throughout
< gwillen>
does it make sense to allow UniValue to be the official interface of this feature, or do I need to like, devise a PSBTAnalysis struct to use instead
< gwillen>
probably the latter?
< sipa>
gwillen: is the latter a lot of work?
< sipa>
i would certainly prefer UniValue to not be used outside of the RPC code
< achow101>
gwillen: i agree with sipa
< gwillen>
achow101: sipa: I expect it's probably not a lot of work
< gwillen>
so I will aim that way and see where I get
< bitcoin-git>
[bitcoin] murrayn opened pull request #15500: Support for a bitcoind 'ready' file to indicate startup is complete. (master...ready_file) https://github.com/bitcoin/bitcoin/pull/15500
< wumpus>
sipa | i would certainly prefer UniValue to not be used outside of the RPC code <- fully agree
< wumpus>
e.g., in the c++ part use c++ structures, not mock-javascript, only use univalue for the front-end
< bitcoin-git>
[bitcoin] luke-jr closed pull request #15428: [WIP] GUI: Add Pairing tab with Tor onion address as copyable text and QR code (master...tor_gui_pairing) https://github.com/bitcoin/bitcoin/pull/15428
< bitcoin-git>
[bitcoin] murrayn opened pull request #15501: Formatting changes to --help code for increased readability. (master...help_formatting) https://github.com/bitcoin/bitcoin/pull/15501
< bitcoin-git>
[bitcoin] fanquake closed pull request #15501: Formatting changes to --help code for increased readability. (master...help_formatting) https://github.com/bitcoin/bitcoin/pull/15501
< wumpus>
PSA: tomorrow the 0.18 split-off is planned
< kanzure>
bitcoin-dev mailing list has been having issues and it's broken
< kanzure>
i have escalated to warren who knows linux foundation people but apparently they don't believe in email anymore
< jonasschnelli>
hmm...
< instagibbs>
hi
< sipa>
kanzure: no eta for a fix?
< wumpus>
email has been dead for a while just not everyone has noticed yet
< kanzure>
no eta for fix
< kanzure>
i don't know anyone at linux foundation and i don't know who maintains this on their end
< achow101>
kanzure: any alternatives that we can move to?
< kanzure>
nothing good....
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #15503: msvc: Use a single file to specify the include path (master...msvc-include-fix) https://github.com/bitcoin/bitcoin/pull/15503
< wumpus>
#topic bitcoin-dev mailing list
< kanzure>
groups.io isn't that nice in my opinion; i don't think we would like it as a group.
< jonasschnelli>
would self-hosted be an option or would that be to "centralized"?
< jonasschnelli>
Could do it over an association
< jnewbery>
hi
< kanzure>
self-hosted would be fine but someone would have to maintain it and fix email delivery problems etc
< jonasschnelli>
I can look into possible options/strategy for a self-hostes (eventually semi) option... in case LF list falls appart
< jonasschnelli>
*hosted
< kanzure>
that would be helpful thank you
< gwillen>
kanzure: if you can summarize quickly, what sort of issues does groups.io face?
< jonasschnelli>
I have a bunch of RPi laying around and a 512kb connection... *duck*
< kanzure>
gwillen: sort of forces you into a web browser environment
< gwillen>
hmm, really?
< jonasschnelli>
I propose to keep the UX (mailman)
< wumpus>
or maybe it's time to move to something else than a mailing list
< promag_>
hi
< jonasschnelli>
If there would just be a decentralied IM service
< sipa>
it's a bit unfortunate that this discussion is held here, but the place it should be held (the ML...) isn't really an option
< gwillen>
ensuring deliverability in a self-hosted setup is going to be a chalenge, the world of email has gotten increasingly hostile
< wumpus>
gwillen: yea... it's dead alright
< wumpus>
email is owned by google now
< jonasschnelli>
Indeed... thanks to the big players
< gwillen>
I host my own email but I smarthost through a gmail account outbound
< provoostenator>
Well, mostly thanks to the spammers I think.
< wumpus>
might as well just run a discourse forum and have all the usability advantages
< jonasschnelli>
would bring it to github (different organization) be an option?
< gmaxwell>
provoostenator: there is enough blame to go around. :)
< wumpus>
I don't think blame is the point of discussion here anyway, how do we move on ?
< gmaxwell>
not going to solve this in this meeting, I suspect!
< wumpus>
true
< gmaxwell>
I also would like it to stay mailman.
< gmaxwell>
(or similar)
< provoostenator>
A publicly readable forum seems like a reasonable solution, but chat seems terrible. Both because it's distraction and because I want to be able to respond to stuff said months ago, so it needs threads.
< gmaxwell>
I guess someone needs to try to find out if its coming back or if we really do need to find an alternative.
< kanzure>
we can try groups.io some more, we have a test group and we can just add a few more people to the test and see what people think
< achow101>
go back to bitcointalk *ducks*
< gmaxwell>
achow101: damn I was just about to make that comment!
< kanzure>
#action message kanzure if you want to be added to the groups.io test group
< gwillen>
kanzure: can you add me to the test group
< gmaxwell>
I'm really not excited about groups.io.
< kanzure>
email should get everyone excited!
< luke-jr>
gmaxwell: supposedly mailman is unmaintained and broken-ish, according to LF?
< jonasschnelli>
self hosted mailman seems superior to groups.io
< gwillen>
self-hosted mailman requires someone to become an email server administrator
< gwillen>
that is an _extremely_ unfun volunteer job
< jonasschnelli>
Yes.
< wumpus>
self-hosted by whom ? who's going to babysit this
< kanzure>
can we pay someone to do work?
< wumpus>
heh.
< jonasschnelli>
But I self-host my email since a couple of years and it's possibble
< luke-jr>
I already do maintain my own email server, but from the sound of it, ML makes it much harder
< gmaxwell>
biggest problem with hosting email these days is that everyone randomly blocks you.
< gwillen>
jonasschnelli: do you do your own outbound mail? No deliverability problems to gmail users, no dnsbl issues?
< jonasschnelli>
gwillen: I do
< jonasschnelli>
No problems
< gwillen>
hm, very good
< wumpus>
right-personal email is easier, though still not trivial; less traffic, and the only person to complain when messages don't arrive is yourself
< gwillen>
I'm glad it's still possible
< jonasschnelli>
But with ML the spamlist (dnsbl, etc.) become more of a problem..
< wumpus>
I used to run my own email server, but gave up when gmail blackholed my last vps host
< jonasschnelli>
But better to manage that than no ML at all
< jonasschnelli>
3-4 IPv4 addresses to switch over to makes it more robust...
< kanzure>
we could just put text files in a git repository
< wumpus>
if you're going through that trouble might as well pay some service to do it
< gmaxwell>
I also don't think we mind too much if the ML suffers a little from users own servers blacklisting it. There are public archives.
< jonasschnelli>
There are also managed mailman hosting
< provoostenator>
I think a paid professional service is fine, as long as the archives are public and we have a way of detecting censorship.
< kanzure>
someone does managed mailman hosting services?
< gmaxwell>
Can we please just get a definitive from LF before we sink tons of effort into this?
< kanzure>
linux foundation has consistently said they are killing this
< kanzure>
according to warren
< jonasschnelli>
Agree with gmaxwell... (before continue this discussion)
< gmaxwell>
Can we please not filter everything through warren?
< wumpus>
well LF's moderation has been offline for quite some time now, I don't think it's coming back tbh, especially as they've already warned months before that this was going to end
< kanzure>
i'd be happy to get in contact with someone at linux foundation myself if i knew who to pester
< gmaxwell>
How are the linux kernel lists and such running?
< kanzure>
let's ask rusty, he's the resident kernel hacker
< jonasschnelli>
If you are having trouble using the lists, please contact mailman@lists.linuxfoundation.org.
< kanzure>
admindb is returning "503 first byte timeout"
< wumpus>
can't we pretend that bitcoind is a gpu driver and get a freedesktop list ...
< MarcoFalke>
I think we should have moved off the list when it was still working. Now there is no way to notify subscribers that it will move to a different place
< sipa>
wumpus: a few years too late :p
< wumpus>
sipa: hehe
< sipa>
MarcoFalke: but who would have expectes it to break like this, with solution in sight, with no warning?
< MarcoFalke>
They warned us months ago, multiple times. No?
< wumpus>
they warned
< kanzure>
they warned
< provoostenator>
That's what kazure claims warren says.
< gmaxwell>
I only ever heard warren saying stuff and it didn't sound credible.
< kanzure>
that's what i claim provoostenator says i claim warren claims
< gmaxwell>
(e.g. it was mixed up in mania about jeff garzik being on their board)
< kanzure>
i have emailed mailman@lists.linuxfoundation.org as of a few moments ago
< MarcoFalke>
What was the reason against a google group?
< MarcoFalke>
At least it would be reliable
< wumpus>
oh noo
< jonasschnelli>
help killing email further?
< gmaxwell>
I won't use it.
< kanzure>
i don't think they intend to support google groups forever
< provoostenator>
Google tends to shut down useful services with crazy short notice.
< wumpus>
I'd so prefer a self-hosted discourse forum to that
< kanzure>
anyway, we're still testing groups.io so others should feel free to email warrentest@groups.io
< wumpus>
at least it doesn't require a google account
< jonasschnelli>
you mean bitcointalk.org? :/
< luke-jr>
btw, re linux kernel ML - it's not hosted by LF it looks like
< kanzure>
any help in reaching linux foundation would be appreciated by me
< sipa>
also don't forget that it needs to be acceptable to a lot of pelple who aren't here
< kanzure>
and someone should ask rusty about lkml
< provoostenator>
In particular #15486 is very new.
< sipa>
they can go in after fork off of coirse
< gribble>
https://github.com/bitcoin/bitcoin/issues/15486 | [net] Allow feeler connections to go to the same netgroup as existing outbound peers by sdaftuar · Pull Request #15486 · bitcoin/bitcoin · GitHub
< wumpus>
#15497 #15486 #15402
< gribble>
https://github.com/bitcoin/bitcoin/issues/15497 | Consistent range arguments in scantxoutset/importmulti/deriveaddresses by sipa · Pull Request #15497 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/15486 | [net] Allow feeler connections to go to the same netgroup as existing outbound peers by sdaftuar · Pull Request #15486 · bitcoin/bitcoin · GitHub
< wumpus>
yes if you have any questions about it, just ask
< wumpus>
any other topics?
< jnewbery>
is there a wallet meeting tomorrow? We postponed last week's
< sipa>
do we have meshcollider?
< wumpus>
good question; meshcollider, jonasschnelli ?
< achow101>
I thought we were just skipping last week's
< jnewbery>
It's it up for vote, I vote yes please
< jonasschnelli>
I think I never participated on one of those meetings (shame on me)
< wumpus>
if you have pressing wallet topics to discuss we should have a wallet meeting
< gmaxwell>
[announcement] In the last 8 days I've merged 17 PRs in libsecp256k1 and closed about twice as many issues. So if anyone was holding back on offering improvements because there wasn't much activity there, thats no longer the case. (Also, most of what remains isn't getting merged quickly, so if you were expecting otherwise please feel free to ping on that repo)
< wumpus>
gmaxwell: good to know, I still intend to make a risc-v asm implementation of some things
< gmaxwell>
\O/
< sipa>
oh nice
< gmaxwell>
I should get a risc-v VM going then. :)
< provoostenator>
Nothing urgent wallet wise from my end. I started a very, very rough draft of a descriptor based wallet in #15487. I'll ping people when that's a bit further along.
< jonasschnelli>
Nice! provoostenator... I'll take a closer look soon
< provoostenator>
If someone wants to whip up a Descriptor instance method that can scan the blockchain for relevant transactions that would help.
< wumpus>
provoostenator: that looks interesting
< luke-jr>
gmaxwell: there's apparently $8 RISC-V hardware now (not much memory, but maybe irrelevant for just libsecp256k1)
< sipa>
provoostenator: that sounds like the wrong approach; descriptors shouldn't need to know about the blockchain
< gmaxwell>
easier to debug on a VM than a microcontroller. :P
< instagibbs>
provoostenator, we're already using descriptor-based detection when scanning blocks I thought
< sipa>
and it shouldn't ne needed either, as you can compute the sPKs and scan for those
< instagibbs>
for detecting used keys at least
< sipa>
instagibbs: nope
< sipa>
yes
< sipa>
but not for ismine
< provoostenator>
sipa: somethign should do such scanning, I don't care what.
< instagibbs>
right, but I'm saying I'm not sure what the big leap is :)
< instagibbs>
details aside
< wumpus>
luke-jr: yea for just that the amount of memory doesn't matter, I was eventually able to test most of secp256k1 on the HiFive board with 16kB of memory (+ lots of read-only flash)
< wumpus>
but yes VM is definitely easier for debugging than JTAG+openocd
< wumpus>
no more topics I guess?
< instagibbs>
provoostenator, I'll take a look at your WIP for tomorrow if I get the time
< sipa>
provoostenator: the hardest part is getting an equivalent of the keypool, i think - we still need lookahead to find gaps, but it needs to be something consisting of sPKs (and related indexes into descriptors) rather than just keys
< instagibbs>
"(and related indexes into descriptors)" hm?
< sipa>
so that we can remember how far the expand them
< instagibbs>
ah, numbers, not like txindex indexes
< sipa>
ah yes
< provoostenator>
In my WIP I added a WalletDescriptor class in walletdb.h, which I image could track the last seen and/or last resevered (with getnewaddress) index.
< instagibbs>
somehow I think "indices" disambiguates it even though they're technically identical
< provoostenator>
Maybe it doesn't need a new class.
< sipa>
provoostenator: it needs a lot more
< sipa>
i have a gist that describes the necessary things i think
< provoostenator>
I added a lot a restrictions to the initial attempt that makes things a bit easier.
< provoostenator>
No private keys for example :-)
< provoostenator>
But of course we still need to architect it in a way that's not a dead end.
< sipa>
yeah
< provoostenator>
Another shortcut I took was serializing the descriptor as a string, which is also not a good long term solution I think.
< provoostenator>
I found myself needing unique identifiers...
< provoostenator>
(maybe your gist already covers all that)
< jonasschnelli>
I guess we can close the meeting?
< sipa>
yeah
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Feb 28 19:55:31 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< provoostenator>
Ah yes, the famous gist. I'll give that another read, since I've dug a lot deeper into the rabbit hole since the last time I read it.
< bitcoin-git>
bitcoin/master 4a5e52c Chun Kuan Lee: msvc: Use a single file to specify the include path
< bitcoin-git>
bitcoin/master 29c24b0 MarcoFalke: Merge #15503: msvc: Use a single file to specify the include path
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15503: msvc: Use a single file to specify the include path (master...msvc-include-fix) https://github.com/bitcoin/bitcoin/pull/15503
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #15505: [p2p] Request NOTFOUND transactions immediately from other outbound peers, when possible (master...2019-02-notfound-requests) https://github.com/bitcoin/bitcoin/pull/15505
< gwillen>
provoostenator: for what it's worth, none of your PGP-signed messages that came through to me at all, have been mangled (on the groups.io test)
< gwillen>
I got two clearsigned with inline signatures, both look fine
< sipa>
sdaftuar: interesting... are notfound messages for things we requested common?
< sdaftuar>
sipa: sort of. they are common now for parents of orphan transactions, since we don't give those out yet ourselves
< sdaftuar>
of course this will have no benefit in those cases, typically
< sdaftuar>
but this paves the way for a future in which we could be more willing to drop things out of mapRelay and not serve them to peers
< sdaftuar>
because we can reasonably believe our peers can just request them from someone else (right now this a small DoS to our peers if we give a NOTFOUND)
< sdaftuar>
and then we can get rid of mapRelay altogether, i think -- which i'd like to do because our memory bounds on it are not very tight
< sdaftuar>
(and then i can fix the problem of us not returning parents of orphan transactions when a peer requests them)
< sipa>
hmm, interesting
< provoostenator>
gwillen: odd, Apple Mail with GPG Suite complains the signature is invalid, but perhaps other mail clients are more tolerant?
< gwillen>
provoostenator: I just copied and pasted everything inside the ----- lines into gpg2
< gwillen>
but I saw that you said something about the footer cutting into the signature, and I don't see anything like that on my end (this is on the message that starts with "maybe this works")
< gwillen>
everything looks intact
< bitcoin-git>
[bitcoin] practicalswift closed pull request #15214: tests: Check for expected return values when calling functions returning a success code (master...check-return-values-in-tests) https://github.com/bitcoin/bitcoin/pull/15214
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #15506: appveyor: fix cache issue and reduce dependencies build time (master...appveyor-release-only) https://github.com/bitcoin/bitcoin/pull/15506
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15507: test: Bump timeout on tests that timeout on windows (master...1903-testTimeoutWindows) https://github.com/bitcoin/bitcoin/pull/15507