Re: [bitcoin-dev] Unique node identifiers

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Reposting this response since this made it neither to distribution nor
to the moderation archive.


-  Forwarded Message 
Subject: Re: [bitcoin-dev] Unique node identifiers
Date: Wed, 8 Mar 2017 18:59:42 -0800
From: Eric Voskuil 
To: Pieter Wuille 
CC: Jonas Schnelli , Bitcoin Protocol Discussion
, Libbitcoin Development


On 03/08/2017 05:55 PM, Pieter Wuille wrote:
> On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil 
> wrote:
>> On 03/08/2017 03:12 PM, Pieter Wuille wrote:
>>> In that way, I see BIP150 as an extension of IP addresses,
>>> except more secure against network-level attackers. If you
>>> believe the concept of people establishing links along existing
>>> trust lines is a problem, you should be arguing against
>>> features in Bitcoin software that allows configuring preferred
>>> IP addresses to connect to as well (-addnode and -connect in
>>> Bitcoin Core, for example).
>> 
>> Weak identity is insufficient to produce the problem scenario
>> that is at the heart of my concern (excluding people). It is this
>> "[same] except more secure" distinction that is the problem. You
>> brush past that as if it did not exist.
> 
> So you're saying that a -onlyacceptconnectionsfrom=IP option
> wouldn't be a concern to you because it can't exclude people? Of
> course it can exclude people - just not your ISP or a state-level
> attacker.

You seem to look at this from only one perspective. Put yourself on the
other end of the wire (web wallets, APIs, exchanges, miners). Is an IP
address strong enough for them to prove to the state that they are
getting connections only from authorized "customers" that they know? Is
it sufficient for them that they may think they know their customer but
in reality it may be some ISP spoofing their customer (or some state)?
Obviously it is not sufficient, which is why IP addresses do not produce
this problem. They will need another mechanism, and BIP150 just happens
to be it.

> Please, Eric. I think I understand your concern,

I assume you do. The question is ultimately whether the P2P protocol is
an anonymous network of public information or it is a private network
(of private information). Too many arguments have been based on the idea
that the information is private (bloom filters, tainting). There are
anonymizing networks, Bitcoin P2P is not one of them.

Consensus rules exist to validate information obtained from the
anonymous public. That includes your ISP and the state. The rules
validate everything that matters except whether there is a stronger
chain - and seeing the strongest chain cannot be guaranteed by
encryption, unless of course we are all strongly tied to the majority
hash power and trust them.

Making the network private so that we can detect denial/disruption of
service is pointless if the the only threat is your own ISP or the state
.

> but this argument isn't constructive either.

I don't need to continue it, I've made my case. It's up to others to
decide whether it has been constructive and what to do with it. I hope
it is understood that I do not question the motivation of anyone involve
d.

> The proposal here is to introduce visible node identities on the 
> network. I think that's misguided as node count is irrelevant and 
> trivial to fake anyway.

Agreed.

> I know that you equate the concept of having verifiable identity
> keys in the P2P with a step towards making every node 
> identifiable,

There is no question that is a step toward making every person who
connects to the more centralized network identifiable. The next step
doesn't even require a software change. A "bitcoin provider" will only
need to provide you a secret to use when connecting. And they have every
reason to want to control this access.

e


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY0b+SAAoJEDzYwH8LXOFOzskH/Ak4xTVWuY02dpA7Xcna0/lG
pLCYz5aFOoCRDokHf2uxtZptNaXMcz5eNBwhxRyXL9cMQ1ewME9nWDiM0x7Is0zC
0haiFW1bi81Tak6ELhA7+BwCQNYH4MBWirFo/T91veiaOx3Ttn5Nf8p+kYfbcvCC
eANxCsPM8s9ul7CzpfDtO+K7S9rV/mEZYDsogKT7P3JPbgH4kRWcyt1AcFfw74LU
Z68XkZL6aCl+nymupZR72z/oxykljjPegkZxIkoguNSybZR9dOLRRmkyiPplX+OU
szOlGnwuePxOq/BQE8ouAlfSgAmBHqMj6lnYCgbBUIWrTzjYlpZVA4dWTj/FVCM=
=um+z
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A BIP proposal for segwit addresses

[Peter Todd via bitcoin-dev]

On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitcoin-dev 
wrote:
> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
> In Bitcoin Wallet, I use Base 43 (alphabet:
> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
> code encoding. I only leave out the space character because it gets
> replaced by "+" in URLs.

Doing that only makes addresses a few % shorter, at the cost of significant
downsides.  For example, not everyone knows what those additional characters
are called, particularly for non-English-speaking users. Non-alphanumeric
characters also complicate using the addresses in a variety of contexts ('/'
in particularly isn't valid in filenames).

I'd suggest you review the "Rational" section of the BIP for more details:

https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki#rationale

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A BIP proposal for segwit addresses

[Andreas Schildbach via bitcoin-dev]

Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
In Bitcoin Wallet, I use Base 43 (alphabet:
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
code encoding. I only leave out the space character because it gets
replaced by "+" in URLs.


On 03/20/2017 10:35 PM, Pieter Wuille via bitcoin-dev wrote:
> Hello everyone,
> 
> I'd like to propose a new BIP for native segwit addresses to replace
> BIP 142. These addresses are not required for segwit, but are more
> efficient, flexible, and nicer to use.
> 
> The format is base 32 and uses a simple checksum algorithm with strong
> error detection properties. Reference code in several languages as
> well as a website demonstrating it are included.
> 
> You can find the text here:
> https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki
> 
> Cheers,
> 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Inquiry: Transaction Tiering

[Tim Ruffing via bitcoin-dev]

(I'm not a lawyer...)

I'm not sure if I can make sense of your email.

On Mon, 2017-03-20 at 20:12 +, Martin Stolze via bitcoin-dev wrote:
> As a participant in the economy in general and of Bitcoin in
> particular, I desire an ability to decide where I transact. The
> current state of Bitcoin does not allow me to choose my place of
> business. As a consequence, I try to learn what would be the best way
> to conduct my business in good faith. [2]

Ignoring the rest, I don't think that the physical location /
jurisdiction of the miner has any legal implications for law applicable
to the relationship between sender and receiver of a payment. 

This is not particular to Bitcoin. We're both in Germany (I guess).
Assume we have a contract without specific agreements and I pay you in
Icelandic kronur via PayPal (in Luxembourg) and my HTTPS requests to
PayPal went via Australia and the US. Then German law applies to our
contract, nothing in the middle can change that.

Also ignoring possible security implications, there is just no need for
a mechanism that enables users to select miners. I claim that almost
nobody cares who will mine a transaction, because it makes no technical
difference. If you don't want a specific miner to mine your
transaction, then don't use Bitcoin.

Tim
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev