Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

The reason why client side certificates have never gained traction because it is a pain to safely store/backup secrets. In bitcoinland we are forced to solve the problem of safely storing secrets, and over the years we have come up with software and hardware solutions to make this safer and easier

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption

The spec has been updated a bit. Even if the bulk of the key-stretching work has been outsourced to another device, and that device is compromised, the passphrase is now protected by minimum 8192 rounds of salted PBKDF2-HMAC-SHA512. The idea is that more powerful devices (mobile phones, laptops,

Re: [Bitcoin-development] Economics of information propagation

Thank you for your thoughts. > The earlier, larger block A will only become stale if *two* blocks are > found in the extra time it takes for block A to propagate the network. > That is a substantially different risk, and probably a negligible > concern to most miners. I really like Mark’s sugges

Re: [Bitcoin-development] Economics of information propagation

Pieter tried it already. If the two nodes views of each others mempools are not exactly in alignment it ends up being slower than just sending the data immediately and redundantly. On Mon, Apr 21, 2014 at 6:38 PM, Mark Friedenbach wrote: > Yes, it certainly can be improved in this way. You can

Re: [Bitcoin-development] Economics of information propagation

Yes, it certainly can be improved in this way. You can even extend the idea to distribute partial proofs of work (block headers + Merkle lists which represent significant but not sufficient work), and 'prime' your memory pools with the transactions contained within. This is, btw, basically what p2

Re: [Bitcoin-development] Economics of information propagation

I haven't done the math on this, so it may be a terrible idea. :) I've been wondering if block propagation times could also be improved by allowing peers to request the list of transaction hashes that make up a block, and then making a follow-up request to only download any transactions not curr

Re: [Bitcoin-development] Economics of information propagation

That wasn't what I was saying. Right now the primacy of a block is determined by the time at which the `block` message is received, which is delays due to both the time it takes to transmit the block data and the time it takes to validate. Headers-first, on the other hand, has the option of basing

Re: [Bitcoin-development] Economics of information propagation

On 04/21/2014 11:40 AM, Ashley Holman wrote: > On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd > wrote: > > That is mistaken: you can't mine on top of just a block header, > leaving small miners disadvantaged as they are earning no profit > while they wait for th

Re: [Bitcoin-development] Economics of information propagation

On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd wrote: > > That is mistaken: you can't mine on top of just a block header, leaving > small miners disadvantaged as they are earning no profit while they wait > for the information to validate the block and update their UTXO sets. This > results in the sa

Re: [Bitcoin-development] Economics of information propagation

I'm not convinced that headers first will result in miners hashing on top of the block with more work without knowing if it's valid yet instead of just keep hashing on top of the longest known-to-be-valid chain. Both options are risky for the miner in some way, and I guess the probability of someon

Re: [Bitcoin-development] "bits": Unit of account

xbit is close to XBT because it would be the same unit, both would mean 100 satoshi or 1e-6 Bitcoin. xbit would be for everyday use, XBT for ISO. I know, the XBT was used by some sites to be a synonym for BTC that is however in my opinion not yet graved in stone until it is used by e.g. Bloombe

Re: [Bitcoin-development] "bits": Unit of account

Tamas, "xbit" is only a typo or spelling error away from "XBT", and some folks may assume they refer to the same unit of measure, not knowing the new currency system as developers here do. From your email, I got the idea of using "x" as a suffix at the end of a number of bits e.g. 17500x, like

Re: [Bitcoin-development] Economics of information propagation

On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd wrote: > Of course, in reality smaller miners can just mine on top of block headers > and include no transactions and do no validation, but that is extremely > harmful to the security of Bitcoin. > I don't think it reduces security much. It is extreme

Re: [Bitcoin-development] "bits": Unit of account

Thomas V: Your proposal misses the points that: - this is about a unit with 1e-6 Bitcoins or 100 satoshis. - it is not about people who know Bitcoin and are techies, but about those who don’t and aren’t. The reasons for such a unit are more than shifting the comma some places for convinience

Re: [Bitcoin-development] "bits": Unit of account

Let me make a sacrilegious proposal: keep using the name "bitcoin", and shift the decimal point. There would be a short adaption period, where people will need to talk about "new bitcoins" and "old bitcoins" in order to disambiguate them. However, Bitcoin users are techies, so I don't think that t