< CodeShark>
this sounds more serious than just potentially fund-losing
< dcousens>
CodeShark: question is, where do you even post it?
< dcousens>
I'm thinking about writing it up for bitcoinjs-lib, bitcore etc
< CodeShark>
contact the wallet authors?
< dcousens>
CodeShark: hard to tell who uses JS under the hood
< dcousens>
I know CoPay does, and it doesn't use XWalk
< dcousens>
I know BlockTrail does (already contacted, their doing a migration now, Ruben helped discover this when users reported mismatched key derivations)
< dcousens>
Basically every webwallet [when run on android 4.3 w/o a new version of Chrome]
< dcousens>
(Assuming* they use typed arrays)
< CodeShark>
all browser controls in android in all apps use this same web view control?
< dcousens>
Typically the SDK has 1 WebView implementation, and depending on certain factors, it may or may not be the same one as the phones default browser
< CodeShark>
and the correct behavior should be? crashing? truncation?
< dcousens>
CodeShark: %256
< dcousens>
mod 256
< CodeShark>
so the least significant byte
< dcousens>
aye
< dcousens>
that is the *defined* behaviour
< CodeShark>
doesn't sound good - are the android folks working on a patch?
< dcousens>
CodeShark: haven't been in contact with them yet, but I'm not sure what the dynamics/communication pathways are there yet.
< dcousens>
CodeShark: any ideas on who you would contact for that?
< CodeShark>
I wish I had some suggestions - unfortunately I don't know how to help
< dcousens>
like, if they could update those web views
< dcousens>
Wouldn't they juts update the entire android anyway?
< dcousens>
I get the feeling the best bet is to just put out the notices to the major JS libs and maybe ping in a few more wallet devs
< CodeShark>
that's what one would think...but I'm guessing there could be compatibility issues or lack of device support that might prevent people from updating the entire android. admittedly, I'm no android expert
< CodeShark>
my android development experience consists of a handful of toy apps :p
< wumpus>
yes, lack of device support for updates is very common, unfortunately
< dcousens>
I'm just glad I deployed the bitcoin apps I work on with XWalk (compatibility, 20mb+ to your app size, but guarantees a consistent (and new) web view across all versions)
< wumpus>
so that's why all those apps are so large nowadays :-) I have a very old, severly resource-challenged smartphone and every time there's application updates available, I need to remove at least one application to make room.
< wumpus>
at some point it's going to be unusable and I'm not actually sure I'm going to get a smartphone again
< CodeShark>
is there still another option? pay phones? :)
< CodeShark>
remember those things?
< dcousens>
CodeShark: rpi with a GSM module? haha
< wumpus>
well there's still cheap 'dumbphones' available that can only call and text. At least when I checked a year ago or so. For old people, like me :-)
< dcousens>
wumpus: but are they actually 'dumb'? :P
< wumpus>
good point. So that leaves... someone have an old Nokia 3310 laying around... ? :P
< CodeShark>
I think I still have a Motorola StarTak somewhere
< CodeShark>
lol
< CodeShark>
s/StarTak/StarTAC
< CodeShark>
from like the mid 1990's
< wumpus>
heh
< CodeShark>
I remember when I got my first cell phone - a car phone - the transciever took up like half the trunk :p
< dcousens>
wumpus: whats the concern anyway, NSA paranoia? :P
< wumpus>
I had a similar one, maybe even the same
< wumpus>
CodeShark: awesome
< wumpus>
dcousens: not so much the NSA, but exploiting vulnerabilities isn't exactly only NSA territory, especially in old software given the lack of vendor support for keeping software up to date and secure
< wumpus>
the ecosystem is a mess. Would be great to have a phone that's more like a normal PC. I think that's what Nokia tried with N900, shame it didn't go very far.
< CodeShark>
built-in obsolescence is a feature of all modern appliances :)
< wumpus>
but not that fast
< wumpus>
anyhow, this has veered very far off topic, sorry for that
< morcos>
interestingly this "attack" does not depend only on chains of transactions. i've had a node up running my new low limits since yesterday and its up to 178M of mempool usage itself
< stonecoldpat>
sipa: ah i see, thats quite annoying! thanks though :)
< paveljanik>
example tx: 895e6500146b67dc668eb73ce490cdf6c49ad2a5682a599b8f12fa97952f2400
< Luke-Jr>
hmm
< Luke-Jr>
so to bring BIP70 to bitcoind probably means replacing that with libcurl or smth
< Luke-Jr>
or maybe it could just use QtNetwork as an optional dep
< paveljanik>
100inputs, 1 output, fee 15000
< wumpus>
Luke-Jr: evhttp would work just as well - but I don't think moving it to bitcoind would make a lot of sense, at least the fetching part. Parsing/processing of payment messages might.
< stonecoldpat>
Luke-Jr: I dont know if it has QtNetwork (if its related to the Q classes), for example QByteArray is used for the payment data structure, but that isn't accessible without core
< stonecoldpat>
s/core/qt
< stonecoldpat>
wumpus: thats what i was hoping to do, verify payment messages using bitcoind
< wumpus>
then again, I think it'd be better to make a BIP70 handling library that is completely independent of bitcoind
< Luke-Jr>
wumpus: probably
< Luke-Jr>
BIP70 adoption is not going fast enough IMO
< wumpus>
that would have been better, it could be done pretty much independent of any specific wallet / frontend implementation
< wumpus>
and also include functionality to make payment protocol messages
< wumpus>
an example could interface to bitcoind and handle BIP70 either as client as server - as long as it is clear that it is a layer on top
< kanzure>
what is the measure of bip70 adoption?
< stonecoldpat>
wumpus: ah you mean like another module, but it interacts with bitcoind to do the signing? (so builds payment message, and then calls rpc of bicoind to create and sign transaction?)
< stonecoldpat>
at the moment, its supported by bitpay and coinbase, so 100k+ merchants should be using it
< wumpus>
stonecoldpat: yes
< randy-waterhouse>
"should be"
< Luke-Jr>
it's very hard for non-merchants to use, though
< kanzure>
sounds like coinbase/bitpay might have internal metrics around adoption, but other than that we don't know? just curious what Luke-Jr is estimating from because would be useful.
< Luke-Jr>
kanzure: also, most wallets besides Core don't support sending to it
<@sipa>
afaik, nearly no wallets support creating payment requesrts...
< stonecoldpat>
Luke-Jr: I wouldn't say thats entirely true, core, bitcoinj, breadwallet, hive, electrum support sending payments to a payment request, but as sipa said there is no wallet that supports creating a request
< kanzure>
wallet/implementation adoption is much easier to measure than user usage. so i'll give you that.
< Luke-Jr>
stonecoldpat: oh? didn't know Electrum did for example
< stonecoldpat>
Luke-Jr: they seem to have code in their github for it (ive never used electrum)
< stonecoldpat>
Luke-Jr: actually, for electrum it may only be for creating a payment request, sorry for that.
< stonecoldpat>
wumpus: if it would help, I can look into making a module for bip70 that interfaces with bitcoind
< Luke-Jr>
stonecoldpat: as wumpus said, an external library would probably be best ;)
< wumpus>
stonecoldpat: well I would write it generally, as a library; then one of the examples could be interfacing with bitcoind
< wumpus>
stonecoldpat: I think binding it to bitcoind specifically reduces the usefulness, people may want to use other wallets, or even without a wallet (just a database of addresses, of which one is dealt out for every now payment)
< stonecoldpat>
wumpus: ah okay, yes that makes sense. i'll have a look into getting a library made then. This is actually better than what I planned to do, now i don't have to worry about messing with core code which should be easier. :)
< wumpus>
stonecoldpat: :)
< GitHub83>
[bitcoin] sipa opened pull request #6776: Support -checkmempool=N, which runs checks once every N transactions (master...fraccheck) https://github.com/bitcoin/bitcoin/pull/6776