1 2015-10-05 02:50:09 <execute> Hello, wanted to discuss my bip proposal for instant exchange rates URI scheme. I've posted this on the mailing list, too: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011008.html
  2 2015-10-05 02:52:49 <Luke-Jr> execute: I don't get the point
  3 2015-10-05 02:54:53 <execute> Luke-Jr: this sets a standard for presenting forex rates for operators who basically use bitcoin as payment rails
  4 2015-10-05 02:57:16 <Luke-Jr> …
  5 2015-10-05 02:57:43 <PRab> execute: The problem that I see is that both sides of the transaction already need to be online anyway. The sender shouldn't blindly trust the exchange rate in the URI or he/she could get scammed, and the receiver needs to verify that the transaction was actually received.
  6 2015-10-05 02:57:46 <Luke-Jr> execute: you realise bitcoin URIs are basically obsolete, right?
  7 2015-10-05 02:58:41 <PRab> If both people are online, then why not just price the item in bitcoin and leave the fiat currency display up to the wallet.
  8 2015-10-05 03:07:21 <execute> sorry, third world internet problems
  9 2015-10-05 03:09:53 <execute> Luke-Jr: i fail to see how bitcoin URIs are now obsolete, how else would people send bitcoins :-)
 10 2015-10-05 03:10:11 <Luke-Jr> execute: BIP 70
 11 2015-10-05 03:10:34 <dcousens> Luke-Jr: that does not have widespread adoption
 12 2015-10-05 03:10:42 <dcousens> Luke-Jr: at least, I've never once seen it in the wild
 13 2015-10-05 03:10:50 <Luke-Jr> dcousens: BitPay at least uses it
 14 2015-10-05 03:10:52 <PRab> execute: Overall I like the idea of implementing new ideas for bitcoin and bring it to new markets, but I'm not 100% sure that trying to embed exchange rates in the URI is the best idea.
 15 2015-10-05 03:11:40 <Luke-Jr> dcousens: and in any case, whatever weird use case execute is trying to support isn't widespread adopted anyway
 16 2015-10-05 03:11:49 <dcousens> Luke-Jr: agreed
 17 2015-10-05 03:12:14 <Luke-Jr> sounds like a b2b thing, which has no reason to even try to use URIs
 18 2015-10-05 03:12:34 <execute> the weird use case would be bitreserve's wallet, coinbase's instant exchange and rebit.ph (my product)
 19 2015-10-05 03:12:47 <dcousens> whats the thoughts on how lightning users will communicate?
 20 2015-10-05 03:13:09 <Luke-Jr> dcousens: from what I hear, the current method is lame.
 21 2015-10-05 03:13:37 <execute> Luke-Jr:  yes its a b2b thing, no reason why a standard shouldn't be set just because only businesses would need it
 22 2015-10-05 03:13:38 <Luke-Jr> execute: those are programs/services, not use cases.
 23 2015-10-05 03:13:43 <dcousens> is it a back and forth or something you can just post?
 24 2015-10-05 03:13:49 <Luke-Jr> execute: there's no reason for b2b to use URIs ever
 25 2015-10-05 03:13:59 <Luke-Jr> bitcoin URIs*
 26 2015-10-05 03:14:11 <dcousens> Luke-Jr: b2b?
 27 2015-10-05 03:14:20 <Luke-Jr> dcousens: business-to-business
 28 2015-10-05 03:15:03 <Luke-Jr> execute: so set a standard extension to BIP 70 instead
 29 2015-10-05 03:15:55 <execute> use case would be a person (A) in the US with a coinbase account who wants to send to a user (B) in the PH via rebit.ph. with this standard, person A's coinbase wallet would be able to present how much he is spending and how much his recipient would receive in PHP
 30 2015-10-05 03:16:04 <dcousens> Luke-Jr: I wonder if a standard would be useful for those kind of iterative repeating payments where both sides can track i
 31 2015-10-05 03:16:13 <dcousens> A BIP32 public key has its own issues
 32 2015-10-05 03:16:14 <execute> Luke-Jr: yes that is a possibility
 33 2015-10-05 03:16:28 <execute> extending bip 70
 34 2015-10-05 03:16:47 <CodeShark> I still don't really understand why BIP70 needs to be specified in bitcoin :p
 35 2015-10-05 03:16:54 <Luke-Jr> execute: ok, I see no reason not to just do what PRab suggested then and just send a specific bitcoin amount
 36 2015-10-05 03:16:56 <CodeShark> seems like a higher tier protocol
 37 2015-10-05 03:17:06 <dcousens> CodeShark: I think because it went into the client
 38 2015-10-05 03:17:14 <dcousens> otherwise, IMHO, you're right
 39 2015-10-05 03:17:51 <Luke-Jr> the user paying doesn't care how many USD/PH/whatever the recipient will get
 40 2015-10-05 03:18:19 <CodeShark> it's probably better to wait until we have a more mature layered protocol and have worked with multiple use cases before attempting to specify that...but meh :p
 41 2015-10-05 03:18:34 <CodeShark> for now URLs work fine :
 42 2015-10-05 03:18:50 <Luke-Jr> in fact, trying to tell the user what the recipient will receive is liable to phishing attacks
 43 2015-10-05 03:19:05 <CodeShark> URLs via https offer basically the same level of security and are basically already supported everywhere
 44 2015-10-05 03:19:08 <Luke-Jr> I'll think I'm sending 5 BTC, but really it'll be 500 BTC at a 100 BTC:BTC exchange rate -.-
 45 2015-10-05 03:19:36 <dcousens> CodeShark: I think it was meant to be a protection against people installing stupid extensions
 46 2015-10-05 03:20:46 <CodeShark> if you're shopping online and paying with a credit card you're at least as vulnerable to attacks (except that credit cards are reversible)
 47 2015-10-05 03:22:02 <CodeShark> so yes, I suppose the irreversibility and the fact that receiving bitcoin is unregulated could make it more dangerous
 48 2015-10-05 03:22:46 <CodeShark> but still...I don't see it as the weakest link in security
 49 2015-10-05 03:23:23 <CodeShark> anyhow, chances are the entire use model will change drastically...especially with payment channels
 50 2015-10-05 03:25:41 <CodeShark> what we will probably need is a transaction authorization protocol that can be used to add signatures
 51 2015-10-05 03:26:15 <dcousens> CodeShark: yup, 2FA basically
 52 2015-10-05 03:27:38 <CodeShark> and hopefully we can eventually come up with something better than x.509 :)
 53 2015-10-05 03:30:58 <CodeShark> lightning-routable cryptographically generated network addresses :)
 54 2015-10-05 03:34:47 <CodeShark> we should just skip IPv7 and go straight to IPvB
 55 2015-10-05 03:39:24 <CodeShark> IPvB.1 beta :p
 56 2015-10-05 03:44:25 <FredEE> execute, LukeJr, FWIW we rolled out our instant exchange feature with the idea in mind that some sort of protocol would be worked out like what you are discussing
 57 2015-10-05 03:44:33 <FredEE> (Fred from Coinbase here)
 58 2015-10-05 03:46:15 <FredEE> You could do it out of band, but the more protocol level and the more secure the better, obviously
 59 2015-10-05 03:48:05 <FredEE> The problem is, at the end of the day, you can have the endpoint run away with the money/not honor the exchange rate to the end user regardless of the exchange rate that was agreed upon in on chain txn
 60 2015-10-05 03:49:02 <FredEE> So if you're a more legitimate/established company you are probably socially on the hook for losses.  But I think this is an acceptable risk for the functionality you can gain
 61 2015-10-05 03:49:47 <FredEE> It's really the lack of a shared standard/protocol that's inhibiting that from making forward progress atm imo
 62 2015-10-05 03:52:18 <phantomcircuit> FredEE, the interesting thing would be to sign the quotes
 63 2015-10-05 03:53:24 <phantomcircuit> the format doesn't have to be standardized for that since it wont matter 99.99% of the time, only when something goes wrong an an offered quote isn't executable
 64 2015-10-05 03:53:54 <FredEE> On quotes, sure
 65 2015-10-05 03:54:22 <FredEE> That would help, but still one level away from true bitcoin in the sense that when you send someone bitcoin they truly have the value.  Here you are still relying on the third party to honor their quote to the end customer (they control the fiat balance they show the end customer on their centralized site)
 66 2015-10-05 03:55:19 <phantomcircuit> FredEE, ultimately that's always going to be true for anything that isn't bitcoin
 67 2015-10-05 03:55:40 <FredEE> Yep, at least for a while :)
 68 2015-10-05 03:55:53 <execute> i initially wanted to publish this as a sort of suggested standard of parameter language, but seeing as bitcoin already has the BIP mechanism, I thought it would be wiser to do it via a BIP. i know 99% of bitcoin users won't use the standard, but i'm pretty sure any cross border transfer via bitcoin would benefit nonetheless
 69 2015-10-05 03:56:04 <CodeShark> phantomcircuit: or anything that isn't crypto, at least :)
 70 2015-10-05 03:56:25 <FredEE> So, again, becomes a real world counterparty issue.  But pretty small risk in the scheme of things.  From my POV biggest thing is some shared standard everyone can jut agree to to start to create interoperability.
 71 2015-10-05 03:57:14 <execute> i'll look into extending BIP 70, but it would pretty much just incorporate the parameter language i've proposed so i guess my request for discussion is on the technical correctness of such a standard rather than the viability of its use
 72 2015-10-05 03:57:36 <FredEE> execute yeah not sure on the philosophical "should this be in the protocol" part
 73 2015-10-05 03:57:56 <CodeShark> chances are any standards we create today will change soon :p
 74 2015-10-05 03:58:15 <CodeShark> we've only started to scratch the surface of potential use cases
 75 2015-10-05 03:58:21 <execute> FredEE: yes, i totally see that pov. it could be a trade industry standard on top of the bitcoin protocol
 76 2015-10-05 03:59:42 <execute> maliciously crafted URIs are not a security hole of the standard i am proposing, IMO, but rather a trust issue with the entity presenting the URI
 77 2015-10-05 04:00:45 <execute> that is, if I send you a paypal invoice for $1000 instead of the $100 you owe me and you pay it, is not the problem of the paypal "protocol" but a trust problem between the invoicer and invoicee
 78 2015-10-05 04:01:54 <execute> CodeShark: on standards changing, my point of view is that its up to us to set a flexible enough foundation, akin to how html 1-5 progressed
 79 2015-10-05 04:04:00 <phantomcircuit> execute, hehe im not sure we want to replicate the html standardization process :)
 80 2015-10-05 04:04:11 <execute> phantomcircuit: haha, ok bad example
 81 2015-10-05 04:11:46 <Luke-Jr> execute: feel free to publish a BIP; I was just commenting as requested :p
 82 2015-10-05 04:12:28 <execute> Luke-Jr: yes, appreciate your comments of course :-) will look into possibly extending BIP 70 too
 83 2015-10-05 07:56:30 <btcdrak> Luke-Jr: looks good, was unable to verify the hashes in Manifest, but otherwise all looks good. That a pretty nice patchset btw.
 84 2015-10-05 07:57:07 <Luke-Jr> btcdrak: ljr?
 85 2015-10-05 07:57:14 <btcdrak> yes
 86 2015-10-05 07:58:15 <Luke-Jr> btcdrak: I try to get a reasonable set of PRs in it for each release ;)
 87 2015-10-05 07:59:13 <btcdrak> it's a pretty sane way of doing things and super easy. Now it's just a shame I dont run Gentoo...
 88 2015-10-05 07:59:23 <Luke-Jr> heh
 89 2015-10-05 07:59:25 <btcdrak> need something like this for Debian/Ubuntu
 90 2015-10-05 07:59:31 <Luke-Jr> could always build it from git too
 91 2015-10-05 07:59:53 <Luke-Jr> oh, and I have binaries up in http://luke.dashjr.org/programs/bitcoin/files/bitcoind/luke-jr/0.11.x/0.11.0.ljr20150711/
 92 2015-10-05 08:00:09 <Luke-Jr> gitian binaries*
 93 2015-10-05 08:04:05 <deego> Looking here: https://bitcoin.org/en/download  I see that the downloads have binaries. What's the way to get the source? go to git?
 94 2015-10-05 08:04:35 <deego> iirc, it used to be source that you'd have to build..
 95 2015-10-05 08:05:21 <Luke-Jr> deego: click "Source code"?
 96 2015-10-05 08:05:45 <Luke-Jr> also move to #bitcoin for this
 97 2015-10-05 08:05:59 <deego> Luke-Jr: ah, thanks
 98 2015-10-05 08:06:01 <deego> ok
 99 2015-10-05 08:41:37 <CodeShark> why is qa/pull-tester/rpc-tests.py always getting modified when I build>
100 2015-10-05 08:41:38 <CodeShark> ?
101 2015-10-05 11:39:08 <drawing_under> Hi guys why is it october 2015 and transaction malleability is still a thing?
102 2015-10-05 11:40:19 <kinlo> it never was a thing in the first place
103 2015-10-05 11:40:42 <sturles> It is a thing, because it is a showstopper for Lightning.
104 2015-10-05 11:40:47 <kinlo> it was just mtgox using something that has been known since day one as excuse
105 2015-10-05 11:40:53 <sturles> There is one more issue to be solved.  The BIP is there, but everything is on hold due to the block size fight.
106 2015-10-05 11:41:03 <drawing_under> kinlo transaction malleability is still a thing trust me
107 2015-10-05 11:41:19 <drawing_under> it happened to me a couple of times in the past week alone
108 2015-10-05 11:41:43 <kinlo> drawing_under: its a known quirk of bitcoin, it's only a thing if you're not handling it correctly
109 2015-10-05 11:42:12 <sturles> kinlo: How do you suppose Lightning should handle malleability correctly?
110 2015-10-05 11:42:42 <drawing_under> Sure, you can prevent 0 confirmations spend using the  spendzeroconfchange but how can you use a wallet then to make more than a transaction every 10 minutes
111 2015-10-05 11:43:03 <kinlo> this is #bitcoin-dev, not #lightning-dev imho :)
112 2015-10-05 11:43:21 <drawing_under> sturles maybe they will design the lightning protocol with this in mind... not allowing a node to modify the tx
113 2015-10-05 11:43:27 <sturles> Right now maleability is a scaleability showstopper.
114 2015-10-05 11:44:00 <sturles> drawing_under: Make sure you have more than one output to spend from.
115 2015-10-05 11:45:04 <drawing_under> so I should fund like 5 different addresses under the same wallet so I can be sure of that? sounds silly to me
116 2015-10-05 11:45:38 <drawing_under> or better yet write a custom wallet implementation and avoid bitcoind altogether
117 2015-10-05 11:45:48 <drawing_under> that sounds like fun
118 2015-10-05 11:47:13 <sturles> It doesn't have to be different addresses.  This is basic knowledge.  -> #bitcoin
119 2015-10-05 11:47:58 <sturles> Bitcoin Core won't spend 0 confirmation outputs if it can avoid it.
120 2015-10-05 11:48:19 <drawing_under> Yes but it usually can't in my use case
121 2015-10-05 11:48:45 <drawing_under> aka I deposit funds, then send from it multiple times
122 2015-10-05 11:49:13 <drawing_under> each time there's a change address generated that takes the difference so it always has 0 confs after each spend
123 2015-10-05 11:49:14 <sturles> -> #bitcoin
124 2015-10-05 14:46:20 <davec> What's the preferred mechanism for feedback on BIP99?
125 2015-10-05 15:25:40 <morcos> gmaxwell and others: https://gist.github.com/morcos/79966b4529834b514f3f
126 2015-10-05 15:26:04 <morcos> i promised i'd post my proposed new limits here first.  they are 25 tx and 100 kb total size for both ancestor and dependent txs
127 2015-10-05 15:26:14 <morcos> i have more stats than i included in the email if anyone is interested
128 2015-10-05 15:26:36 <morcos> but the total size limit almost never comes into effect, so it seemed reasonable to me to take it all the way down to the standard tx limit
129 2015-10-05 15:26:46 <morcos> ran by sdaftuar already
130 2015-10-05 15:26:59 <jgarzik> morcos, like it.  I would say >100k for lower limits... 200k & 25
131 2015-10-05 15:27:18 <jgarzik> tx count is good but you might have a couple large TXs consolidating UTXOs
132 2015-10-05 15:28:31 <morcos> so the 100kb limit (for packages) would have been hit by less than 1% of txs in April/May
133 2015-10-05 15:28:34 <jgarzik> morcos, "based on historical data" - that info seems a bit odd; was that a guess based on what is in the block, or was is it truly historical data from mempool observation?
134 2015-10-05 15:28:51 <morcos> truly historical data
135 2015-10-05 15:29:21 <morcos> i guess from only one node, but shoudl be a representative sample
136 2015-10-05 15:29:27 <jgarzik> morcos, 6% of transactions confirmed were involved in an in-mempool 25-long chain?
137 2015-10-05 15:29:43 <morcos> 6% of txs accepted into my mempool
138 2015-10-05 15:30:11 <morcos> that number is almost 30% during the stress tests in mid-July
139 2015-10-05 15:30:53 <morcos> i think its likely that existing uses would be slightly inhibited, but i can't think of any reason why the existing use cases would NEED txs that long
140 2015-10-05 15:30:57 <morcos> chains that long
141 2015-10-05 15:31:12 <morcos> but that would be the point of the email i suppose, so someone could argue why they need that
142 2015-10-05 15:31:30 <jgarzik> morcos, (trying to drill down)   "confirmed" is still vague to me :/    You are saying that a single mempool contained 25-count 100% unconfirmed chain at a single snapshot point in time X?
143 2015-10-05 15:31:53 <jgarzik> 6% consistently had this condition over time for entire month?
144 2015-10-05 15:32:34 <morcos> ok yeah let me be precise
145 2015-10-05 15:32:48 <morcos> of all the txs that were accepted into this nodes mempool over the months of april and may
146 2015-10-05 15:33:34 <morcos> 4.8% of them already had at least 25 unconfirmed ancestors still in the mempool at the time they entered
147 2015-10-05 15:33:59 <jgarzik> and those counted also exited mempool eventuallys?
148 2015-10-05 15:34:02 <morcos> 5.8% of them (mostly the same ones) caused one of their ancestors still in the mempool to currently have at least 25 unconfirmed descendants in the mempool
149 2015-10-05 15:34:03 <jgarzik> *eventually
150 2015-10-05 15:34:39 <morcos> i didn't record the extent to which these individual txs were eventually mined, but i have all their txid's if you want them.. :)
151 2015-10-05 15:34:46 <jgarzik> long chains of crap is to be expected
152 2015-10-05 15:34:55 <jgarzik> not a real use case though :)
153 2015-10-05 15:34:57 <morcos> i believe that they were probably all mined, historically crap has gotten mined
154 2015-10-05 15:35:02 <morcos> agreed
155 2015-10-05 15:35:18 <morcos> so the fact they were included in a block wouldn't tell us much
156 2015-10-05 15:35:33 <jgarzik> long chains primarily emerge precisely _because_ they are crap and are not getting mined
157 2015-10-05 15:35:59 <morcos> its possible, but i would be surprised, that many of these txs were booted because a conflicting tx was mined
158 2015-10-05 15:36:12 <jgarzik> In any case, +100 on lower limits
159 2015-10-05 15:36:15 <jgarzik> ACK
160 2015-10-05 15:36:32 <morcos> yeah its almost like it makes us want them more right?
161 2015-10-05 15:36:56 <morcos> ok thx... i'll wait if there is more feedback a couple hours then post to list
162 2015-10-05 15:38:24 <jgarzik> kudos to jtimon for trying to be productive
163 2015-10-05 18:04:00 <ProfMac> I am writing a very tiny IPv6 multicast client/server heartbeat program.  It is not unlike http://www.cs.ucsb.edu/~almeroth/classes/W01.176B/hw2/examples/udp-server.c  It could have a very tiny application added to it, such as sending the time of day, or exchanging locally interesting addresses.  This is self study for me on the topics of C, UDP, IPv6, and multicast.  Is there any tiny task that might interest the bitcoin community?
164 2015-10-05 19:01:14 <btcdrak> ping Luke-Jr
165 2015-10-05 19:36:35 <jcorgan> the bitcoin-dev list must be what it is like inside the halls of the US Congress
166 2015-10-05 19:52:44 <btcdrak> jcorgan: it should get better once we have the new list.
167 2015-10-05 19:52:50 <btcdrak> warren: any update on that?
168 2015-10-05 22:11:18 <Luke-Jr> btcdrak: pong