Re: [Bitcoin-development] BIP: Custodial Identities
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)
> > 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
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
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)
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
