Re: [Bitcoin-development] Mailing list abuse

2014-04-21 Thread Rodney Morris
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 out.

Thanks for taking the time to reply.

Rodney
 On 21/04/2014 3:47 pm, Wladimir laa...@gmail.com wrote:

 On Mon, Apr 21, 2014 at 6:58 AM, Rodney Morris rodney.mor...@gmail.com
 wrote:
  What is the procedure for dealing with it? Is it considered abuse to
 reply
  to and quote the entire digest for the sake of a few lines of content?
 Am I
  the only one annoyed by this (if so I'll just shut right up).

 I would not go as far as calling it 'abuse' if it is not done on
 purpose. Probably the person doesn't even know he/she is doing this.
 Best to mail the person and ask (nicely) instead of complaining to the
 list.

 Wladimir

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

2014-04-21 Thread Tamas Blummer
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 pieter.wui...@gmail.com wrote:

 
 On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com 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



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

2014-04-21 Thread 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


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

2014-04-21 Thread 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] Economics of information propagation

2014-04-21 Thread Tier Nolan
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.  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

2014-04-21 Thread 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 ta...@bitsofproof.com 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 pieter.wui...@gmail.com wrote:
 
 
 On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com 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] bits: Unit of account

2014-04-21 Thread 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 slashdevn...@hotmail.com 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] Economics of information propagation

2014-04-21 Thread 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 tier.no...@gmail.com wrote:
 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.  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] Economics of information propagation

2014-04-21 Thread Alan Reiner
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 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

2014-04-21 Thread 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

2014-04-21 Thread 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

2014-04-21 Thread 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 m...@monetize.io 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

2014-04-21 Thread 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 m...@monetize.io 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