Transcript for #bitcoin-dev 2018/01/19

01:01 d3h echo=10usd fee? sweep*
01:05 d3h I actually wanna fucking kill you guys after that fee
01:08 contrapumpkin ?
01:08 contrapumpkin no threats plsthx
01:08 d3h sorry dude. its just you took 10usd off my balance without asked ng or notifying.
01:09 d3h on the sweep function with private keys
01:12 d3h it was 30usd balance. now 20 heh
01:15 S-Nake i need web site i can stay update on crypto witch one is the best
01:15 d3h I don't make a lot of money. Most of my money goes towards what I believe in. I'm unemployed at the moment and a long way away from being able to throw 10usd away, its actually a lot of money for most people. Please adjust the fee notices on the sweep wallet function. I wouldn't pay the fee if you notified me before the sweep. please just don't let this happen again.
01:16 d3h Thank You and good luck
01:18 S-Nake crypto news
01:33 d3h it says "all coins will be moved"
01:33 d3h 10usd is a lot without notice
01:34 d3h you guys get an at with that?
01:34 d3h get away*
01:34 S-Nake d3h you have web site to news on crypto
01:34 d3h cointelegraph?
01:35 d3h coindesk?
01:35 S-Nake i go check
01:35 S-Nake thank
01:35 d3h no where in the world takes your money without asking/notifying. that's theft
01:36 d3h I thought my parents generation stopped that?
01:36 d3h before and after photo of a wallet sweep with convention rates
01:37 d3h conversion
01:37 d3h to usd
01:37 d3h who can I speak to about this? reverse transaction?
01:38 d3h at least to the wallet where the funds originated from. that's outrageous.
01:40 d3h I'll sink their Azimut.
01:41 d3h and watch a moroccon laugh
01:41 d3h I'd swiss insure that
01:43 zendainc Christ
01:43 zendainc If I pay you $10 will you go away?
01:44 d3h if you reverse the transaction
01:44 zendainc I have zero to do with anything related to bitcoin-dev, but you are annoying and should go away
01:44 d3h otherwise I'll kill your fucking daughter.
01:46 d3h hahahhahahahhahhahha
01:46 d3h does that come with jack and coke?
01:46 d3h you sick fuck
01:47 d3h I'll drive that thing over your mums face
01:48 d3h =P
01:48 zendainc zzzzzzz
01:48 d3h speedy
01:49 zendainc Troll more. Clearly you are bored.
01:51 d3h go get some more freckles.
01:51 d3h is that a lookalike? oh no wait, her face got ran over.
01:53 d3h its as easy as right click edit
01:54 d3h and I still can't import those keys into core from jaxx wallet
01:54 d3h so I'll have to do it again or send.
01:54 d3h how many siblings have you got?
01:55 d3h can you fix the fees or import from wallet to core with keys.
02:00 d3h if I lose 2/3 of my balance I won't be happu
08:03 eugenes1__ hi
09:22 thrasos hi
09:23 thrasos I am thinking of coding an open source wallet for iOS, does anyone know of any easy API's that output data in JSON?
09:48 thrasos I got disconnected, did anyone repond?
10:02 arubi thrasos, no. but the channel is logged (topic) so if you drop you can check there
10:03 thrasos I see thanks
10:04 meshcollider thrasos: there are probably lots of APIs, I can see multiple from just google search
10:09 thrasos @meshcollider : Which one would be the most popular? Also I'll be coding in Swift, most of the API's have their own libraries in other languages. I am looking something cleaner like POST requests queries and JSON responses
10:10 meshcollider thrasos: no idea sorry, I wouldn't trust a third party API for a wallet in general anyway
10:12 thrasos @meshcollider, OK how would you go about it?
10:13 meshcollider well ideally it would be a standalone SPV wallet I guess
10:14 meshcollider because if you're going to trust an API like one, you might as well just use's app
13:02 dansmith_btc Hi, I was in the middle of -reindex-chainstate when I had to Ctrl+C it, now if I run -reindex-chainstate again, it starts from the very beginning. Is there a way to resume it from where it left off?
13:47 rav3nn hi, do I need synced node first to use zeromq on my daemon ?
17:54 arubi anybody knows how to load a modified firmware image on the digital bitbox? I built the binary but (no surprise) it doesn't like how it's unsigned
17:55 arubi there's also a "debug" option for firmware loading, but still : "ERROR: invalid firmware signature"
18:00 arubi there is also an undocumented "-noreadsig" flag in the dbb-cli application. when trying to append the "debug" signature (all zeros) to my unsigned firmware and loading it with that flag set to true using the -cli, then it doesn't show the signature on screen when it tries the upgrade, but still fails the same
18:01 arubi in "" there is a comment "Invalid firmware cannot be run." , right, but how am I supposed to test stuff then?
18:34 arubi ^ needs special bootloader. :(
19:02 dansmith_btc Hi, why does -reindex-chainstate consume about 2ghz of my cpu? does it verify signatures or something? I thought there shouldnt be anything CPU-intensive
19:04 mahamoti when a node solves a POW problem, how is the completed block forwarded around to all other nodes in the network? The node can send to all its known peers, and every peer could forward to all their known peers, but how does this not result in an infinite propagation through the network?
19:15 reardencode mahamoti: just like you said, every node sends it to every peer, unless they know for sure that peer already has it (because nodes keep track of their peers' heights)
19:20 mahamoti reardencode: so...whenever a node creates (or receives) a new block, it then queries all known peers for their height, and forwards to any peer with height < the new block number?
19:24 reardencode mahamoti: it already knows its peers' heights because they tell each other that regularly AFAIK otherwise, yep
19:27 mahamoti reardencode: so are you saying that every X seconds, a peer PUSHES its last known block to all other peers -- and whenever it receives/creates a new block, it then PULLS the last known block from any peer that hasn't reported its block-no in the last Y seconds?
19:32 reardencode mahamoti: I don't know the exact protocol messages that are involved
19:33 reardencode I know that blocks are propagated by receiving nodes to any of their peers who don't already have it
19:33 mahamoti ok
19:34 mahamoti its strange to me that nobody seems to know the basic network architecture
19:34 reardencode mahamoti: what do you mean? many people (myself included) know the network architecture, few know the exact protocol messages, because not many people need to know that
19:39 mahamoti reardencode: dont care about the exact protocol messages...but whether this information is communication via push model or pull model, based on a frequency or based on a trigger, etc, seem to be the basic architecture concepts
19:39 mahamoti communicated*
19:39 reardencode it's pushed, and whenever a new block is received
19:40 reardencode that may be done by the node that receives a new block knowing which peers need it already, or it may be done by it asking those peers if they want it
19:41 mahamoti you said blocks are pushed based on the peer heights, but peer height is basically equivalent to knowledge of last known is peer height communicated via push or pull
19:42 reardencode so now you're back to asking about the specific protocol messages and sequences used to maintain the peer data on each node...
19:43 mahamoti push vs pull is network architecture
19:44 mahamoti i mean you no offense. honestly, im just trying to understand at a conceptual level how information is communicated efficiently and without redundancy
19:45 reardencode yes, I figured that part out - the point is that exactly how a node knows which of its peers need a specific block isn't particularly important compared to the fact that it immediately sends the block to any peers who need it
19:46 reardencode I just looked up the protocol documentation and related BIPs, so it looks like on receipt of a new block the node sends a message to each of its peers announcing that it has a new block, and those peers can then request the block data if they don't already have it.
19:46 reardencode (and this is why people don't need to _know_ the specifics of the protocol, because it's documented for when they do need it
19:47 mahamoti reardencode: thank you for that info. where is the link that you found it from?
19:47 reardencode was most helpful
19:49 mahamoti thanks!
19:53 mahamoti reardencode: im still a little confused though. if, upon receipt of a new block, a node sends a message to all known peers announcing it has a new block, then this would trigger an infinite chain reaction of messages. to make it not infinite, it would have to NOT send the message to peers it knows already have it, which brings us back to the question of how it knows which peers already have it.
19:54 adiabat nodes use inv messages
19:54 reardencode no, because only peers who don't already have it would actually get the new block and announce it further down
19:54 adiabat for blocks and txs
19:54 adiabat you also won't send inv messages about things they've told you about, since obviously they've seen it
19:55 adiabat also you keep track of what inv messages you've sent to nodes, so you don't repeat yourself
19:58 adiabat wiki is a bit old but has the idea:
19:58 mahamoti reardencode: ok, i think i see what you mean
19:58 adiabat There are also now witness_tx types
19:59 mahamoti adiabat: are these inv messages separate from the messages reardencode was talking about?
20:00 adiabat inv messages are what reardencode mentioned
20:00 adiabat it applies not just to blocks, but also txs
20:00 adiabat there are some gotchas though
20:00 adiabat there's a way for nodes to say "send headers!"
20:00 mahamoti you mean for valid transactions that have yet to be included in a block?
20:01 adiabat yes, those are the only transactions which get sent
20:01 adiabat if they're invalid, you can't send them to other nodes, and if they're already in a block, you can't send them either
20:01 adiabat if you've told other nodes "send headers" then they won't send a block inv message, they'll send the block header instead.
20:02 adiabat it's not too big at 80 bytes, and lets you check the work on it without requesting the whole block
20:02 mahamoti adiabat: so if a wallet sends a transaction to one node, that node will notify all its known peers that it has a new transaction?
20:02 adiabat in general, yes
20:02 adiabat however there are new models where it won't
20:02 adiabat called dandelion
20:03 adiabat also it will delay things a bit
20:03 adiabat both of those techniques are to make it harder to track the origin of transactions
20:04 mahamoti adiabat: it seems that it would be against the peers own interests to forward transactions to other nodes, because if it doesnt forward this info, theres a chance that the other nodes won't have enough transactions to fill a block, which would delay their ability to start POW, and increase probability that the first node would beat them to solving the next POW problem
20:05 adiabat ah, for mining nodes you mean
20:05 mahamoti yes
20:05 adiabat yes, if there's a particularly juicy (high fee) tx, mining nodes wouldn't want to let other mining nodes know
20:05 adiabat in practice, most of the nodes on the network with public IPs are not mining
20:06 mahamoti oh really? what is their incentive for operation then?
20:06 adiabat To run bitcoin :)
20:06 adiabat yeah you could be more of a leech and only accept blocks / txs
20:06 adiabat the forwarding part is a bit altruistic
20:07 mahamoti is there an actual different executable for mining nodes vs. non-mining nodes?
20:07 adiabat as a transaction signer however, you want to get your tx out to as many nodes as possible
20:07 adiabat no, same software
20:07 adiabat well. Miners may recompile, change things, who knows. There's some evidence that they do
20:08 mahamoti so you're saying the majority of bitcoin nodes are running mining software, with the actual mining part disabled, so that they just forward transactions around?
20:08 adiabat that's not how I'd phrase it...
20:09 mahamoti :)
20:09 adiabat also depends on your definition of nodes... if you count SPV clients as "nodes"
20:09 adiabat then that would be the majority
20:10 adiabat but yeah, nodes can mine if you tell them to; mining is "easy" once you've got a fully sync'd node; syncing is the hard part
20:16 mahamoti it seems like a node exists either to be mining, or to act as a wallet. if they are mining, then i dont see the incentive for forwarding uncomfirmed trsnsactions to anyone else, because they would want to save for themselves. if you're a wallet, I also dont see incentive, because once you know your balance, you dont really care about wasting network bandwidth to send stuff to others...assuming everyone isgreedy
20:17 adiabat yeah on first order, there isn't a *direct* incentive to forward txs
20:17 adiabat however, lots of inderect reasons
20:17 mahamoti if you're a wallet, and you generated a transaction, then you'd have an incentive to forward that to all known mining nodes
20:17 adiabat as a wallet, you don't want people to know that your txs came from your node, and your IP address
20:17 adiabat if you only send txs that you signed, it's really obvious which are yours
20:18 mahamoti ah ok, interesting point
20:18 adiabat if you forward everything, then your own txs get lost in the noise
20:18 mahamoti i see
20:19 mahamoti so would you say its commonplace that mining software does not forward uncomfirmed transactions to known peers, but wallet software does?
20:20 adiabat I think most mining nodes are not on the public network, with global listening IPs
20:20 adiabat miners don't want that risk
20:21 adiabat DDoS, etc. So they might run a node behind various firewalls. Also they connect to each other directly with fibre, etc
20:21 mahamoti for the purpose of this discussion, lets ignore mining nodes operating under a mining pool
20:21 adiabat workers like that aren't even nodes generally
20:22 adiabat they just get some work to do and do it, with no knowledge of the blocks or txs
20:23 mahamoti interesting. so what you're saying seems to be confirming what i just said: that mining nodes are greedy, receive transactions but never forward, while the wallet softwares do the major forwarding of the network. yes?
20:32 mahamoti adiabat: whats the general concept behind synching a new full node to the network?
20:33 mahamoti i presume that a node might be able to request blocks from a known peer, but any particular peer would not want to provide an excessive amount of data to synch a new node up
20:33 mahamoti so im curious how that data load would be distributed in practice
20:43 adiabat it's probably power law; I have good internet at MIT and run a node that serves a lot
20:44 adiabat I send out about 100GB / day, 3TB / month.
20:44 adiabat that's too much for most home users but I doubt MIT even notices
20:45 mahamoti from a protocol level i mean
20:46 adiabat nodes have a lot of control over how much they send / receive
20:47 mahamoti so do you request specific blocks individually, or do you request a batch of blocks?
20:47 adiabat you send a getdata message with the block hash
20:47 adiabat you can send getdata with a bunch of block hashes I guess, then they'll send a bunch of blocks
20:48 mahamoti if i start up a new full node, whats the algorithm that this node would likely use to try to download all the blocks it needs. does it make a bunch of requests in parallel to all known peers, or go sequentially or what
20:48 adiabat I'm not sure, it's implementation dependent, and it's changed a bunch
20:48 adiabat basic idea is get all the headers first
20:49 mahamoti well new headers are being added all the time, so you cant exactly get all headers first
20:49 adiabat check all the PoW, then go through each header, request the block, parse all the txs, modify utxo set, and continue to next block
20:49 adiabat you can get all the headers in a few seconds
20:49 mahamoti oh really
20:50 mahamoti so the header contains just what...the block hash and the prev hash?
20:51 adiabat most of this is in the wiki
20:51 adiabat er, bitcoin reference
20:51 adiabat
20:52 mahamoti thanks, looks like a good reference for me
21:22 contrapumpkin is supposedly the only block that violates bip16, but I can't find any information on how/why it violates it
21:22 contrapumpkin (going by
22:28 thelazycoder I am working on building a pretty sizeable bitcoin management system, And I needed to get some testnet bitcoins from someone. Does anyone know an easy way to get a lot of tBTC ? Thanks in advance.
22:29 contrapumpkin thelazycoder: there are faucets
22:32 thelazycoder Yeah, most only give out a bit at a timeā€¦ Unfortunately my developer lost the private key of the wallet he had been playing with and we had accumulated into. He didnt think it would be a big issue until he mentioned to me that he got rid of it, and now he want to test the larger transaction logistics, and have only a few btc
22:32 thelazycoder tbtc*
22:47 mahamoti do full nodes synchronize in reverse order?
22:48 mahamoti ie, do they wait to hear a report of a block, then request the block with hash mentioned from the previous block, etc, all the way back? or do they synchronize from the start forward?
22:52 mahamoti i guess not
22:54 mahamoti but im confused: suppose there is a node that was fully synched up to block N. For some reason, it doesn't get a report of block N+1, but then it gets a report of block N+2. When it looks at the prevous hash of block N+2, it clearly does not block N. Whats the process to catch up?
23:11 luke-jr thelazycoder: address?
23:32 reardencode mahamoti: it can request the next block by hash from any of its peers
23:42 thelazycoder luke-jr: mhGBQCsTPxdhHE7DzgGzLL5wosRJ6sgugy
23:42 thelazycoder Thank you for whatever you can spare :) Much appreciated.
23:59 luke-jr thelazycoder: when/if you decide you're done and plan to destroy the wallet, you can return any funds left to 2N2U9wWjQvzqTwwmeZTAuUqA6fR2rQkS3Vz