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

[Jan Møller]

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 to manage for ordinary people.
Solving this is paramount to the success of Bitcoin, and nobody has solved
it before on a grand scale.

I see no reason for forcing end users to use two different mechanisms for
safely managing secrets.

I agree that using a bitcoin address for authentication purposes might be
confusing and potentially linking your funds with your identity. So I am
all for using something else than bitcoin addresses and bitcoin private
keys.

With bip32 we have finally agreed on a mechanism for generating a hierarchy
of bitcoin private keys from a master seed. A similar approach can be used
for generating a parallel hierarchy for authentication purposes.

- Jan
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[William Yager]

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, etc.) can
do all the key-stretching on their own, whereas weaker devices with access
to another device with more computing power (like Trezors) do a fair amount
of key-stretching on their own, but can safely export the rest of the
key-stretching to the other device.

Will

On Tue, Mar 11, 2014 at 10:17 PM, Jean-Paul Kogelman <
jeanpaulkogel...@me.com> wrote:

> Hi everyone,
>
> We've been hard at work updating the spec to include features that were
> requested. We've removed the Scrypt dependency that was present in the
> initial drafts, added new KDFs, added plausible deniability and have a
> reference implementation.
>
>
> Kind regards,
>
>
> Jean-Paul Kogelman
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Jonathan Levin]

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 suggestion but one concern is that it might tip the needle 
too far. Currently, there is a private cost to include more transactions, which 
might be too high, but limit the amount of negative externalities that this 
creates on other miners. If I am able to create blocks that are very likely to 
be on the main chain with the maximum number of transactions then this makes 
imposing negative externalities on other miners less costly. Other nodes that 
are closely connected to me would experience a positive externality through 
this as well. Would have do some more thinking here but it seems that there is 
a balance to strike.

> If anything, looks like a threat to the current situation with huge
> mining subsidies coming from the seigniorage, not a problem that you
> would have when the the seigniorage is gone.

The incentives remain so long as the ratio of the seignorage revenues to 
transaction fees remain very high. Even though the dollar price does not change 
that relationship it does mean that Bitcoin becomes more expensive in USD terms 
as the USD price of Bitcoin rises.

> I think the most important part is that nodes can reliably decide on
> "first received", regardless of how they subsequently act on it. 

If we want to limit the amount of network time spent on redundant problems it 
would be best for miners to act on this information? What is the benefit of 
serialisation? Is it that the miner would consider it more likely to make it 
into the main chain rather than the block that came second?

> But I don't see how miners mining headers first would result in empty
> blocks either.

I guess it is due to the fact that this is the only way a miner can be certain 
that none of the transactions have been spent already resulting in an orphan 
block.

On 21 Apr 2014, at 17:00, Mark Friedenbach  wrote:

> 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 primacy on the time the block header is received, which
> is O(1) time to transmit and to SPV-validate. Mining on that block
> doesn't actually commence until the full block is received and validated.
> 
> To see how this works, take an example: two blocks with a common parent
> are found relatively close to each other, block A and block B. A is
> found first but is a large block with the maximum block size and many
> slow scripts. B is found a few seconds later and is an empty block. In
> the current regime it is entirely possible that block B, the later but
> smaller block, would get received and processed first by more mining
> peers than the larger block A, exactly as described in Jonathan Levin's
> email.
> 
> With headers-first, however, the cost of propagation of the block header
> is the same and we should expect block A to win out over block B nearly
> every time. Miners will continue working on the old, known valid parent
> block until the contents of block A are received and processed. So the
> smaller block B is still found, and since it's data moves across the
> network faster, miners even briefly mine on block B. But as soon as they
> receive and process the contents of block A, they switch to that.
> 
> 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.
> 
> On 04/20/2014 09:06 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 same problem as before, as the
>> large pools who mine most blocks can validate either instantly - the
>> self-mine case - or more quickly than the smaller miners.
>> 
>> 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.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatfo

Re: [Bitcoin-development] Economics of information propagation

[Mike Hearn]

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 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 p2pool does, which is why last time I
> calculated you get roughly 1% better return from p2pool than a zero-fee
> mining pool would get you, specifically because of the lower stale rate.
>
> On 04/21/2014 09:22 AM, Paul Lyon wrote:
> > 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 currently known. I'm not sure what percentage of
> > transactions a node will usually already have when it receives a new
> > block, but if it's high I figure this could be beneficial.
> >
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

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 p2pool does, which is why last time I
calculated you get roughly 1% better return from p2pool than a zero-fee
mining pool would get you, specifically because of the lower stale rate.

On 04/21/2014 09:22 AM, Paul Lyon wrote:
> 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 currently known. I'm not sure what percentage of
> transactions a node will usually already have when it receives a new
> block, but if it's high I figure this could be beneficial.
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Paul Lyon]

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 
currently known. I'm not sure what percentage of transactions a node will 
usually already have when it receives a new block, but if it's high I figure 
this could be beneficial.

> Date: Mon, 21 Apr 2014 09:00:09 -0700
> From: m...@monetize.io
> To: p...@petertodd.org; jonathan.le...@sant.ox.ac.uk
> CC: bitcoin-development@lists.sourceforge.net
> Subject: 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 primacy on the time the block header is received, which
> is O(1) time to transmit and to SPV-validate. Mining on that block
> doesn't actually commence until the full block is received and validated.
> 
> To see how this works, take an example: two blocks with a common parent
> are found relatively close to each other, block A and block B. A is
> found first but is a large block with the maximum block size and many
> slow scripts. B is found a few seconds later and is an empty block. In
> the current regime it is entirely possible that block B, the later but
> smaller block, would get received and processed first by more mining
> peers than the larger block A, exactly as described in Jonathan Levin's
> email.
> 
> With headers-first, however, the cost of propagation of the block header
> is the same and we should expect block A to win out over block B nearly
> every time. Miners will continue working on the old, known valid parent
> block until the contents of block A are received and processed. So the
> smaller block B is still found, and since it's data moves across the
> network faster, miners even briefly mine on block B. But as soon as they
> receive and process the contents of block A, they switch to that.
> 
> 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.
> 
> On 04/20/2014 09:06 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 same problem as before, as the
> > large pools who mine most blocks can validate either instantly - the
> > self-mine case - or more quickly than the smaller miners.
> > 
> > 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.
> 
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  --
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

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 primacy on the time the block header is received, which
is O(1) time to transmit and to SPV-validate. Mining on that block
doesn't actually commence until the full block is received and validated.

To see how this works, take an example: two blocks with a common parent
are found relatively close to each other, block A and block B. A is
found first but is a large block with the maximum block size and many
slow scripts. B is found a few seconds later and is an empty block. In
the current regime it is entirely possible that block B, the later but
smaller block, would get received and processed first by more mining
peers than the larger block A, exactly as described in Jonathan Levin's
email.

With headers-first, however, the cost of propagation of the block header
is the same and we should expect block A to win out over block B nearly
every time. Miners will continue working on the old, known valid parent
block until the contents of block A are received and processed. So the
smaller block B is still found, and since it's data moves across the
network faster, miners even briefly mine on block B. But as soon as they
receive and process the contents of block A, they switch to that.

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.

On 04/20/2014 09:06 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 same problem as before, as the
> large pools who mine most blocks can validate either instantly - the
> self-mine case - or more quickly than the smaller miners.
> 
> 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.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Alan Reiner]

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 the information to validate the block and
> update their UTXO sets. This results in the same problem as
> before, as the large pools who mine most blocks can validate
> either instantly - the self-mine case - or more quickly than the
> smaller miners.
>
>  
> Under the headers first scenario, wouldn't the full block still reach
> everyone in the same time as it would under the current rules?  So the
> small miner loses nothing in terms of updating their UTXO set, but
> gains an early "heads up" alert that a new block is coming.  This
> allows them spend the propagation time working more productively on an
> empty block in the new chain rather than wasting time on an orphan.
>  It's true that it doesn't solve the problem of larger pools vs
> smaller pools, but if it doesn't make it any worse then headers-first
> propagation would be a net benefit to the network since it removes the
> incentive to make small blocks.
>

I think the most important part is that nodes can reliably decide on
"first received", regardless of how they subsequently act on it.  I
believe it would be fine for a node to receive a header and continue
mining the old block, or a subsequently-verified competing block, until
it has the necessary pieces to fully verify the first header received. 
If that block data doesn't come, then it will be naturally ignored.  But
if multiple blocks come at once, even if a competing block "verifies"
first, the node would still switch to considering the first header
received as the best block when it later receives proof it is valid
(which may only be a couple seconds).

In other words, the node will always consider the header-received time
as the primary ordering criteria, but will not mine on anything until it
has full proof of validity, even if /that/ is out of order.  This means
that new blocks "effectively" propagate at the speed of 80 bytes, which
limits certain kinds of block-injection/racing attacks. 


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Ashley Holman]

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 same problem as before, as the large pools who mine most
> blocks can validate either instantly - the self-mine case - or more quickly
> than the smaller miners.
>
>
Under the headers first scenario, wouldn't the full block still reach
everyone in the same time as it would under the current rules?  So the
small miner loses nothing in terms of updating their UTXO set, but gains an
early "heads up" alert that a new block is coming.  This allows them spend
the propagation time working more productively on an empty block in the new
chain rather than wasting time on an orphan.  It's true that it doesn't
solve the problem of larger pools vs smaller pools, but if it doesn't make
it any worse then headers-first propagation would be a net benefit to the
network since it removes the incentive to make small blocks.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Jorge Timón]

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 someone hashing an invalid block above difficulty is
too low to be the main concern, but there's intermediate solutions,
like say, waiting to validate at least 5% of the block.

But I don't see how miners mining headers first would result in empty
blocks either.
Why wouldn't them validate and include transactions after they have
received the full block?
They will likely know most of the transaction before receiving the block anyway.
In a future where they ONLY live on transaction fees, why would they
refuse to validate and include transactions? What are they hashing for
then?
If anything, looks like a threat to the current situation with huge
mining subsidies coming from the seigniorage, not a problem that you
would have when the the seigniorage is gone.

In any case, it is true that this is mining policy and therefore out
of the realm of what the protocol can regulate, so we should assume
miners will do whatever it's best for them.

The trade-off between tps and centralization remains: if you want
higher tx volume, less full nodes will be able to process it.

On 4/21/14, Tier Nolan  wrote:
> 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 extremely unlikely that
> someone would publish an invalid block, since they would waste their POW.
>
> Presuming that new headers are correct is reasonable, as long as you check
> the full block within a few minutes of receiving the header.
>
> If anything, it increases security, since less hashing power is wasted
> while the full block is broadcast.
>
> Block propagation could take the form
>
> - broadcast new header
> - all miners switch to mining empty blocks
> - broadcast new block
> - miners update to a block with transactions
>
> If the block doesn't arrive within a timeout, then the miner could switch
> back to the old block.
>
> This would mean that a few percent of empty blocks end up in the
> blockchain, but that doesn't do any harm.
>
> It is only harmful, if it is used as a DOS attack on the network.
>
> The empty blocks will only occur when 2 blocks are found in quick
> succession, so it doesn't have much affect on average time until 1
> confirm.  Empty blocks are just as good for providing 1 of the 6 confirms
> needed too.
>


-- 
Jorge Timón

http://freico.in/

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Tamas Blummer]

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. Bloomberg.

Regards,

Tamas Blummer
http://bitsofproof.com

On 21.04.2014, at 14:14, Un Ix  wrote:

> 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.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Un Ix]

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 cents or centavos. I guess this might clash with 
formal S.I. notation but it's easy to read and has less ambiguity, IMHO.

> On 21/04/2014, at 2:21 pm, "Tamas Blummer"  wrote:
> 
> 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.
> 
> Regarding XBT: No matter who used it for what. The way Bloomberg will use it 
> will define its use in finance,
> and since that did not happen yet, we are not late to shape.
> 
> Regards,
> 
> Tamas Blummer
> http://bitsofproof.com
> 
>> On 21.04.2014, at 07:41, Pieter Wuille  wrote:
>> 
>> 
>> On Apr 21, 2014 3:37 AM, "Un Ix"  wrote:
>> >
>> > Something tells me this would be reduced to a single syllable in common 
>> > usage I.e. bit.
>> 
>> What units will be called colloquially is not something developers will 
>> determine. It will vary, depend on language and culture, and is not relevant 
>> to this discussion in my opinion.
>> 
>> It may well be that people in some geographic or language area will end up 
>> (or for a while) calling 1e-06 BTC "bits". That's fine, but using that as 
>> "official" name in software would be very strange and potentially confusing 
>> in my opinion. As mentioned by others, that would seem to me like calling 
>> dollars "bucks" in bank software. Nobody seems to have a problem with having 
>> colloquial names, but "US dollar" or "euro" are far less ambiguous than 
>> "bit". I think we need a more distinctive name.
>> 
>> -- 
>> Pieter
>> --
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Tier Nolan]

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 extremely unlikely that
someone would publish an invalid block, since they would waste their POW.

Presuming that new headers are correct is reasonable, as long as you check
the full block within a few minutes of receiving the header.

If anything, it increases security, since less hashing power is wasted
while the full block is broadcast.

Block propagation could take the form

- broadcast new header
- all miners switch to mining empty blocks
- broadcast new block
- miners update to a block with transactions

If the block doesn't arrive within a timeout, then the miner could switch
back to the old block.

This would mean that a few percent of empty blocks end up in the
blockchain, but that doesn't do any harm.

It is only harmful, if it is used as a DOS attack on the network.

The empty blocks will only occur when 2 blocks are found in quick
succession, so it doesn't have much affect on average time until 1
confirm.  Empty blocks are just as good for providing 1 of the 6 confirms
needed too.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Tamas Blummer]

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, 
but to align Bitcoin with capabilities of existing financial software and 
customs of finance and average people,
and ISO standard of currency abbreviations.

bit and XBT seems to check the boxes. 

I would love to have some feedback on xbit as per my previous mail.

Regards,

Tamas Blummer
http://bitsofproof.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Thomas Voegtlin]

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 ambiguity
will be a big issue. I don't think lots of people will mistakenly send
1000 times more than the amount they intended.

The name "bitcoin" has a huge advantage over any other proposal, because
it is already established. No marketing is needed.

This kind of renaming has already taken place many times in history,
because the currency was debased. Bitcoin would be the first time it
happens in the other direction.


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development