I think one could make the argument that the only people who talk
about and understand 24 bit audio or 256 bit cryptography are the ones
who can tell the difference very easily.
To me, your example seems to try hard to make the case for a problem
that won't exist in reality.
Bitcoin (BTC), Millib
I should not take it that the lack of critical feedback to this revised
proposal is a glowing endorsement. I understand that there would be technical
issues to resolve in implementation, but, are there no fundamental errors?
I suppose that it if is difficult to determine how long a transaction h
>Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the >correct<
approach. It's tidy, systematic and precise.
The SI system is great, but it's nice if you pick a base unit that is easy
for intuition to comprehend.
It is a fact that I weigh approximately .000,000,000,000,000,000,000,01
> I understand that there would be technical issues to resolve in
> implementation, but, are there no fundamental errors?
Unfortunately your proposal is really fundamentally broken, on a few levels. I
think you might need to do a bit more research into how bitcoin works before
coming up with su
I don't have anything interesting to add, except that I have been using 'bits'
on my site for over 3 years. It's a great unit that people quickly adapt to,
and it's far more convenient. When dealing with large amounts of money, people
have no problem naturally thinking in "thousand bits" or "mil
One of the ideas that Greg Maxwell brought up in the "'Compressed' headers
stream" thread is the possibility of a header sync mechanism that allowed
parallel download from multiple peers. With the current getheaders/headers
semantics, headers must be downloaded sequentially from genesis. In my
test
