Not a bad idea. Semantics of the word abuse not withstanding.
I don't want to become the self appointed mailing list cop, but I notice it
maybe more than others because I almost exclusively read this mailing list
on a mobile device. Hence my asking for feedback without publicly calling
anyone
Here is one to please those looking for a “fully qualified” slang word, that
links with the official XBT:
xbit (spoken: ex-bit) would rationalise XBT (where X comes from supranational
use) and is unique.
I personally associate from x to six also supporting the 1e-6 divisor of
Bitcoin.
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 the
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
On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd p...@petertodd.org 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.
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
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.
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
On 04/21/2014 11:40 AM, Ashley Holman wrote:
On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd p...@petertodd.org
mailto:p...@petertodd.org 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
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
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
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 m...@monetize.io wrote:
Yes, it certainly can be improved in
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
13 matches
Mail list logo
