Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

[Michael Wozniak]

It’s in my logs:

2014-07-28 02:00:24 receive version message: /Satoshi:0.9.2/: version 70002, 
blocks=302684, us=**:8333, them=0.0.0.0:0, peer=5.9.93.101:33928


On Jul 27, 2014, at 10:45 PM, Gregory Maxwell  wrote:

> On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd  wrote:
>> Anyway, just goes to show that we need to implement better incoming
>> connection limiting. gmaxwell has a good scheme with interactive
>> proof-of-memory - where's your latest writeup?
> 
> Or its a complete snipe hunt, I'm unable to find any nodes with it
> connected to them. Does anyone here have any?
> 
> Last discussion on the measures for anti-global-resource-consumption
> was at https://bitcointalk.org/index.php?topic=310323.0  but it hasn't
> seemed to be a huge issue such that adding more protocol surface area
> was justified.
> 
> --
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls. 
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 38 NFC normalisation issue

[Michael Wozniak]

I have a python implementation that seems to pass this test vector:

https://github.com/wozz/electrum/blob/bip38_import/lib/bip38.py#L299



On Jul 15, 2014, at 9:19 AM, Andreas Schildbach  wrote:

> I think generally control-characters (such as \u) should be
> disallowed in passphrases. (Even the use of whitespaces is very
> questionable.)
> 
> I'm ok with allowing pile-of-poo's. On mobile phones there is keyboards
> just containing emoticons -- why not allow those? Assuming NFC works of
> course.
> 
> 
> On 07/15/2014 03:07 PM, Eric Winer wrote:
>> I don't know for sure if the test vector is correct NFC form.  But for
>> what it's worth, the Pile of Poo character is pretty easily accessible
>> on the iPhone and Android keyboards, and in this string it's already in
>> NFC form (f09f92a9 in the test result).  I've certainly seen it in
>> usernames around the internet, and wouldn't be surprised to see it in
>> passphrases entered on smartphones, especially if the author of a
>> BIP38-compatible app includes a (possibly ill-advised) suggestion to
>> have your passphrase "include special characters".
>> 
>> I haven't seen the NULL character on any smartphone keyboards, though -
>> I assume the iOS and Android developers had the foresight to know how
>> much havoc that would wreak on systems assuming null-terminated strings.
>> It seems unlikely that NULL would be in a real-world passphrase entered
>> by a sane user.
>> 
>> 
>> On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn > > wrote:
>> 
>>[+cc aaron]
>> 
>>We recently added an implementation of BIP 38 (password protected
>>private keys) to bitcoinj. It came to my attention that the third
>>test vector may be broken. It gives a hex version of what the NFC
>>normalised version of the input string should be, but this does not
>>match the results of the Java unicode normaliser, and in fact I
>>can't even get Python to print the names of the characters past the
>>embedded null. I'm curious where this normalised version came from.
>> 
>>Given that "pile of poo" is not a character I think any sane user
>>would put into a passphrase, I question the value of this test
>>vector. NFC form is intended to collapse things like umlaut control
>>characters onto their prior code point, but here we're feeding the
>>algorithm what is basically garbage so I'm not totally surprised
>>that different implementations appear to disagree on the outcome.
>> 
>>Proposed action: we remove this test vector as it does not represent
>>any real world usage of the spec, or if we desperately need to
>>verify NFC normalisation I suggest using a different, more realistic
>>test string, like Zürich, or something written in Thai.
>> 
>> 
>> 
>>Test 3:
>> 
>>  * Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK
>>UPSILON WITH HOOK , COMBINING
>>ACUTE ACCENT , NULL
>>, DESERET CAPITAL LETTER LONG I
>>, PILE OF POO
>>)
>>  * Encrypted key:
>>6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
>>  * Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
>>  * Unencrypted private key (WIF):
>>5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
>>  * /Note:/ The non-standard UTF-8 characters in this passphrase
>>should be NFC normalized to result in a passphrase
>>of0xcf9300f0909080f09f92a9 before further processing
>> 
>> 
>> 
>> 
>>
>> --
>>Want fast and easy access to all the code in your enterprise? Index and
>>search up to 200,000 lines of code with a free copy of Black Duck
>>Code Sight - the same software that powers the world's largest code
>>search on Ohloh, the Black Duck Open Hub! Try it now.
>>http://p.sf.net/sfu/bds
>>___
>>Bitcoin-development mailing list
>>Bitcoin-development@lists.sourceforge.net
>>
>>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
>> 
>> 
>> 
>> --
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> 
>> 
>> 
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
> 
> 
> 
> 

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Michael Wozniak]

Multiple parameters is currently undefined as far as I can tell.  Should the 
client take the first, last, or ignore it completely if there are multiple of 
any parameter?  I think that’s the point of the parameter pollution discussion, 
which will define it one way or the other.

I’m only familiar with the Electrum implementation, which is currently checking 
for any duplicate parameters and treating the entire URI as invalid if 
duplicate parameters exist (following the parameter pollution suggestions).

-
Michael Wozniak

On Jul 1, 2014, at 10:59 AM, Andreas Schildbach  wrote:

> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
> advocate for a simple array parameter name, like rs= ("plural" of r).
> Length really does matter for QR codes.
> 
> I'm fine with either multiple r= params or exactly one r= plus zero to
> many r[]= params. Although I think it is a violation of the (current)
> spec to choke on more than one r= parameters, I admit that bitcoinj is
> currently implemented that way. (We could however fix this in a
> maintenance release.)
> 
> However, r= should also allow all other protocols, exactly like any of
> the r[]= params. I don't think we should do a distinction here. Also
> because of backwards compatibility to the status quo.
> 
> 
> On 07/01/2014 03:03 PM, Alex Kotenko wrote:
>> In my mind it's not like the client's phone is going all directions at
>> the same time. There should be a priority method and fallback method(s).
>> ​And I ​see p2p radio as priority, and web as fallback, and BIP21 in the
>> end as always-working-default.
>> 
>> ​So I'm keeping support for it all while want to be able to provide best
>> user experience. 
>> Mike, a while ago in ​this thread you've described contactless cards
>> user experience. I'm also using contactless cards often, and what I'm
>> aiming at is creating same level of user experience for Bitcoin users. 
>> 
>> Encryption over bluetooth is a matter to worry about, and we will
>> introduce that, but we need to sort out more low level problems first
>> before coming into that stage. 
>> 
>> 
>> So, the backwards compatibility is a good issue Michael pointed out. 
>> While processing of multiple "r" parameters is indeed uncertain (since
>> there is no RFC for that various implementations may behave
>> differently), the array solution is somewhat better. The array parameter
>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
>> alongside. And if particular implementation understands the array
>> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
>> use only usual "r=". 
>> 
>> This doens't work though for cases where particular implementation
>> understands array construct but doesn't work well with repeating
>> parameters, since it will see two repeating "r" - an array and a string.
>> I don't have a solution for that atm. 
>> 
>> 
>> If add completely new parameter to solve this we will need to make it an
>> array straight away to address upcoming issues with accommodating other
>> protocols. 
>> And then I would also modify existing BIP72 to strictly define "r=" as
>> "http(s)" ​only ​parameter, while all other protocols (bluetooth, WiFi
>> Direct, ultrasound, chirp etc) should go to the new array parameter.
>> 
>> 
>> ​
>> 
>> 
>> --
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> 
>> 
>> 
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
> 
> 
> 
> --
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> ___
> Bitcoin-development mailing list
>

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Michael Wozniak]

I think it makes more sense to not add a duplicate parameter.  Current 
implementations will break if multiple r parameters are used (either reject the 
URI completely, or do something undefined).  If a new parameter is used, then 
the current implementations will just ignore it if they don’t support it.

-
Michael Wozniak

On Jul 1, 2014, at 5:48 AM, Andreas Schildbach  wrote:

> On 07/01/2014 10:18 AM, Mike Hearn wrote:
>>​However it's not ideal at the moment. Basically the main problem is
>>that in the BIP72 there is no way to provide a fallback alternative
>>URI for payment request fetch if client wallet supports BIP70 but
>>doesn't not support fetching over bluetooth or bluetooth connection
>>fails for any reason. 
> 
> I think the way to go here is using multiple r= parameters.
> 
>> So the idea here is that the recipient wallet both uploads to the
>> internet and exposes the payment request over Bluetooth simultaneously,
>> then let's the sending wallet pick whatever radio layer works best in
>> its current conditions?
> 
> Either that, or just use the other ones as a fallback. Currently,
> Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=
> URL fails.
> 
>> I think having multiple r= params is reasonable, but the Bluetooth
>> support is not specced in any BIP anyway. And if it were to be, people
>> would point out the lack of link-layer encryption.
> 
> Its "specced" in code and implemented by several parties. I think its
> clear that link-layer encryption has to be an add-on to the current
> unencrypted connection, just like HTTPS is on top of HTTP. Anyway,
> that's unrelated to the question of how to provide fallback URLs.
> 
> One more thought: We have a similar problem with the BIP70 payment URL.
> It doesn't allow for fallbacks either. I brought this issue up in the
> discussion phase of BIP70, but it was dismissed I think because of
> "let's not get too complex for the first version". The fallback here is
> to send the transaction via the P2P network.
> 
> (I think BIP70 via P2P radio will get used more often in future. I plan
> to look into Bluetooth 4 LE as soon as I have devices and wanted to try
> WIFI Direct again also. I hope we can skip BIP72 for both of those, but
> lets see.)
> 
> 
> 
> --
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] DNS seeds unstable

[Michael Wozniak]

You would set it up as a forwarder, not as a zone transfer to bind.  That 
should proxy the request every time and only cache based on any TTL that’s set 
in the response.

Here’s an example of how it could work:
https://planet.jboss.org/post/setting_up_a_forwarding_dns_server_or_dns_proxy_with_isc_bind


On May 19, 2014, at 7:49 PM, Jeff Garzik  wrote:

> On Mon, May 19, 2014 at 4:36 PM, Robert McKay  wrote:
>> It should be possible to configure bind as a DNS forwarder.. this can
>> be done in a zone context.. then you can forward the different zones to
>> different dnsseed daemons running on different non-public IPs or two
>> different ports on the same IP (or on one single non-public IP since
>> there's really no reason to expose the dnsseed directly daemon at all).
> 
> Quite the opposite.  dnsseed data rotates through a lot of addresses
> if available.  Using the bind/zone-xfer system would result in fewer
> total addresses going through to the clients, thanks to the addition
> of caching levels that the bind/zone-xfer system brings.
> 
> That said, if the choice is between no-service and bind, bind it is ;p
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
> 
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] DNS seeds unstable

[Michael Wozniak]

I’m not familiar with how the daemon works, however could you set up two 
daemons listening local on different ports and with a separate daemon or normal 
dns server that proxies incoming queries to either domain? I don’t know if 
standard DNS servers would support that, or if you would need a custom proxy 
application.

-
Michael Wozniak


On May 19, 2014, at 4:14 PM, Alex Kotenko  wrote:

> Hmm, I've mostly setup what's promised, testing DNS seeds now. There is one 
> problem I see that I can't really solve myself. 
> This dnsseed daemon cannot serve more than one name at once, which means that 
> I cannot serve testnet and mainnet seeds off one daemon instance which means 
> I need to buy two IP addresses for it. That's unfortunate as it needs much 
> more spendings from me to operate, second IP address will cost nearly as much 
> as the server itself. 
> 
> ​Can anybody help with this? I cannot into C++ to fix that myself.   ​
> 
> 
> Best regards, 
> Alex Kotenko
> 
> 
> 2014-05-17 13:39 GMT+01:00 Andreas Schildbach :
> On 05/17/2014 02:02 PM, Alex Kotenko wrote:
> 
> > So, my understanding is that atm we have no working DNS seeds at the
> > testnet3, right? There are two DNS seeds known, of which one is
> > unreachable atm, and another one is giving just one IP address, which is
> > also a dead node.
> 
> Yes, that's my understanding too.
> 
> > If I'll start a DNS seed of my own and make sure it works well, will
> > this help?
> 
> Yes, definately.
> 
> > I've found this DNS seeder daemon
> > <https://github.com/sipa/bitcoin-seeder>, and it seems to be exactly
> > what I need to run a DNS seeder myself.
> 
> Afaik this is what most of the other seeds are using, yes.
> 
> > So if my understanding is correct, I'll setup a DNS seeds for mainnet
> > and for testnet at bitcoin-seed.alexykot.me
> > <http://bitcoin-seed.alexykot.me> and testnet-seed.alexykot.me
> > <http://testnet-seed.alexykot.me>, and also a well connected nodes for
> > mainnet and testnet on the same server.
> > Is this a good plan? Will this all help?
> 
> Sound great! Let me know if you've got something to test.
> 
> 
> 
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development