Re: [Bitcoin-development] BIP: Custodial Identities

2014-08-20 Thread 21E14
Thank you for your feedback regarding Custodial Identities. I will address
it to the mailing list for transparency.

Think of it as a 1-of-2 multisig edge case where Custodian Identities are
actively managed by the Bitcoin Assigned Custodial Identities
Authority/Regional Bitcoin Custodial Identity Registries. Once the optional
identity layer is integrated, there are so many applications beyond dispute
resolution, if you could effortlessly inject Custodian Identities into the
blockchain itself as easily as providing 1-of-2 public keys.

Bitcoin Custodial Identities can be applied to coinbase transactions as
well, in any or all jurisdictions, thus providing further incentive to keep
nodes honest, or enabling a recovery mechanism in catastrophic failure
events, such as a break in SHA-256. Custodians provide account addresses
out of unused address space further alleviating address collisions as a
psychological barrier to adoption. Custodial to non-custodial transactions
could behave much like the UTXO of a coinbase transaction, which has the
special condition that it cannot be spent (used as an input) for at least
100 blocks. It's based on open market competition, and there will probably
always be users willing to live outside of the BCI address space.


>>On Tue, Aug 19, 2014 at 10:23 PM, 21E14 <21x...@gmail.com> wrote:
>>
>>As suggested before submitting a BIP, I am sending this to the mailing
list.
>>
>>
>>Bitcoin is often described as “the currency of the Internet”, “the TCP/IP
of money”, or simply “the Internet of Money”. What is needed is an optional
identity layer — a Bitcoin Assigned Custodial Identities >>Authority, much
like the Internet Assigned Numbers Authority, to oversee global Custodial
Identity allocation. Such an authority delegates Custodial Identity Spaces
to Regional Bitcoin Custodial Identity >>Registries, much like the RIRs
(Regional Internet Registries) managing the allocation of Internet number
resources.
>>
>>A Bitcoin Custodial Identity (BCI) account address would consist of a
Custodial Identifier allocated by the BACIA/RBCIRs (much like a bank’s
routing number), and an account address (much like an account >>number).
Bitcoin Custodial Identities allow dispute resolution in the legal system
for transactions in the BCI address space. Free market would drive and
determine the demand for custodial accounts. P2PKH >>users not affected.
>>
>>Feedback is appreciated.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

2014-08-20 Thread Mike Hearn
>
> Misbehaving addresses can have their connecting difficulty
> scaled up, which should make it uneconomic to try to DoS the usage of
> Tor exit nodes for connecting to Bitcoin.
>

You can't solve DoS by requiring all clients to do complicated work, all
that means is that weak clients (like users mobile phones and tablets) are
successfully DoSd whereas the attackers botnet of stolen computers sit
there solving PoWs.

The correct way to solve DoS is by having work prioritisation and queueing
mechanisms, then finding ways to distinguish "good" clients from "bad"
clients. Doing this whilst preserving privacy is hard. Long term the only
way to solve it may be to require clients to present some kind of cookie
during resource exhaustion events that prove they've been around for a
while, thus allowing them to jump the queue.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-20 Thread Mike Hearn
I would be very happy if we upgraded the P2P protocol with MAC keys and a
simple home grown encryption layer, because:

   1. It's practically guaranteed that 5-eyes intelligence agencies are
   either systematically deanonymising Bitcoin users already (linking
   transactions to real world identities) or close to succeeding. Peter is
   correct. Given the way their infrastructure works, encrypting link level
   traffic would significantly raise the bar to such attacks. Quite possibly
   to the level where it's deemed unprofitable to continue.

   2. Tor is not a complete solution. The most interesting links to monitor
   are those from SPV clients connecting to Core nodes. Whilst Java SPV
   clients have the nice option of an easy bundled Tor client (er, once we fix
   the last bugs) clients that are not based on bitcoinj would have to use the
   full-blown Tor client, which is not only a PITA to bundle as Tor is not at
   all library-fied, but is a giant pile of C which is almost certainly
   exploitable. Even if it runs in a separate address space, for many
   platforms this is insufficient as a compromised Tor client could then go
   ahead and compromise your wallet app too.

Implementing a full Tor client is not a reasonable thing to ask of a wallet
developer, but doing HMAC checks and a simple ECDH exchange + AES would be
quite realistic.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reconsidering github

2014-08-20 Thread Mike Hearn
If github were to be abandoned for anything, it'd make sense to move code
review and bug tracking elsewhere. GitHub does a reasonably good job of
hosting git repositories. It kind of sucks at code review and the issue
tracker is rudimentary at best. These days you can do "log in with my
github account" so if done well, it'd not have to be very painful.

JetBrains make great stuff and they have a code review and repository
exploration tool called Upsource in development, which should come out
soon. I think it's proprietary but that would be no different to github,
and it's designed for self hosting.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

2014-08-20 Thread Isidor Zeuner
Hi there,

quote:
[...]
> If two distinct transactions (with unrelated bitcoin addresses)
> come from the same set of 8 peers, the attacker can conclude that they
> originated from the same user. This gives another method (in addition
> to transaction graph analysis) for an attacker to link different BC
> addresses of the same user.

Using the same set of nodes for posting transactions using unrelated
inputs kind of limits the privacy improvement that can be gained from
using unrelated inputs in the first place.

Similar to how Tor uses different circuits for different hosts to
connect to, it may make more sense to only use the same set of nodes
for posting a subsequent transaction when the input addresses are also
the same.

[...]
> Some details are here: https://www.cryptolux.org/index.php/Bitcoin
>

I also find the topic of banning Tor exit nodes interesting.

I wonder if it makes more sense not to ban IP addresses completely,
but instead to throttle them using a PoW-based access control
scheme. Misbehaving addresses can have their connecting difficulty
scaled up, which should make it uneconomic to try to DoS the usage of
Tor exit nodes for connecting to Bitcoin.

It may also help nodes behind a NAT router if they share their global
IP with misconfigured nodes.

Best regards,

Isidor

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development