public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

• * [Bitcoin-development] Economics of information propagation
         [not found] <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
  @ 2014-04-21  1:30 ` Jonathan Levin
    2014-04-21  3:58   ` Mark Friedenbach
                       ` (2 more replies)
    0 siblings, 3 replies; 21+ messages in thread
  From: Jonathan Levin @ 2014-04-21  1:30 UTC (permalink / raw)
    To: bitcoin-development
  
  [-- Attachment #1: Type: text/plain, Size: 15699 bytes --]
  
  Hi all,
  
  I am a post-graduate economist writing a paper on the incentives of mining. Even though this issue has been debated in the forums, I think it is important to get a sense of the magnitude of the incentives at play and determine what implications this has for the transaction fee market.
  
  As it has been pointed out before the marginal cost for miners does not stem from the private cost of the miner validating the signature and including it in the list of transactions in the block but rather the increased probability that the block will be orphaned as a result of slower propagation. Gavin did some back of the envelope worst case calculations but these overstated the effect of propagation delay. The reason being the 80ms additional time to reach 50% of the network is spread throughout the time that it takes to reach 50% of the network. During this time miners are notified about the block and treat it as the longest chain and hence are no longer mining with the aim to produce a competing block. 
  
  I am looking to calculate the change in the curvature of the probability mass function that a block hears about my block in any given second as a function of the block size. Although there is likely to be significant noise here, there seems to be some stable linear relationships with the time that it takes to reach different quartiles. Has anyone done this? I have used some empirical data that I am happy to share but ideally I would like analytical solutions.
  
  Following Peter Todd, I also find the concerning result that propagation delays results in increasing returns to higher shares of the hashing power. Indeed it may well be in the interest of large pools to publish large blocks to increase propagation delays on the network which would increase orphan rates particularly for small miners and miners that have not invested in sufficient bandwidth / connectivity. If a small miner hears about a block after 4.5 seconds on average there is a 0.7% chance that there is already a block in circulation.  Large miners can increase the time that it takes for small miners to hear about blocks by increasing the size of their blocks. For example if the time that it takes for a small miner to hear about the block goes to 12 seconds there is a 2 percent chance there is already a block in circulation for the small miner. There is also a 1.2% chance that there will be a competing block published after a small miner propagates in the time that it gets to full propagation. Am I getting this right that the probability of a miner’s block being orphaned is comprised of the probability that the miner was not the first to find a valid block and the probability that given they are first, someone else in the absence of hearing about it finds a competing valid block. 
  
  One question is: Are orphans probabilistic and only resolved after hearing about a new block that lengthens the chain or is there a way to know in advance? Is it frowned upon to mine on top of a block that you have just found even though it is very likely going to end up an orphan?
  
  Would be happy to share the draft form of the paper and receive any feedback.
  
  Finally, at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software. 
  
  Best,
  
  Jonathan
  
  
  
  
  
  
  
  
  
  
  On 21 Apr 2014, at 01:16, <bitcoin-development-request@lists•sourceforge.net> <bitcoin-development-request@lists•sourceforge.net> wrote:
  
  > Send Bitcoin-development mailing list submissions to
  > 	bitcoin-development@lists•sourceforge.net
  > 
  > To subscribe or unsubscribe via the World Wide Web, visit
  > 	https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  > or, via email, send a message with subject or body 'help' to
  > 	bitcoin-development-request@lists•sourceforge.net
  > 
  > You can reach the person managing the list at
  > 	bitcoin-development-owner@lists•sourceforge.net
  > 
  > When replying, please edit your Subject line so it is more specific
  > than "Re: Contents of Bitcoin-development digest..."
  > 
  > 
  > Today's Topics:
  > 
  >   1. Re: "bits": Unit of account (Oliver Egginger)
  >   2. Re: "bits": Unit of account (Christophe Biocca)
  >   3. Re: "bits": Unit of account (Gmail)
  >   4. Re: "bits": Unit of account (Mike Caldwell)
  >   5. Re: "bits": Unit of account (Justin A)
  > 
  > 
  > ----------------------------------------------------------------------
  > 
  > Message: 1
  > Date: Sun, 20 Apr 2014 20:43:24 +0200
  > From: Oliver Egginger <bitcoin@olivere•de>
  > Subject: Re: [Bitcoin-development] "bits": Unit of account
  > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
  > Message-ID: <5354154C.1080908@olivere•de>
  > Content-Type: text/plain; charset=ISO-8859-1
  > 
  > Hello,
  > 
  > just my two 'cents':
  > 
  > Terms arises by itself. Just as most people speak of coins when they
  > mean bitcoins. I do not see that bitcoin is currently in common use
  > except for speculation. Therefore no term for smaller units has
  > established yet. No problem in my eyes. Time will tell.
  > 
  > - oliver
  > 
  > 
  > 
  > 
  > ------------------------------
  > 
  > Message: 2
  > Date: Sun, 20 Apr 2014 15:19:38 -0400
  > From: Christophe Biocca <christophe.biocca@gmail•com>
  > Subject: Re: [Bitcoin-development] "bits": Unit of account
  > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
  > Message-ID:
  > 	<CANOOu=9=TAnaCuyh_P2GqHaguyY39xjhj84HSA_x+6F4MOqM_A@mail•gmail.com>
  > Content-Type: text/plain; charset=UTF-8
  > 
  > Culturally neutral? "bit" in French phonetically collides with slang
  > for phallus ("bitte", with a silent "e"). Apparently it means "louse"
  > in Turkish as well.
  > 
  > Not that this really would be avoidable with any short word (all the
  > short possible words are usually taken), but it's not neutral.
  > 
  > On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin@olivere•de> wrote:
  >> Hello,
  >> 
  >> just my two 'cents':
  >> 
  >> Terms arises by itself. Just as most people speak of coins when they
  >> mean bitcoins. I do not see that bitcoin is currently in common use
  >> except for speculation. Therefore no term for smaller units has
  >> established yet. No problem in my eyes. Time will tell.
  >> 
  >> - oliver
  >> 
  >> 
  >> ------------------------------------------------------------------------------
  >> Learn Graph Databases - Download FREE O'Reilly Book
  >> "Graph Databases" is the definitive new guide to graph databases and their
  >> applications. Written by three acclaimed leaders in the field,
  >> this first edition is now available. Download your free book today!
  >> http://p.sf.net/sfu/NeoTech
  >> _______________________________________________
  >> Bitcoin-development mailing list
  >> Bitcoin-development@lists•sourceforge.net
  >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  > 
  > 
  > 
  > ------------------------------
  > 
  > Message: 3
  > Date: Sun, 20 Apr 2014 14:32:26 -0500
  > From: Gmail <will.yager@gmail•com>
  > Subject: Re: [Bitcoin-development] "bits": Unit of account
  > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
  > Message-ID: <B687D4AD-263F-4594-BE7A-FF238B8DF7AF@gmail•com>
  > Content-Type: text/plain; charset="us-ascii"
  > 
  > People in the Bitcoin community are sometimes resistant to the idea of using the word "credit" as a unit of Bitcoin, because Bitcoin is not a credit-based system. 
  > 
  > However, given that the average person has close to no understanding of what "credit" means, and probably no concern for the distinction even if they do know, it may be wise to use the futuristic and easily understandable "credit" as our human-friendly unit. 
  > 
  > Do others agree that "credits" as a unit of account has a desirable futuristic connotation?
  > 
  > Will
  > 
  > -------------- next part --------------
  > A non-text attachment was scrubbed...
  > Name: smime.p7s
  > Type: application/pkcs7-signature
  > Size: 1593 bytes
  > Desc: not available
  > 
  > ------------------------------
  > 
  > Message: 4
  > Date: Sun, 20 Apr 2014 16:28:34 -0400
  > From: Mike Caldwell <mcaldwell@swipeclock•com>
  > Subject: Re: [Bitcoin-development] "bits": Unit of account
  > To: Christophe Biocca <christophe.biocca@gmail•com>
  > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
  > Message-ID: <4098C706-D67F-474E-9C13-E4C8F56B41ED@swipeclock•com>
  > Content-Type: text/plain; charset="us-ascii"
  > 
  > By culturally neutral I mean we avoid deliberately invoking a cultural reference in the name.  For example "satoshi" would be a reference to Japanese culture just for being a common Japanese name regardless of who Satoshi turns out to be. 
  > 
  > Mike
  > 
  > Sent from my iPhone
  > 
  >> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <christophe.biocca@gmail•com> wrote:
  >> 
  >> Culturally neutral? "bit" in French phonetically collides with slang
  >> for phallus ("bitte", with a silent "e"). Apparently it means "louse"
  >> in Turkish as well.
  >> 
  >> Not that this really would be avoidable with any short word (all the
  >> short possible words are usually taken), but it's not neutral.
  >> 
  >>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin@olivere•de> wrote:
  >>> Hello,
  >>> 
  >>> just my two 'cents':
  >>> 
  >>> Terms arises by itself. Just as most people speak of coins when they
  >>> mean bitcoins. I do not see that bitcoin is currently in common use
  >>> except for speculation. Therefore no term for smaller units has
  >>> established yet. No problem in my eyes. Time will tell.
  >>> 
  >>> - oliver
  >>> 
  >>> 
  >>> ------------------------------------------------------------------------------
  >>> Learn Graph Databases - Download FREE O'Reilly Book
  >>> "Graph Databases" is the definitive new guide to graph databases and their
  >>> applications. Written by three acclaimed leaders in the field,
  >>> this first edition is now available. Download your free book today!
  >>> http://p.sf.net/sfu/NeoTech
  >>> _______________________________________________
  >>> Bitcoin-development mailing list
  >>> Bitcoin-development@lists•sourceforge.net
  >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >> 
  >> ------------------------------------------------------------------------------
  >> Learn Graph Databases - Download FREE O'Reilly Book
  >> "Graph Databases" is the definitive new guide to graph databases and their
  >> applications. Written by three acclaimed leaders in the field,
  >> this first edition is now available. Download your free book today!
  >> http://p.sf.net/sfu/NeoTech
  >> _______________________________________________
  >> Bitcoin-development mailing list
  >> Bitcoin-development@lists•sourceforge.net
  >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  > 
  > 
  > 
  > ------------------------------
  > 
  > Message: 5
  > Date: Sun, 20 Apr 2014 20:16:35 -0400
  > From: Justin A <allport@gmail•com>
  > Subject: Re: [Bitcoin-development] "bits": Unit of account
  > To: Mike Caldwell <mcaldwell@swipeclock•com>
  > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
  > Message-ID:
  > 	<CAK2MuX3GufxU_AH0Kaw3pUkzgX_agok86ahCh+7r96UkxZwneQ@mail•gmail.com>
  > Content-Type: text/plain; charset="utf-8"
  > 
  > <delurk>
  > 
  > What about "ubit", pronounced "YOU-bit", representing 1e-6 bitcoin? Easy to
  > say, tied in a visual way to the metric micro, leaves the required 2
  > decimal places for the marginally numerate.. What more could one want?
  > 
  > </delurk>
  > 
  > Also, hi. My first post; plan to get involved over the southern hemisphere
  > winter if I can learn enough.
  > On Apr 20, 2014 4:32 PM, "Mike Caldwell" <mcaldwell@swipeclock•com> wrote:
  > 
  >> By culturally neutral I mean we avoid deliberately invoking a cultural
  >> reference in the name.  For example "satoshi" would be a reference to
  >> Japanese culture just for being a common Japanese name regardless of who
  >> Satoshi turns out to be.
  >> 
  >> Mike
  >> 
  >> Sent from my iPhone
  >> 
  >>> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
  >> christophe.biocca@gmail•com> wrote:
  >>> 
  >>> Culturally neutral? "bit" in French phonetically collides with slang
  >>> for phallus ("bitte", with a silent "e"). Apparently it means "louse"
  >>> in Turkish as well.
  >>> 
  >>> Not that this really would be avoidable with any short word (all the
  >>> short possible words are usually taken), but it's not neutral.
  >>> 
  >>>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin@olivere•de>
  >> wrote:
  >>>> Hello,
  >>>> 
  >>>> just my two 'cents':
  >>>> 
  >>>> Terms arises by itself. Just as most people speak of coins when they
  >>>> mean bitcoins. I do not see that bitcoin is currently in common use
  >>>> except for speculation. Therefore no term for smaller units has
  >>>> established yet. No problem in my eyes. Time will tell.
  >>>> 
  >>>> - oliver
  >>>> 
  >>>> 
  >>>> 
  >> ------------------------------------------------------------------------------
  >>>> Learn Graph Databases - Download FREE O'Reilly Book
  >>>> "Graph Databases" is the definitive new guide to graph databases and
  >> their
  >>>> applications. Written by three acclaimed leaders in the field,
  >>>> this first edition is now available. Download your free book today!
  >>>> http://p.sf.net/sfu/NeoTech
  >>>> _______________________________________________
  >>>> Bitcoin-development mailing list
  >>>> Bitcoin-development@lists•sourceforge.net
  >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >>> 
  >>> 
  >> ------------------------------------------------------------------------------
  >>> Learn Graph Databases - Download FREE O'Reilly Book
  >>> "Graph Databases" is the definitive new guide to graph databases and
  >> their
  >>> applications. Written by three acclaimed leaders in the field,
  >>> this first edition is now available. Download your free book today!
  >>> http://p.sf.net/sfu/NeoTech
  >>> _______________________________________________
  >>> Bitcoin-development mailing list
  >>> Bitcoin-development@lists•sourceforge.net
  >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >> 
  >> 
  >> ------------------------------------------------------------------------------
  >> Learn Graph Databases - Download FREE O'Reilly Book
  >> "Graph Databases" is the definitive new guide to graph databases and their
  >> applications. Written by three acclaimed leaders in the field,
  >> this first edition is now available. Download your free book today!
  >> http://p.sf.net/sfu/NeoTech
  >> _______________________________________________
  >> Bitcoin-development mailing list
  >> Bitcoin-development@lists•sourceforge.net
  >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >> 
  > -------------- next part --------------
  > An HTML attachment was scrubbed...
  > 
  > ------------------------------
  > 
  > ------------------------------------------------------------------------------
  > 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
  > 
  > 
  > End of Bitcoin-development Digest, Vol 35, Issue 72
  > ***************************************************
  
  
  [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
  [-- Type: application/pgp-signature, Size: 496 bytes --]
  
  ^ permalink raw reply	[flat|nested] 21+ messages in thread

• • * Re: [Bitcoin-development] Economics of information propagation
      2014-04-21  1:30 ` [Bitcoin-development] Economics of information propagation Jonathan Levin
    @ 2014-04-21  3:58   ` Mark Friedenbach
      2014-04-21  4:06     ` Peter Todd
      2014-04-23  2:54   ` Tom Harding
      2014-04-23 15:05   ` Peter Todd
      2 siblings, 1 reply; 21+ messages in thread
    From: Mark Friedenbach @ 2014-04-21  3:58 UTC (permalink / raw)
      To: Jonathan Levin; +Cc: bitcoin-development
    
    [-- Attachment #1: Type: text/plain, Size: 17447 bytes --]
    
    As soon as we switch to headers
    first - which will be soon - there will be no difference in propagation
    time no matter how large the block is. Only 80 bites will be required to
    propagate the block header which establishes priority for when the block is
    fully validated.
    On Apr 20, 2014 6:56 PM, "Jonathan Levin" <jonathan.levin@sant•ox.ac.uk>
    wrote:
    
    > Hi all,
    >
    > I am a post-graduate economist writing a paper on the incentives of
    > mining. Even though this issue has been debated in the forums, I think it
    > is important to get a sense of the magnitude of the incentives at play and
    > determine what implications this has for the transaction fee market.
    >
    > As it has been pointed out before the marginal cost for miners does not
    > stem from the private cost of the miner validating the signature and
    > including it in the list of transactions in the block but rather the
    > increased probability that the block will be orphaned as a result of slower
    > propagation. Gavin did some back of the envelope worst case calculations
    > but these overstated the effect of propagation delay. The reason being the
    > 80ms additional time to reach 50% of the network is spread throughout the
    > time that it takes to reach 50% of the network. During this time miners are
    > notified about the block and treat it as the longest chain and hence are no
    > longer mining with the aim to produce a competing block.
    >
    > I am looking to calculate the change in the curvature of the probability
    > mass function that a block hears about my block in any given second as a
    > function of the block size. Although there is likely to be significant
    > noise here, there seems to be some stable linear relationships with the
    > time that it takes to reach different quartiles. Has anyone done this? I
    > have used some empirical data that I am happy to share but ideally I would
    > like analytical solutions.
    >
    > Following Peter Todd, I also find the concerning result that propagation
    > delays results in increasing returns to higher shares of the hashing power.
    > Indeed it may well be in the interest of large pools to publish large
    > blocks to increase propagation delays on the network which would increase
    > orphan rates particularly for small miners and miners that have not
    > invested in sufficient bandwidth / connectivity. If a small miner hears
    > about a block after 4.5 seconds on average there is a 0.7% chance that
    > there is already a block in circulation.  Large miners can increase the
    > time that it takes for small miners to hear about blocks by increasing the
    > size of their blocks. For example if the time that it takes for a small
    > miner to hear about the block goes to 12 seconds there is a 2 percent
    > chance there is already a block in circulation for the small miner. There
    > is also a 1.2% chance that there will be a competing block published after
    > a small miner propagates in the time that it gets to full propagation. Am I
    > getting this right that the probability of a miner’s block being orphaned
    > is comprised of the probability that the miner was not the first to find a
    > valid block and the probability that given they are first, someone else in
    > the absence of hearing about it finds a competing valid block.
    >
    > One question is: Are orphans probabilistic and only resolved after hearing
    > about a new block that lengthens the chain or is there a way to know in
    > advance? Is it frowned upon to mine on top of a block that you have just
    > found even though it is very likely going to end up an orphan?
    >
    > Would be happy to share the draft form of the paper and receive any
    > feedback.
    >
    > Finally, at coinometrics we are working on a modified client to capture
    > information on network propagation and would invite any suggestions of any
    > other useful statistics that would be useful in the development of software.
    >
    > Best,
    >
    > Jonathan
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > On 21 Apr 2014, at 01:16, <
    > bitcoin-development-request@lists•sourceforge.net> <
    > bitcoin-development-request@lists•sourceforge.net> wrote:
    >
    > > Send Bitcoin-development mailing list submissions to
    > >       bitcoin-development@lists•sourceforge.net
    > >
    > > To subscribe or unsubscribe via the World Wide Web, visit
    > >       https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > > or, via email, send a message with subject or body 'help' to
    > >       bitcoin-development-request@lists•sourceforge.net
    > >
    > > You can reach the person managing the list at
    > >       bitcoin-development-owner@lists•sourceforge.net
    > >
    > > When replying, please edit your Subject line so it is more specific
    > > than "Re: Contents of Bitcoin-development digest..."
    > >
    > >
    > > Today's Topics:
    > >
    > >   1. Re: "bits": Unit of account (Oliver Egginger)
    > >   2. Re: "bits": Unit of account (Christophe Biocca)
    > >   3. Re: "bits": Unit of account (Gmail)
    > >   4. Re: "bits": Unit of account (Mike Caldwell)
    > >   5. Re: "bits": Unit of account (Justin A)
    > >
    > >
    > > ----------------------------------------------------------------------
    > >
    > > Message: 1
    > > Date: Sun, 20 Apr 2014 20:43:24 +0200
    > > From: Oliver Egginger <bitcoin@olivere•de>
    > > Subject: Re: [Bitcoin-development] "bits": Unit of account
    > > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
    > > Message-ID: <5354154C.1080908@olivere•de>
    > > Content-Type: text/plain; charset=ISO-8859-1
    > >
    > > Hello,
    > >
    > > just my two 'cents':
    > >
    > > Terms arises by itself. Just as most people speak of coins when they
    > > mean bitcoins. I do not see that bitcoin is currently in common use
    > > except for speculation. Therefore no term for smaller units has
    > > established yet. No problem in my eyes. Time will tell.
    > >
    > > - oliver
    > >
    > >
    > >
    > >
    > > ------------------------------
    > >
    > > Message: 2
    > > Date: Sun, 20 Apr 2014 15:19:38 -0400
    > > From: Christophe Biocca <christophe.biocca@gmail•com>
    > > Subject: Re: [Bitcoin-development] "bits": Unit of account
    > > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
    > > Message-ID:
    > >       <CANOOu=9=
    > TAnaCuyh_P2GqHaguyY39xjhj84HSA_x+6F4MOqM_A@mail•gmail.com>
    > > Content-Type: text/plain; charset=UTF-8
    > >
    > > Culturally neutral? "bit" in French phonetically collides with slang
    > > for phallus ("bitte", with a silent "e"). Apparently it means "louse"
    > > in Turkish as well.
    > >
    > > Not that this really would be avoidable with any short word (all the
    > > short possible words are usually taken), but it's not neutral.
    > >
    > > On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin@olivere•de>
    > wrote:
    > >> Hello,
    > >>
    > >> just my two 'cents':
    > >>
    > >> Terms arises by itself. Just as most people speak of coins when they
    > >> mean bitcoins. I do not see that bitcoin is currently in common use
    > >> except for speculation. Therefore no term for smaller units has
    > >> established yet. No problem in my eyes. Time will tell.
    > >>
    > >> - oliver
    > >>
    > >>
    > >>
    > ------------------------------------------------------------------------------
    > >> Learn Graph Databases - Download FREE O'Reilly Book
    > >> "Graph Databases" is the definitive new guide to graph databases and
    > their
    > >> applications. Written by three acclaimed leaders in the field,
    > >> this first edition is now available. Download your free book today!
    > >> http://p.sf.net/sfu/NeoTech
    > >> _______________________________________________
    > >> Bitcoin-development mailing list
    > >> Bitcoin-development@lists•sourceforge.net
    > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > >
    > >
    > >
    > > ------------------------------
    > >
    > > Message: 3
    > > Date: Sun, 20 Apr 2014 14:32:26 -0500
    > > From: Gmail <will.yager@gmail•com>
    > > Subject: Re: [Bitcoin-development] "bits": Unit of account
    > > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
    > > Message-ID: <B687D4AD-263F-4594-BE7A-FF238B8DF7AF@gmail•com>
    > > Content-Type: text/plain; charset="us-ascii"
    > >
    > > People in the Bitcoin community are sometimes resistant to the idea of
    > using the word "credit" as a unit of Bitcoin, because Bitcoin is not a
    > credit-based system.
    > >
    > > However, given that the average person has close to no understanding of
    > what "credit" means, and probably no concern for the distinction even if
    > they do know, it may be wise to use the futuristic and easily
    > understandable "credit" as our human-friendly unit.
    > >
    > > Do others agree that "credits" as a unit of account has a desirable
    > futuristic connotation?
    > >
    > > Will
    > >
    > > -------------- next part --------------
    > > A non-text attachment was scrubbed...
    > > Name: smime.p7s
    > > Type: application/pkcs7-signature
    > > Size: 1593 bytes
    > > Desc: not available
    > >
    > > ------------------------------
    > >
    > > Message: 4
    > > Date: Sun, 20 Apr 2014 16:28:34 -0400
    > > From: Mike Caldwell <mcaldwell@swipeclock•com>
    > > Subject: Re: [Bitcoin-development] "bits": Unit of account
    > > To: Christophe Biocca <christophe.biocca@gmail•com>
    > > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
    > > Message-ID: <4098C706-D67F-474E-9C13-E4C8F56B41ED@swipeclock•com>
    > > Content-Type: text/plain; charset="us-ascii"
    > >
    > > By culturally neutral I mean we avoid deliberately invoking a cultural
    > reference in the name.  For example "satoshi" would be a reference to
    > Japanese culture just for being a common Japanese name regardless of who
    > Satoshi turns out to be.
    > >
    > > Mike
    > >
    > > Sent from my iPhone
    > >
    > >> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
    > christophe.biocca@gmail•com> wrote:
    > >>
    > >> Culturally neutral? "bit" in French phonetically collides with slang
    > >> for phallus ("bitte", with a silent "e"). Apparently it means "louse"
    > >> in Turkish as well.
    > >>
    > >> Not that this really would be avoidable with any short word (all the
    > >> short possible words are usually taken), but it's not neutral.
    > >>
    > >>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin@olivere•de>
    > wrote:
    > >>> Hello,
    > >>>
    > >>> just my two 'cents':
    > >>>
    > >>> Terms arises by itself. Just as most people speak of coins when they
    > >>> mean bitcoins. I do not see that bitcoin is currently in common use
    > >>> except for speculation. Therefore no term for smaller units has
    > >>> established yet. No problem in my eyes. Time will tell.
    > >>>
    > >>> - oliver
    > >>>
    > >>>
    > >>>
    > ------------------------------------------------------------------------------
    > >>> Learn Graph Databases - Download FREE O'Reilly Book
    > >>> "Graph Databases" is the definitive new guide to graph databases and
    > their
    > >>> applications. Written by three acclaimed leaders in the field,
    > >>> this first edition is now available. Download your free book today!
    > >>> http://p.sf.net/sfu/NeoTech
    > >>> _______________________________________________
    > >>> Bitcoin-development mailing list
    > >>> Bitcoin-development@lists•sourceforge.net
    > >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > >>
    > >>
    > ------------------------------------------------------------------------------
    > >> Learn Graph Databases - Download FREE O'Reilly Book
    > >> "Graph Databases" is the definitive new guide to graph databases and
    > their
    > >> applications. Written by three acclaimed leaders in the field,
    > >> this first edition is now available. Download your free book today!
    > >> http://p.sf.net/sfu/NeoTech
    > >> _______________________________________________
    > >> Bitcoin-development mailing list
    > >> Bitcoin-development@lists•sourceforge.net
    > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > >
    > >
    > >
    > > ------------------------------
    > >
    > > Message: 5
    > > Date: Sun, 20 Apr 2014 20:16:35 -0400
    > > From: Justin A <allport@gmail•com>
    > > Subject: Re: [Bitcoin-development] "bits": Unit of account
    > > To: Mike Caldwell <mcaldwell@swipeclock•com>
    > > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
    > > Message-ID:
    > >       <
    > CAK2MuX3GufxU_AH0Kaw3pUkzgX_agok86ahCh+7r96UkxZwneQ@mail•gmail.com>
    > > Content-Type: text/plain; charset="utf-8"
    > >
    > > <delurk>
    > >
    > > What about "ubit", pronounced "YOU-bit", representing 1e-6 bitcoin? Easy
    > to
    > > say, tied in a visual way to the metric micro, leaves the required 2
    > > decimal places for the marginally numerate.. What more could one want?
    > >
    > > </delurk>
    > >
    > > Also, hi. My first post; plan to get involved over the southern
    > hemisphere
    > > winter if I can learn enough.
    > > On Apr 20, 2014 4:32 PM, "Mike Caldwell" <mcaldwell@swipeclock•com>
    > wrote:
    > >
    > >> By culturally neutral I mean we avoid deliberately invoking a cultural
    > >> reference in the name.  For example "satoshi" would be a reference to
    > >> Japanese culture just for being a common Japanese name regardless of who
    > >> Satoshi turns out to be.
    > >>
    > >> Mike
    > >>
    > >> Sent from my iPhone
    > >>
    > >>> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
    > >> christophe.biocca@gmail•com> wrote:
    > >>>
    > >>> Culturally neutral? "bit" in French phonetically collides with slang
    > >>> for phallus ("bitte", with a silent "e"). Apparently it means "louse"
    > >>> in Turkish as well.
    > >>>
    > >>> Not that this really would be avoidable with any short word (all the
    > >>> short possible words are usually taken), but it's not neutral.
    > >>>
    > >>>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin@olivere•de>
    > >> wrote:
    > >>>> Hello,
    > >>>>
    > >>>> just my two 'cents':
    > >>>>
    > >>>> Terms arises by itself. Just as most people speak of coins when they
    > >>>> mean bitcoins. I do not see that bitcoin is currently in common use
    > >>>> except for speculation. Therefore no term for smaller units has
    > >>>> established yet. No problem in my eyes. Time will tell.
    > >>>>
    > >>>> - oliver
    > >>>>
    > >>>>
    > >>>>
    > >>
    > ------------------------------------------------------------------------------
    > >>>> Learn Graph Databases - Download FREE O'Reilly Book
    > >>>> "Graph Databases" is the definitive new guide to graph databases and
    > >> their
    > >>>> applications. Written by three acclaimed leaders in the field,
    > >>>> this first edition is now available. Download your free book today!
    > >>>> http://p.sf.net/sfu/NeoTech
    > >>>> _______________________________________________
    > >>>> Bitcoin-development mailing list
    > >>>> Bitcoin-development@lists•sourceforge.net
    > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > >>>
    > >>>
    > >>
    > ------------------------------------------------------------------------------
    > >>> Learn Graph Databases - Download FREE O'Reilly Book
    > >>> "Graph Databases" is the definitive new guide to graph databases and
    > >> their
    > >>> applications. Written by three acclaimed leaders in the field,
    > >>> this first edition is now available. Download your free book today!
    > >>> http://p.sf.net/sfu/NeoTech
    > >>> _______________________________________________
    > >>> Bitcoin-development mailing list
    > >>> Bitcoin-development@lists•sourceforge.net
    > >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > >>
    > >>
    > >>
    > ------------------------------------------------------------------------------
    > >> Learn Graph Databases - Download FREE O'Reilly Book
    > >> "Graph Databases" is the definitive new guide to graph databases and
    > their
    > >> applications. Written by three acclaimed leaders in the field,
    > >> this first edition is now available. Download your free book today!
    > >> http://p.sf.net/sfu/NeoTech
    > >> _______________________________________________
    > >> Bitcoin-development mailing list
    > >> Bitcoin-development@lists•sourceforge.net
    > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > >>
    > > -------------- next part --------------
    > > An HTML attachment was scrubbed...
    > >
    > > ------------------------------
    > >
    > >
    > ------------------------------------------------------------------------------
    > > 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
    > >
    > >
    > > End of Bitcoin-development Digest, Vol 35, Issue 72
    > > ***************************************************
    >
    >
    >
    > ------------------------------------------------------------------------------
    > 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
    >
    >
    
    [-- Attachment #2: Type: text/html, Size: 23886 bytes --]
    
    ^ permalink raw reply	[flat|nested] 21+ messages in thread

  • • * Re: [Bitcoin-development] Economics of information propagation
        2014-04-21  3:58   ` Mark Friedenbach
      @ 2014-04-21  4:06     ` Peter Todd
        2014-04-21  4:44       ` Daniel Lidstrom
                               ` (3 more replies)
        0 siblings, 4 replies; 21+ messages in thread
      From: Peter Todd @ 2014-04-21  4:06 UTC (permalink / raw)
        To: Mark Friedenbach, Jonathan Levin; +Cc: bitcoin-development
      
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA256
      
      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.
      
      
      On 20 April 2014 23:58:58 GMT-04:00, Mark Friedenbach <mark@monetize•io> wrote:
      >As soon as we switch to headers
      >first - which will be soon - there will be no difference in propagation
      >time no matter how large the block is. Only 80 bites will be required
      >to
      >propagate the block header which establishes priority for when the
      >block is
      >fully validated.
      >On Apr 20, 2014 6:56 PM, "Jonathan Levin"
      ><jonathan.levin@sant•ox.ac.uk>
      >wrote:
      >
      >> Hi all,
      >>
      >> I am a post-graduate economist writing a paper on the incentives of
      >> mining. Even though this issue has been debated in the forums, I
      >think it
      >> is important to get a sense of the magnitude of the incentives at
      >play and
      >> determine what implications this has for the transaction fee market.
      >>
      >> As it has been pointed out before the marginal cost for miners does
      >not
      >> stem from the private cost of the miner validating the signature and
      >> including it in the list of transactions in the block but rather the
      >> increased probability that the block will be orphaned as a result of
      >slower
      >> propagation. Gavin did some back of the envelope worst case
      >calculations
      >> but these overstated the effect of propagation delay. The reason
      >being the
      >> 80ms additional time to reach 50% of the network is spread throughout
      >the
      >> time that it takes to reach 50% of the network. During this time
      >miners are
      >> notified about the block and treat it as the longest chain and hence
      >are no
      >> longer mining with the aim to produce a competing block.
      >>
      >> I am looking to calculate the change in the curvature of the
      >probability
      >> mass function that a block hears about my block in any given second
      >as a
      >> function of the block size. Although there is likely to be
      >significant
      >> noise here, there seems to be some stable linear relationships with
      >the
      >> time that it takes to reach different quartiles. Has anyone done
      >this? I
      >> have used some empirical data that I am happy to share but ideally I
      >would
      >> like analytical solutions.
      >>
      >> Following Peter Todd, I also find the concerning result that
      >propagation
      >> delays results in increasing returns to higher shares of the hashing
      >power.
      >> Indeed it may well be in the interest of large pools to publish large
      >> blocks to increase propagation delays on the network which would
      >increase
      >> orphan rates particularly for small miners and miners that have not
      >> invested in sufficient bandwidth / connectivity. If a small miner
      >hears
      >> about a block after 4.5 seconds on average there is a 0.7% chance
      >that
      >> there is already a block in circulation.  Large miners can increase
      >the
      >> time that it takes for small miners to hear about blocks by
      >increasing the
      >> size of their blocks. For example if the time that it takes for a
      >small
      >> miner to hear about the block goes to 12 seconds there is a 2 percent
      >> chance there is already a block in circulation for the small miner.
      >There
      >> is also a 1.2% chance that there will be a competing block published
      >after
      >> a small miner propagates in the time that it gets to full
      >propagation. Am I
      >> getting this right that the probability of a miner’s block being
      >orphaned
      >> is comprised of the probability that the miner was not the first to
      >find a
      >> valid block and the probability that given they are first, someone
      >else in
      >> the absence of hearing about it finds a competing valid block.
      >>
      >> One question is: Are orphans probabilistic and only resolved after
      >hearing
      >> about a new block that lengthens the chain or is there a way to know
      >in
      >> advance? Is it frowned upon to mine on top of a block that you have
      >just
      >> found even though it is very likely going to end up an orphan?
      >>
      >> Would be happy to share the draft form of the paper and receive any
      >> feedback.
      >>
      >> Finally, at coinometrics we are working on a modified client to
      >capture
      >> information on network propagation and would invite any suggestions
      >of any
      >> other useful statistics that would be useful in the development of
      >software.
      >>
      >> Best,
      >>
      >> Jonathan
      >>
      >>
      >>
      >>
      >>
      >>
      >>
      >>
      >>
      >>
      >> On 21 Apr 2014, at 01:16, <
      >> bitcoin-development-request@lists•sourceforge.net> <
      >> bitcoin-development-request@lists•sourceforge.net> wrote:
      >>
      >> > Send Bitcoin-development mailing list submissions to
      >> >       bitcoin-development@lists•sourceforge.net
      >> >
      >> > To subscribe or unsubscribe via the World Wide Web, visit
      >> >
      >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> > or, via email, send a message with subject or body 'help' to
      >> >       bitcoin-development-request@lists•sourceforge.net
      >> >
      >> > You can reach the person managing the list at
      >> >       bitcoin-development-owner@lists•sourceforge.net
      >> >
      >> > When replying, please edit your Subject line so it is more specific
      >> > than "Re: Contents of Bitcoin-development digest..."
      >> >
      >> >
      >> > Today's Topics:
      >> >
      >> >   1. Re: "bits": Unit of account (Oliver Egginger)
      >> >   2. Re: "bits": Unit of account (Christophe Biocca)
      >> >   3. Re: "bits": Unit of account (Gmail)
      >> >   4. Re: "bits": Unit of account (Mike Caldwell)
      >> >   5. Re: "bits": Unit of account (Justin A)
      >> >
      >> >
      >> >
      >----------------------------------------------------------------------
      >> >
      >> > Message: 1
      >> > Date: Sun, 20 Apr 2014 20:43:24 +0200
      >> > From: Oliver Egginger <bitcoin@olivere•de>
      >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
      >> > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
      >> > Message-ID: <5354154C.1080908@olivere•de>
      >> > Content-Type: text/plain; charset=ISO-8859-1
      >> >
      >> > Hello,
      >> >
      >> > just my two 'cents':
      >> >
      >> > Terms arises by itself. Just as most people speak of coins when
      >they
      >> > mean bitcoins. I do not see that bitcoin is currently in common use
      >> > except for speculation. Therefore no term for smaller units has
      >> > established yet. No problem in my eyes. Time will tell.
      >> >
      >> > - oliver
      >> >
      >> >
      >> >
      >> >
      >> > ------------------------------
      >> >
      >> > Message: 2
      >> > Date: Sun, 20 Apr 2014 15:19:38 -0400
      >> > From: Christophe Biocca <christophe.biocca@gmail•com>
      >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
      >> > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
      >> > Message-ID:
      >> >       <CANOOu=9=
      >> TAnaCuyh_P2GqHaguyY39xjhj84HSA_x+6F4MOqM_A@mail•gmail.com>
      >> > Content-Type: text/plain; charset=UTF-8
      >> >
      >> > Culturally neutral? "bit" in French phonetically collides with
      >slang
      >> > for phallus ("bitte", with a silent "e"). Apparently it means
      >"louse"
      >> > in Turkish as well.
      >> >
      >> > Not that this really would be avoidable with any short word (all
      >the
      >> > short possible words are usually taken), but it's not neutral.
      >> >
      >> > On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
      ><bitcoin@olivere•de>
      >> wrote:
      >> >> Hello,
      >> >>
      >> >> just my two 'cents':
      >> >>
      >> >> Terms arises by itself. Just as most people speak of coins when
      >they
      >> >> mean bitcoins. I do not see that bitcoin is currently in common
      >use
      >> >> except for speculation. Therefore no term for smaller units has
      >> >> established yet. No problem in my eyes. Time will tell.
      >> >>
      >> >> - oliver
      >> >>
      >> >>
      >> >>
      >>
      >------------------------------------------------------------------------------
      >> >> Learn Graph Databases - Download FREE O'Reilly Book
      >> >> "Graph Databases" is the definitive new guide to graph databases
      >and
      >> their
      >> >> applications. Written by three acclaimed leaders in the field,
      >> >> this first edition is now available. Download your free book
      >today!
      >> >> http://p.sf.net/sfu/NeoTech
      >> >> _______________________________________________
      >> >> Bitcoin-development mailing list
      >> >> Bitcoin-development@lists•sourceforge.net
      >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> >
      >> >
      >> >
      >> > ------------------------------
      >> >
      >> > Message: 3
      >> > Date: Sun, 20 Apr 2014 14:32:26 -0500
      >> > From: Gmail <will.yager@gmail•com>
      >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
      >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
      >> > Message-ID: <B687D4AD-263F-4594-BE7A-FF238B8DF7AF@gmail•com>
      >> > Content-Type: text/plain; charset="us-ascii"
      >> >
      >> > People in the Bitcoin community are sometimes resistant to the idea
      >of
      >> using the word "credit" as a unit of Bitcoin, because Bitcoin is not
      >a
      >> credit-based system.
      >> >
      >> > However, given that the average person has close to no
      >understanding of
      >> what "credit" means, and probably no concern for the distinction even
      >if
      >> they do know, it may be wise to use the futuristic and easily
      >> understandable "credit" as our human-friendly unit.
      >> >
      >> > Do others agree that "credits" as a unit of account has a desirable
      >> futuristic connotation?
      >> >
      >> > Will
      >> >
      >> > -------------- next part --------------
      >> > A non-text attachment was scrubbed...
      >> > Name: smime.p7s
      >> > Type: application/pkcs7-signature
      >> > Size: 1593 bytes
      >> > Desc: not available
      >> >
      >> > ------------------------------
      >> >
      >> > Message: 4
      >> > Date: Sun, 20 Apr 2014 16:28:34 -0400
      >> > From: Mike Caldwell <mcaldwell@swipeclock•com>
      >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
      >> > To: Christophe Biocca <christophe.biocca@gmail•com>
      >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
      >> > Message-ID: <4098C706-D67F-474E-9C13-E4C8F56B41ED@swipeclock•com>
      >> > Content-Type: text/plain; charset="us-ascii"
      >> >
      >> > By culturally neutral I mean we avoid deliberately invoking a
      >cultural
      >> reference in the name.  For example "satoshi" would be a reference to
      >> Japanese culture just for being a common Japanese name regardless of
      >who
      >> Satoshi turns out to be.
      >> >
      >> > Mike
      >> >
      >> > Sent from my iPhone
      >> >
      >> >> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
      >> christophe.biocca@gmail•com> wrote:
      >> >>
      >> >> Culturally neutral? "bit" in French phonetically collides with
      >slang
      >> >> for phallus ("bitte", with a silent "e"). Apparently it means
      >"louse"
      >> >> in Turkish as well.
      >> >>
      >> >> Not that this really would be avoidable with any short word (all
      >the
      >> >> short possible words are usually taken), but it's not neutral.
      >> >>
      >> >>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
      ><bitcoin@olivere•de>
      >> wrote:
      >> >>> Hello,
      >> >>>
      >> >>> just my two 'cents':
      >> >>>
      >> >>> Terms arises by itself. Just as most people speak of coins when
      >they
      >> >>> mean bitcoins. I do not see that bitcoin is currently in common
      >use
      >> >>> except for speculation. Therefore no term for smaller units has
      >> >>> established yet. No problem in my eyes. Time will tell.
      >> >>>
      >> >>> - oliver
      >> >>>
      >> >>>
      >> >>>
      >>
      >------------------------------------------------------------------------------
      >> >>> Learn Graph Databases - Download FREE O'Reilly Book
      >> >>> "Graph Databases" is the definitive new guide to graph databases
      >and
      >> their
      >> >>> applications. Written by three acclaimed leaders in the field,
      >> >>> this first edition is now available. Download your free book
      >today!
      >> >>> http://p.sf.net/sfu/NeoTech
      >> >>> _______________________________________________
      >> >>> Bitcoin-development mailing list
      >> >>> Bitcoin-development@lists•sourceforge.net
      >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> >>
      >> >>
      >>
      >------------------------------------------------------------------------------
      >> >> Learn Graph Databases - Download FREE O'Reilly Book
      >> >> "Graph Databases" is the definitive new guide to graph databases
      >and
      >> their
      >> >> applications. Written by three acclaimed leaders in the field,
      >> >> this first edition is now available. Download your free book
      >today!
      >> >> http://p.sf.net/sfu/NeoTech
      >> >> _______________________________________________
      >> >> Bitcoin-development mailing list
      >> >> Bitcoin-development@lists•sourceforge.net
      >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> >
      >> >
      >> >
      >> > ------------------------------
      >> >
      >> > Message: 5
      >> > Date: Sun, 20 Apr 2014 20:16:35 -0400
      >> > From: Justin A <allport@gmail•com>
      >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
      >> > To: Mike Caldwell <mcaldwell@swipeclock•com>
      >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
      >> > Message-ID:
      >> >       <
      >> CAK2MuX3GufxU_AH0Kaw3pUkzgX_agok86ahCh+7r96UkxZwneQ@mail•gmail.com>
      >> > Content-Type: text/plain; charset="utf-8"
      >> >
      >> > <delurk>
      >> >
      >> > What about "ubit", pronounced "YOU-bit", representing 1e-6 bitcoin?
      >Easy
      >> to
      >> > say, tied in a visual way to the metric micro, leaves the required
      >2
      >> > decimal places for the marginally numerate.. What more could one
      >want?
      >> >
      >> > </delurk>
      >> >
      >> > Also, hi. My first post; plan to get involved over the southern
      >> hemisphere
      >> > winter if I can learn enough.
      >> > On Apr 20, 2014 4:32 PM, "Mike Caldwell" <mcaldwell@swipeclock•com>
      >> wrote:
      >> >
      >> >> By culturally neutral I mean we avoid deliberately invoking a
      >cultural
      >> >> reference in the name.  For example "satoshi" would be a reference
      >to
      >> >> Japanese culture just for being a common Japanese name regardless
      >of who
      >> >> Satoshi turns out to be.
      >> >>
      >> >> Mike
      >> >>
      >> >> Sent from my iPhone
      >> >>
      >> >>> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
      >> >> christophe.biocca@gmail•com> wrote:
      >> >>>
      >> >>> Culturally neutral? "bit" in French phonetically collides with
      >slang
      >> >>> for phallus ("bitte", with a silent "e"). Apparently it means
      >"louse"
      >> >>> in Turkish as well.
      >> >>>
      >> >>> Not that this really would be avoidable with any short word (all
      >the
      >> >>> short possible words are usually taken), but it's not neutral.
      >> >>>
      >> >>>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
      ><bitcoin@olivere•de>
      >> >> wrote:
      >> >>>> Hello,
      >> >>>>
      >> >>>> just my two 'cents':
      >> >>>>
      >> >>>> Terms arises by itself. Just as most people speak of coins when
      >they
      >> >>>> mean bitcoins. I do not see that bitcoin is currently in common
      >use
      >> >>>> except for speculation. Therefore no term for smaller units has
      >> >>>> established yet. No problem in my eyes. Time will tell.
      >> >>>>
      >> >>>> - oliver
      >> >>>>
      >> >>>>
      >> >>>>
      >> >>
      >>
      >------------------------------------------------------------------------------
      >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
      >> >>>> "Graph Databases" is the definitive new guide to graph databases
      >and
      >> >> their
      >> >>>> applications. Written by three acclaimed leaders in the field,
      >> >>>> this first edition is now available. Download your free book
      >today!
      >> >>>> http://p.sf.net/sfu/NeoTech
      >> >>>> _______________________________________________
      >> >>>> Bitcoin-development mailing list
      >> >>>> Bitcoin-development@lists•sourceforge.net
      >> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> >>>
      >> >>>
      >> >>
      >>
      >------------------------------------------------------------------------------
      >> >>> Learn Graph Databases - Download FREE O'Reilly Book
      >> >>> "Graph Databases" is the definitive new guide to graph databases
      >and
      >> >> their
      >> >>> applications. Written by three acclaimed leaders in the field,
      >> >>> this first edition is now available. Download your free book
      >today!
      >> >>> http://p.sf.net/sfu/NeoTech
      >> >>> _______________________________________________
      >> >>> Bitcoin-development mailing list
      >> >>> Bitcoin-development@lists•sourceforge.net
      >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> >>
      >> >>
      >> >>
      >>
      >------------------------------------------------------------------------------
      >> >> Learn Graph Databases - Download FREE O'Reilly Book
      >> >> "Graph Databases" is the definitive new guide to graph databases
      >and
      >> their
      >> >> applications. Written by three acclaimed leaders in the field,
      >> >> this first edition is now available. Download your free book
      >today!
      >> >> http://p.sf.net/sfu/NeoTech
      >> >> _______________________________________________
      >> >> Bitcoin-development mailing list
      >> >> Bitcoin-development@lists•sourceforge.net
      >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> >>
      >> > -------------- next part --------------
      >> > An HTML attachment was scrubbed...
      >> >
      >> > ------------------------------
      >> >
      >> >
      >>
      >------------------------------------------------------------------------------
      >> > 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
      >> >
      >> >
      >> > End of Bitcoin-development Digest, Vol 35, Issue 72
      >> > ***************************************************
      >>
      >>
      >>
      >>
      >------------------------------------------------------------------------------
      >> 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
      -----BEGIN PGP SIGNATURE-----
      Version: APG v1.1.1
      
      iQFQBAEBCAA6BQJTVJlDMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
      cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTbNB/4lHTsUN/iee7H0UyBn
      +TDRgf1BSoUx9HP+vtwXzS0JkVQoxoB5x4Pls+ex7qIXGNxdG9EPYi1RqQ5A8RUo
      X2ntOL2pj6qTmW4aYxqqyihiQayLs5ixHPmJxqHv343g5ekqsKmBeDuWR4hXjUyZ
      0Pfcp40Xd3eJ38dSbq98letl5eD+ryBPKYtb91Trumqa9S0WB8kw9IqNaXjlpfG1
      lYuaVEllpaLpZW+4cx1mlPneS1GmLvloWhXf4Qh4X39VXECAjOAmNKh1atJCyT7H
      ugkOcx1F2Rxo5P3jNzBRJKyAD96sbOhKm4sX7rzSjhT3WJgyHtJm3wkeluDCOVbR
      QZqK
      =R7Tv
      -----END PGP SIGNATURE-----
      
      
      
      
      ^ permalink raw reply	[flat|nested] 21+ messages in thread

    • • * Re: [Bitcoin-development] Economics of information propagation
          2014-04-21  4:06     ` Peter Todd
        @ 2014-04-21  4:44       ` Daniel Lidstrom
          2014-04-21  5:46         ` Daniel Lidstrom
          2014-04-21 11:34       ` Tier Nolan
                                 ` (2 subsequent siblings)
          3 siblings, 1 reply; 21+ messages in thread
        From: Daniel Lidstrom @ 2014-04-21  4:44 UTC (permalink / raw)
          To: Peter Todd; +Cc: Bitcoin Dev, Jonathan Levin
        
        [-- Attachment #1: Type: text/plain, Size: 22318 bytes --]
        
        > 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.
        
        
        If it's only during the few seconds that it takes to to verify the block,
        then would this really be that big of a deal?  E.g. even if all miners did
        this, a 10 second delay would only yield an average of a couple blind/empty
        blocks per day.
        
        
        On Sun, Apr 20, 2014 at 10:06 PM, Peter Todd <pete@petertodd•org> wrote:
        
        > -----BEGIN PGP SIGNED MESSAGE-----
        > Hash: SHA256
        >
        > 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.
        >
        >
        > On 20 April 2014 23:58:58 GMT-04:00, Mark Friedenbach <mark@monetize•io>
        > wrote:
        > >As soon as we switch to headers
        > >first - which will be soon - there will be no difference in propagation
        > >time no matter how large the block is. Only 80 bites will be required
        > >to
        > >propagate the block header which establishes priority for when the
        > >block is
        > >fully validated.
        > >On Apr 20, 2014 6:56 PM, "Jonathan Levin"
        > ><jonathan.levin@sant•ox.ac.uk>
        > >wrote:
        > >
        > >> Hi all,
        > >>
        > >> I am a post-graduate economist writing a paper on the incentives of
        > >> mining. Even though this issue has been debated in the forums, I
        > >think it
        > >> is important to get a sense of the magnitude of the incentives at
        > >play and
        > >> determine what implications this has for the transaction fee market.
        > >>
        > >> As it has been pointed out before the marginal cost for miners does
        > >not
        > >> stem from the private cost of the miner validating the signature and
        > >> including it in the list of transactions in the block but rather the
        > >> increased probability that the block will be orphaned as a result of
        > >slower
        > >> propagation. Gavin did some back of the envelope worst case
        > >calculations
        > >> but these overstated the effect of propagation delay. The reason
        > >being the
        > >> 80ms additional time to reach 50% of the network is spread throughout
        > >the
        > >> time that it takes to reach 50% of the network. During this time
        > >miners are
        > >> notified about the block and treat it as the longest chain and hence
        > >are no
        > >> longer mining with the aim to produce a competing block.
        > >>
        > >> I am looking to calculate the change in the curvature of the
        > >probability
        > >> mass function that a block hears about my block in any given second
        > >as a
        > >> function of the block size. Although there is likely to be
        > >significant
        > >> noise here, there seems to be some stable linear relationships with
        > >the
        > >> time that it takes to reach different quartiles. Has anyone done
        > >this? I
        > >> have used some empirical data that I am happy to share but ideally I
        > >would
        > >> like analytical solutions.
        > >>
        > >> Following Peter Todd, I also find the concerning result that
        > >propagation
        > >> delays results in increasing returns to higher shares of the hashing
        > >power.
        > >> Indeed it may well be in the interest of large pools to publish large
        > >> blocks to increase propagation delays on the network which would
        > >increase
        > >> orphan rates particularly for small miners and miners that have not
        > >> invested in sufficient bandwidth / connectivity. If a small miner
        > >hears
        > >> about a block after 4.5 seconds on average there is a 0.7% chance
        > >that
        > >> there is already a block in circulation.  Large miners can increase
        > >the
        > >> time that it takes for small miners to hear about blocks by
        > >increasing the
        > >> size of their blocks. For example if the time that it takes for a
        > >small
        > >> miner to hear about the block goes to 12 seconds there is a 2 percent
        > >> chance there is already a block in circulation for the small miner.
        > >There
        > >> is also a 1.2% chance that there will be a competing block published
        > >after
        > >> a small miner propagates in the time that it gets to full
        > >propagation. Am I
        > >> getting this right that the probability of a miner’s block being
        > >orphaned
        > >> is comprised of the probability that the miner was not the first to
        > >find a
        > >> valid block and the probability that given they are first, someone
        > >else in
        > >> the absence of hearing about it finds a competing valid block.
        > >>
        > >> One question is: Are orphans probabilistic and only resolved after
        > >hearing
        > >> about a new block that lengthens the chain or is there a way to know
        > >in
        > >> advance? Is it frowned upon to mine on top of a block that you have
        > >just
        > >> found even though it is very likely going to end up an orphan?
        > >>
        > >> Would be happy to share the draft form of the paper and receive any
        > >> feedback.
        > >>
        > >> Finally, at coinometrics we are working on a modified client to
        > >capture
        > >> information on network propagation and would invite any suggestions
        > >of any
        > >> other useful statistics that would be useful in the development of
        > >software.
        > >>
        > >> Best,
        > >>
        > >> Jonathan
        > >>
        > >>
        > >>
        > >>
        > >>
        > >>
        > >>
        > >>
        > >>
        > >>
        > >> On 21 Apr 2014, at 01:16, <
        > >> bitcoin-development-request@lists•sourceforge.net> <
        > >> bitcoin-development-request@lists•sourceforge.net> wrote:
        > >>
        > >> > Send Bitcoin-development mailing list submissions to
        > >> >       bitcoin-development@lists•sourceforge.net
        > >> >
        > >> > To subscribe or unsubscribe via the World Wide Web, visit
        > >> >
        > >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        > >> > or, via email, send a message with subject or body 'help' to
        > >> >       bitcoin-development-request@lists•sourceforge.net
        > >> >
        > >> > You can reach the person managing the list at
        > >> >       bitcoin-development-owner@lists•sourceforge.net
        > >> >
        > >> > When replying, please edit your Subject line so it is more specific
        > >> > than "Re: Contents of Bitcoin-development digest..."
        > >> >
        > >> >
        > >> > Today's Topics:
        > >> >
        > >> >   1. Re: "bits": Unit of account (Oliver Egginger)
        > >> >   2. Re: "bits": Unit of account (Christophe Biocca)
        > >> >   3. Re: "bits": Unit of account (Gmail)
        > >> >   4. Re: "bits": Unit of account (Mike Caldwell)
        > >> >   5. Re: "bits": Unit of account (Justin A)
        > >> >
        > >> >
        > >> >
        > >----------------------------------------------------------------------
        > >> >
        > >> > Message: 1
        > >> > Date: Sun, 20 Apr 2014 20:43:24 +0200
        > >> > From: Oliver Egginger <bitcoin@olivere•de>
        > >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
        > >> > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
        > >> > Message-ID: <5354154C.1080908@olivere•de>
        > >> > Content-Type: text/plain; charset=ISO-8859-1
        > >> >
        > >> > Hello,
        > >> >
        > >> > just my two 'cents':
        > >> >
        > >> > Terms arises by itself. Just as most people speak of coins when
        > >they
        > >> > mean bitcoins. I do not see that bitcoin is currently in common use
        > >> > except for speculation. Therefore no term for smaller units has
        > >> > established yet. No problem in my eyes. Time will tell.
        > >> >
        > >> > - oliver
        > >> >
        > >> >
        > >> >
        > >> >
        > >> > ------------------------------
        > >> >
        > >> > Message: 2
        > >> > Date: Sun, 20 Apr 2014 15:19:38 -0400
        > >> > From: Christophe Biocca <christophe.biocca@gmail•com>
        > >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
        > >> > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
        > >> > Message-ID:
        > >> >       <CANOOu=9=
        > >> TAnaCuyh_P2GqHaguyY39xjhj84HSA_x+6F4MOqM_A@mail•gmail.com>
        > >> > Content-Type: text/plain; charset=UTF-8
        > >> >
        > >> > Culturally neutral? "bit" in French phonetically collides with
        > >slang
        > >> > for phallus ("bitte", with a silent "e"). Apparently it means
        > >"louse"
        > >> > in Turkish as well.
        > >> >
        > >> > Not that this really would be avoidable with any short word (all
        > >the
        > >> > short possible words are usually taken), but it's not neutral.
        > >> >
        > >> > On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
        > ><bitcoin@olivere•de>
        > >> wrote:
        > >> >> Hello,
        > >> >>
        > >> >> just my two 'cents':
        > >> >>
        > >> >> Terms arises by itself. Just as most people speak of coins when
        > >they
        > >> >> mean bitcoins. I do not see that bitcoin is currently in common
        > >use
        > >> >> except for speculation. Therefore no term for smaller units has
        > >> >> established yet. No problem in my eyes. Time will tell.
        > >> >>
        > >> >> - oliver
        > >> >>
        > >> >>
        > >> >>
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> >> Learn Graph Databases - Download FREE O'Reilly Book
        > >> >> "Graph Databases" is the definitive new guide to graph databases
        > >and
        > >> their
        > >> >> applications. Written by three acclaimed leaders in the field,
        > >> >> this first edition is now available. Download your free book
        > >today!
        > >> >> http://p.sf.net/sfu/NeoTech
        > >> >> _______________________________________________
        > >> >> Bitcoin-development mailing list
        > >> >> Bitcoin-development@lists•sourceforge.net
        > >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        > >> >
        > >> >
        > >> >
        > >> > ------------------------------
        > >> >
        > >> > Message: 3
        > >> > Date: Sun, 20 Apr 2014 14:32:26 -0500
        > >> > From: Gmail <will.yager@gmail•com>
        > >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
        > >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
        > >> > Message-ID: <B687D4AD-263F-4594-BE7A-FF238B8DF7AF@gmail•com>
        > >> > Content-Type: text/plain; charset="us-ascii"
        > >> >
        > >> > People in the Bitcoin community are sometimes resistant to the idea
        > >of
        > >> using the word "credit" as a unit of Bitcoin, because Bitcoin is not
        > >a
        > >> credit-based system.
        > >> >
        > >> > However, given that the average person has close to no
        > >understanding of
        > >> what "credit" means, and probably no concern for the distinction even
        > >if
        > >> they do know, it may be wise to use the futuristic and easily
        > >> understandable "credit" as our human-friendly unit.
        > >> >
        > >> > Do others agree that "credits" as a unit of account has a desirable
        > >> futuristic connotation?
        > >> >
        > >> > Will
        > >> >
        > >> > -------------- next part --------------
        > >> > A non-text attachment was scrubbed...
        > >> > Name: smime.p7s
        > >> > Type: application/pkcs7-signature
        > >> > Size: 1593 bytes
        > >> > Desc: not available
        > >> >
        > >> > ------------------------------
        > >> >
        > >> > Message: 4
        > >> > Date: Sun, 20 Apr 2014 16:28:34 -0400
        > >> > From: Mike Caldwell <mcaldwell@swipeclock•com>
        > >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
        > >> > To: Christophe Biocca <christophe.biocca@gmail•com>
        > >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
        > >> > Message-ID: <4098C706-D67F-474E-9C13-E4C8F56B41ED@swipeclock•com>
        > >> > Content-Type: text/plain; charset="us-ascii"
        > >> >
        > >> > By culturally neutral I mean we avoid deliberately invoking a
        > >cultural
        > >> reference in the name.  For example "satoshi" would be a reference to
        > >> Japanese culture just for being a common Japanese name regardless of
        > >who
        > >> Satoshi turns out to be.
        > >> >
        > >> > Mike
        > >> >
        > >> > Sent from my iPhone
        > >> >
        > >> >> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
        > >> christophe.biocca@gmail•com> wrote:
        > >> >>
        > >> >> Culturally neutral? "bit" in French phonetically collides with
        > >slang
        > >> >> for phallus ("bitte", with a silent "e"). Apparently it means
        > >"louse"
        > >> >> in Turkish as well.
        > >> >>
        > >> >> Not that this really would be avoidable with any short word (all
        > >the
        > >> >> short possible words are usually taken), but it's not neutral.
        > >> >>
        > >> >>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
        > ><bitcoin@olivere•de>
        > >> wrote:
        > >> >>> Hello,
        > >> >>>
        > >> >>> just my two 'cents':
        > >> >>>
        > >> >>> Terms arises by itself. Just as most people speak of coins when
        > >they
        > >> >>> mean bitcoins. I do not see that bitcoin is currently in common
        > >use
        > >> >>> except for speculation. Therefore no term for smaller units has
        > >> >>> established yet. No problem in my eyes. Time will tell.
        > >> >>>
        > >> >>> - oliver
        > >> >>>
        > >> >>>
        > >> >>>
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> >>> Learn Graph Databases - Download FREE O'Reilly Book
        > >> >>> "Graph Databases" is the definitive new guide to graph databases
        > >and
        > >> their
        > >> >>> applications. Written by three acclaimed leaders in the field,
        > >> >>> this first edition is now available. Download your free book
        > >today!
        > >> >>> http://p.sf.net/sfu/NeoTech
        > >> >>> _______________________________________________
        > >> >>> Bitcoin-development mailing list
        > >> >>> Bitcoin-development@lists•sourceforge.net
        > >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        > >> >>
        > >> >>
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> >> Learn Graph Databases - Download FREE O'Reilly Book
        > >> >> "Graph Databases" is the definitive new guide to graph databases
        > >and
        > >> their
        > >> >> applications. Written by three acclaimed leaders in the field,
        > >> >> this first edition is now available. Download your free book
        > >today!
        > >> >> http://p.sf.net/sfu/NeoTech
        > >> >> _______________________________________________
        > >> >> Bitcoin-development mailing list
        > >> >> Bitcoin-development@lists•sourceforge.net
        > >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        > >> >
        > >> >
        > >> >
        > >> > ------------------------------
        > >> >
        > >> > Message: 5
        > >> > Date: Sun, 20 Apr 2014 20:16:35 -0400
        > >> > From: Justin A <allport@gmail•com>
        > >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
        > >> > To: Mike Caldwell <mcaldwell@swipeclock•com>
        > >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
        > >> > Message-ID:
        > >> >       <
        > >> CAK2MuX3GufxU_AH0Kaw3pUkzgX_agok86ahCh+7r96UkxZwneQ@mail•gmail.com>
        > >> > Content-Type: text/plain; charset="utf-8"
        > >> >
        > >> > <delurk>
        > >> >
        > >> > What about "ubit", pronounced "YOU-bit", representing 1e-6 bitcoin?
        > >Easy
        > >> to
        > >> > say, tied in a visual way to the metric micro, leaves the required
        > >2
        > >> > decimal places for the marginally numerate.. What more could one
        > >want?
        > >> >
        > >> > </delurk>
        > >> >
        > >> > Also, hi. My first post; plan to get involved over the southern
        > >> hemisphere
        > >> > winter if I can learn enough.
        > >> > On Apr 20, 2014 4:32 PM, "Mike Caldwell" <mcaldwell@swipeclock•com>
        > >> wrote:
        > >> >
        > >> >> By culturally neutral I mean we avoid deliberately invoking a
        > >cultural
        > >> >> reference in the name.  For example "satoshi" would be a reference
        > >to
        > >> >> Japanese culture just for being a common Japanese name regardless
        > >of who
        > >> >> Satoshi turns out to be.
        > >> >>
        > >> >> Mike
        > >> >>
        > >> >> Sent from my iPhone
        > >> >>
        > >> >>> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
        > >> >> christophe.biocca@gmail•com> wrote:
        > >> >>>
        > >> >>> Culturally neutral? "bit" in French phonetically collides with
        > >slang
        > >> >>> for phallus ("bitte", with a silent "e"). Apparently it means
        > >"louse"
        > >> >>> in Turkish as well.
        > >> >>>
        > >> >>> Not that this really would be avoidable with any short word (all
        > >the
        > >> >>> short possible words are usually taken), but it's not neutral.
        > >> >>>
        > >> >>>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
        > ><bitcoin@olivere•de>
        > >> >> wrote:
        > >> >>>> Hello,
        > >> >>>>
        > >> >>>> just my two 'cents':
        > >> >>>>
        > >> >>>> Terms arises by itself. Just as most people speak of coins when
        > >they
        > >> >>>> mean bitcoins. I do not see that bitcoin is currently in common
        > >use
        > >> >>>> except for speculation. Therefore no term for smaller units has
        > >> >>>> established yet. No problem in my eyes. Time will tell.
        > >> >>>>
        > >> >>>> - oliver
        > >> >>>>
        > >> >>>>
        > >> >>>>
        > >> >>
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
        > >> >>>> "Graph Databases" is the definitive new guide to graph databases
        > >and
        > >> >> their
        > >> >>>> applications. Written by three acclaimed leaders in the field,
        > >> >>>> this first edition is now available. Download your free book
        > >today!
        > >> >>>> http://p.sf.net/sfu/NeoTech
        > >> >>>> _______________________________________________
        > >> >>>> Bitcoin-development mailing list
        > >> >>>> Bitcoin-development@lists•sourceforge.net
        > >> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        > >> >>>
        > >> >>>
        > >> >>
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> >>> Learn Graph Databases - Download FREE O'Reilly Book
        > >> >>> "Graph Databases" is the definitive new guide to graph databases
        > >and
        > >> >> their
        > >> >>> applications. Written by three acclaimed leaders in the field,
        > >> >>> this first edition is now available. Download your free book
        > >today!
        > >> >>> http://p.sf.net/sfu/NeoTech
        > >> >>> _______________________________________________
        > >> >>> Bitcoin-development mailing list
        > >> >>> Bitcoin-development@lists•sourceforge.net
        > >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        > >> >>
        > >> >>
        > >> >>
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> >> Learn Graph Databases - Download FREE O'Reilly Book
        > >> >> "Graph Databases" is the definitive new guide to graph databases
        > >and
        > >> their
        > >> >> applications. Written by three acclaimed leaders in the field,
        > >> >> this first edition is now available. Download your free book
        > >today!
        > >> >> http://p.sf.net/sfu/NeoTech
        > >> >> _______________________________________________
        > >> >> Bitcoin-development mailing list
        > >> >> Bitcoin-development@lists•sourceforge.net
        > >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        > >> >>
        > >> > -------------- next part --------------
        > >> > An HTML attachment was scrubbed...
        > >> >
        > >> > ------------------------------
        > >> >
        > >> >
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> > 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
        > >> >
        > >> >
        > >> > End of Bitcoin-development Digest, Vol 35, Issue 72
        > >> > ***************************************************
        > >>
        > >>
        > >>
        > >>
        >
        > >------------------------------------------------------------------------------
        > >> 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
        > -----BEGIN PGP SIGNATURE-----
        > Version: APG v1.1.1
        >
        > iQFQBAEBCAA6BQJTVJlDMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
        > cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTbNB/4lHTsUN/iee7H0UyBn
        > +TDRgf1BSoUx9HP+vtwXzS0JkVQoxoB5x4Pls+ex7qIXGNxdG9EPYi1RqQ5A8RUo
        > X2ntOL2pj6qTmW4aYxqqyihiQayLs5ixHPmJxqHv343g5ekqsKmBeDuWR4hXjUyZ
        > 0Pfcp40Xd3eJ38dSbq98letl5eD+ryBPKYtb91Trumqa9S0WB8kw9IqNaXjlpfG1
        > lYuaVEllpaLpZW+4cx1mlPneS1GmLvloWhXf4Qh4X39VXECAjOAmNKh1atJCyT7H
        > ugkOcx1F2Rxo5P3jNzBRJKyAD96sbOhKm4sX7rzSjhT3WJgyHtJm3wkeluDCOVbR
        > QZqK
        > =R7Tv
        > -----END PGP SIGNATURE-----
        >
        >
        >
        > ------------------------------------------------------------------------------
        > 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
        >
        
        [-- Attachment #2: Type: text/html, Size: 33044 bytes --]
        
        ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • • * Re: [Bitcoin-development] Economics of information propagation
            2014-04-21  4:44       ` Daniel Lidstrom
          @ 2014-04-21  5:46         ` Daniel Lidstrom
            0 siblings, 0 replies; 21+ messages in thread
          From: Daniel Lidstrom @ 2014-04-21  5:46 UTC (permalink / raw)
            To: Peter Todd; +Cc: Bitcoin Dev, Jonathan Levin
          
          [-- Attachment #1: Type: text/plain, Size: 23287 bytes --]
          
          If this policy of mining empty blocks upon new block headers before
          downloading and verifying the blocks became the standard, then wouldn't the
          marginal orphan probability per transaction vanish?  It seems like this
          could be a way to seriously reduce transaction fees.
          
          
          On Sun, Apr 20, 2014 at 10:44 PM, Daniel Lidstrom <lidstrom83@gmail•com>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.
          >
          >
          > If it's only during the few seconds that it takes to to verify the block,
          > then would this really be that big of a deal?  E.g. even if all miners did
          > this, a 10 second delay would only yield an average of a couple blind/empty
          > blocks per day.
          >
          >
          > On Sun, Apr 20, 2014 at 10:06 PM, Peter Todd <pete@petertodd•org> wrote:
          >
          >> -----BEGIN PGP SIGNED MESSAGE-----
          >> Hash: SHA256
          >>
          >> 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.
          >>
          >>
          >> On 20 April 2014 23:58:58 GMT-04:00, Mark Friedenbach <mark@monetize•io>
          >> wrote:
          >> >As soon as we switch to headers
          >> >first - which will be soon - there will be no difference in propagation
          >> >time no matter how large the block is. Only 80 bites will be required
          >> >to
          >> >propagate the block header which establishes priority for when the
          >> >block is
          >> >fully validated.
          >> >On Apr 20, 2014 6:56 PM, "Jonathan Levin"
          >> ><jonathan.levin@sant•ox.ac.uk>
          >> >wrote:
          >> >
          >> >> Hi all,
          >> >>
          >> >> I am a post-graduate economist writing a paper on the incentives of
          >> >> mining. Even though this issue has been debated in the forums, I
          >> >think it
          >> >> is important to get a sense of the magnitude of the incentives at
          >> >play and
          >> >> determine what implications this has for the transaction fee market.
          >> >>
          >> >> As it has been pointed out before the marginal cost for miners does
          >> >not
          >> >> stem from the private cost of the miner validating the signature and
          >> >> including it in the list of transactions in the block but rather the
          >> >> increased probability that the block will be orphaned as a result of
          >> >slower
          >> >> propagation. Gavin did some back of the envelope worst case
          >> >calculations
          >> >> but these overstated the effect of propagation delay. The reason
          >> >being the
          >> >> 80ms additional time to reach 50% of the network is spread throughout
          >> >the
          >> >> time that it takes to reach 50% of the network. During this time
          >> >miners are
          >> >> notified about the block and treat it as the longest chain and hence
          >> >are no
          >> >> longer mining with the aim to produce a competing block.
          >> >>
          >> >> I am looking to calculate the change in the curvature of the
          >> >probability
          >> >> mass function that a block hears about my block in any given second
          >> >as a
          >> >> function of the block size. Although there is likely to be
          >> >significant
          >> >> noise here, there seems to be some stable linear relationships with
          >> >the
          >> >> time that it takes to reach different quartiles. Has anyone done
          >> >this? I
          >> >> have used some empirical data that I am happy to share but ideally I
          >> >would
          >> >> like analytical solutions.
          >> >>
          >> >> Following Peter Todd, I also find the concerning result that
          >> >propagation
          >> >> delays results in increasing returns to higher shares of the hashing
          >> >power.
          >> >> Indeed it may well be in the interest of large pools to publish large
          >> >> blocks to increase propagation delays on the network which would
          >> >increase
          >> >> orphan rates particularly for small miners and miners that have not
          >> >> invested in sufficient bandwidth / connectivity. If a small miner
          >> >hears
          >> >> about a block after 4.5 seconds on average there is a 0.7% chance
          >> >that
          >> >> there is already a block in circulation.  Large miners can increase
          >> >the
          >> >> time that it takes for small miners to hear about blocks by
          >> >increasing the
          >> >> size of their blocks. For example if the time that it takes for a
          >> >small
          >> >> miner to hear about the block goes to 12 seconds there is a 2 percent
          >> >> chance there is already a block in circulation for the small miner.
          >> >There
          >> >> is also a 1.2% chance that there will be a competing block published
          >> >after
          >> >> a small miner propagates in the time that it gets to full
          >> >propagation. Am I
          >> >> getting this right that the probability of a miner’s block being
          >> >orphaned
          >> >> is comprised of the probability that the miner was not the first to
          >> >find a
          >> >> valid block and the probability that given they are first, someone
          >> >else in
          >> >> the absence of hearing about it finds a competing valid block.
          >> >>
          >> >> One question is: Are orphans probabilistic and only resolved after
          >> >hearing
          >> >> about a new block that lengthens the chain or is there a way to know
          >> >in
          >> >> advance? Is it frowned upon to mine on top of a block that you have
          >> >just
          >> >> found even though it is very likely going to end up an orphan?
          >> >>
          >> >> Would be happy to share the draft form of the paper and receive any
          >> >> feedback.
          >> >>
          >> >> Finally, at coinometrics we are working on a modified client to
          >> >capture
          >> >> information on network propagation and would invite any suggestions
          >> >of any
          >> >> other useful statistics that would be useful in the development of
          >> >software.
          >> >>
          >> >> Best,
          >> >>
          >> >> Jonathan
          >> >>
          >> >>
          >> >>
          >> >>
          >> >>
          >> >>
          >> >>
          >> >>
          >> >>
          >> >>
          >> >> On 21 Apr 2014, at 01:16, <
          >> >> bitcoin-development-request@lists•sourceforge.net> <
          >> >> bitcoin-development-request@lists•sourceforge.net> wrote:
          >> >>
          >> >> > Send Bitcoin-development mailing list submissions to
          >> >> >       bitcoin-development@lists•sourceforge.net
          >> >> >
          >> >> > To subscribe or unsubscribe via the World Wide Web, visit
          >> >> >
          >> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >> >> > or, via email, send a message with subject or body 'help' to
          >> >> >       bitcoin-development-request@lists•sourceforge.net
          >> >> >
          >> >> > You can reach the person managing the list at
          >> >> >       bitcoin-development-owner@lists•sourceforge.net
          >> >> >
          >> >> > When replying, please edit your Subject line so it is more specific
          >> >> > than "Re: Contents of Bitcoin-development digest..."
          >> >> >
          >> >> >
          >> >> > Today's Topics:
          >> >> >
          >> >> >   1. Re: "bits": Unit of account (Oliver Egginger)
          >> >> >   2. Re: "bits": Unit of account (Christophe Biocca)
          >> >> >   3. Re: "bits": Unit of account (Gmail)
          >> >> >   4. Re: "bits": Unit of account (Mike Caldwell)
          >> >> >   5. Re: "bits": Unit of account (Justin A)
          >> >> >
          >> >> >
          >> >> >
          >> >----------------------------------------------------------------------
          >> >> >
          >> >> > Message: 1
          >> >> > Date: Sun, 20 Apr 2014 20:43:24 +0200
          >> >> > From: Oliver Egginger <bitcoin@olivere•de>
          >> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
          >> >> > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
          >> >> > Message-ID: <5354154C.1080908@olivere•de>
          >> >> > Content-Type: text/plain; charset=ISO-8859-1
          >> >> >
          >> >> > Hello,
          >> >> >
          >> >> > just my two 'cents':
          >> >> >
          >> >> > Terms arises by itself. Just as most people speak of coins when
          >> >they
          >> >> > mean bitcoins. I do not see that bitcoin is currently in common use
          >> >> > except for speculation. Therefore no term for smaller units has
          >> >> > established yet. No problem in my eyes. Time will tell.
          >> >> >
          >> >> > - oliver
          >> >> >
          >> >> >
          >> >> >
          >> >> >
          >> >> > ------------------------------
          >> >> >
          >> >> > Message: 2
          >> >> > Date: Sun, 20 Apr 2014 15:19:38 -0400
          >> >> > From: Christophe Biocca <christophe.biocca@gmail•com>
          >> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
          >> >> > To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
          >> >> > Message-ID:
          >> >> >       <CANOOu=9=
          >> >> TAnaCuyh_P2GqHaguyY39xjhj84HSA_x+6F4MOqM_A@mail•gmail.com>
          >> >> > Content-Type: text/plain; charset=UTF-8
          >> >> >
          >> >> > Culturally neutral? "bit" in French phonetically collides with
          >> >slang
          >> >> > for phallus ("bitte", with a silent "e"). Apparently it means
          >> >"louse"
          >> >> > in Turkish as well.
          >> >> >
          >> >> > Not that this really would be avoidable with any short word (all
          >> >the
          >> >> > short possible words are usually taken), but it's not neutral.
          >> >> >
          >> >> > On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
          >> ><bitcoin@olivere•de>
          >> >> wrote:
          >> >> >> Hello,
          >> >> >>
          >> >> >> just my two 'cents':
          >> >> >>
          >> >> >> Terms arises by itself. Just as most people speak of coins when
          >> >they
          >> >> >> mean bitcoins. I do not see that bitcoin is currently in common
          >> >use
          >> >> >> except for speculation. Therefore no term for smaller units has
          >> >> >> established yet. No problem in my eyes. Time will tell.
          >> >> >>
          >> >> >> - oliver
          >> >> >>
          >> >> >>
          >> >> >>
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> >> Learn Graph Databases - Download FREE O'Reilly Book
          >> >> >> "Graph Databases" is the definitive new guide to graph databases
          >> >and
          >> >> their
          >> >> >> applications. Written by three acclaimed leaders in the field,
          >> >> >> this first edition is now available. Download your free book
          >> >today!
          >> >> >> http://p.sf.net/sfu/NeoTech
          >> >> >> _______________________________________________
          >> >> >> Bitcoin-development mailing list
          >> >> >> Bitcoin-development@lists•sourceforge.net
          >> >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >> >> >
          >> >> >
          >> >> >
          >> >> > ------------------------------
          >> >> >
          >> >> > Message: 3
          >> >> > Date: Sun, 20 Apr 2014 14:32:26 -0500
          >> >> > From: Gmail <will.yager@gmail•com>
          >> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
          >> >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
          >> >> > Message-ID: <B687D4AD-263F-4594-BE7A-FF238B8DF7AF@gmail•com>
          >> >> > Content-Type: text/plain; charset="us-ascii"
          >> >> >
          >> >> > People in the Bitcoin community are sometimes resistant to the idea
          >> >of
          >> >> using the word "credit" as a unit of Bitcoin, because Bitcoin is not
          >> >a
          >> >> credit-based system.
          >> >> >
          >> >> > However, given that the average person has close to no
          >> >understanding of
          >> >> what "credit" means, and probably no concern for the distinction even
          >> >if
          >> >> they do know, it may be wise to use the futuristic and easily
          >> >> understandable "credit" as our human-friendly unit.
          >> >> >
          >> >> > Do others agree that "credits" as a unit of account has a desirable
          >> >> futuristic connotation?
          >> >> >
          >> >> > Will
          >> >> >
          >> >> > -------------- next part --------------
          >> >> > A non-text attachment was scrubbed...
          >> >> > Name: smime.p7s
          >> >> > Type: application/pkcs7-signature
          >> >> > Size: 1593 bytes
          >> >> > Desc: not available
          >> >> >
          >> >> > ------------------------------
          >> >> >
          >> >> > Message: 4
          >> >> > Date: Sun, 20 Apr 2014 16:28:34 -0400
          >> >> > From: Mike Caldwell <mcaldwell@swipeclock•com>
          >> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
          >> >> > To: Christophe Biocca <christophe.biocca@gmail•com>
          >> >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
          >> >> > Message-ID: <4098C706-D67F-474E-9C13-E4C8F56B41ED@swipeclock•com>
          >> >> > Content-Type: text/plain; charset="us-ascii"
          >> >> >
          >> >> > By culturally neutral I mean we avoid deliberately invoking a
          >> >cultural
          >> >> reference in the name.  For example "satoshi" would be a reference to
          >> >> Japanese culture just for being a common Japanese name regardless of
          >> >who
          >> >> Satoshi turns out to be.
          >> >> >
          >> >> > Mike
          >> >> >
          >> >> > Sent from my iPhone
          >> >> >
          >> >> >> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
          >> >> christophe.biocca@gmail•com> wrote:
          >> >> >>
          >> >> >> Culturally neutral? "bit" in French phonetically collides with
          >> >slang
          >> >> >> for phallus ("bitte", with a silent "e"). Apparently it means
          >> >"louse"
          >> >> >> in Turkish as well.
          >> >> >>
          >> >> >> Not that this really would be avoidable with any short word (all
          >> >the
          >> >> >> short possible words are usually taken), but it's not neutral.
          >> >> >>
          >> >> >>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
          >> ><bitcoin@olivere•de>
          >> >> wrote:
          >> >> >>> Hello,
          >> >> >>>
          >> >> >>> just my two 'cents':
          >> >> >>>
          >> >> >>> Terms arises by itself. Just as most people speak of coins when
          >> >they
          >> >> >>> mean bitcoins. I do not see that bitcoin is currently in common
          >> >use
          >> >> >>> except for speculation. Therefore no term for smaller units has
          >> >> >>> established yet. No problem in my eyes. Time will tell.
          >> >> >>>
          >> >> >>> - oliver
          >> >> >>>
          >> >> >>>
          >> >> >>>
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> >>> Learn Graph Databases - Download FREE O'Reilly Book
          >> >> >>> "Graph Databases" is the definitive new guide to graph databases
          >> >and
          >> >> their
          >> >> >>> applications. Written by three acclaimed leaders in the field,
          >> >> >>> this first edition is now available. Download your free book
          >> >today!
          >> >> >>> http://p.sf.net/sfu/NeoTech
          >> >> >>> _______________________________________________
          >> >> >>> Bitcoin-development mailing list
          >> >> >>> Bitcoin-development@lists•sourceforge.net
          >> >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >> >> >>
          >> >> >>
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> >> Learn Graph Databases - Download FREE O'Reilly Book
          >> >> >> "Graph Databases" is the definitive new guide to graph databases
          >> >and
          >> >> their
          >> >> >> applications. Written by three acclaimed leaders in the field,
          >> >> >> this first edition is now available. Download your free book
          >> >today!
          >> >> >> http://p.sf.net/sfu/NeoTech
          >> >> >> _______________________________________________
          >> >> >> Bitcoin-development mailing list
          >> >> >> Bitcoin-development@lists•sourceforge.net
          >> >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >> >> >
          >> >> >
          >> >> >
          >> >> > ------------------------------
          >> >> >
          >> >> > Message: 5
          >> >> > Date: Sun, 20 Apr 2014 20:16:35 -0400
          >> >> > From: Justin A <allport@gmail•com>
          >> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
          >> >> > To: Mike Caldwell <mcaldwell@swipeclock•com>
          >> >> > Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
          >> >> > Message-ID:
          >> >> >       <
          >> >> CAK2MuX3GufxU_AH0Kaw3pUkzgX_agok86ahCh+7r96UkxZwneQ@mail•gmail.com>
          >> >> > Content-Type: text/plain; charset="utf-8"
          >> >> >
          >> >> > <delurk>
          >> >> >
          >> >> > What about "ubit", pronounced "YOU-bit", representing 1e-6 bitcoin?
          >> >Easy
          >> >> to
          >> >> > say, tied in a visual way to the metric micro, leaves the required
          >> >2
          >> >> > decimal places for the marginally numerate.. What more could one
          >> >want?
          >> >> >
          >> >> > </delurk>
          >> >> >
          >> >> > Also, hi. My first post; plan to get involved over the southern
          >> >> hemisphere
          >> >> > winter if I can learn enough.
          >> >> > On Apr 20, 2014 4:32 PM, "Mike Caldwell" <mcaldwell@swipeclock•com>
          >> >> wrote:
          >> >> >
          >> >> >> By culturally neutral I mean we avoid deliberately invoking a
          >> >cultural
          >> >> >> reference in the name.  For example "satoshi" would be a reference
          >> >to
          >> >> >> Japanese culture just for being a common Japanese name regardless
          >> >of who
          >> >> >> Satoshi turns out to be.
          >> >> >>
          >> >> >> Mike
          >> >> >>
          >> >> >> Sent from my iPhone
          >> >> >>
          >> >> >>> On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
          >> >> >> christophe.biocca@gmail•com> wrote:
          >> >> >>>
          >> >> >>> Culturally neutral? "bit" in French phonetically collides with
          >> >slang
          >> >> >>> for phallus ("bitte", with a silent "e"). Apparently it means
          >> >"louse"
          >> >> >>> in Turkish as well.
          >> >> >>>
          >> >> >>> Not that this really would be avoidable with any short word (all
          >> >the
          >> >> >>> short possible words are usually taken), but it's not neutral.
          >> >> >>>
          >> >> >>>> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger
          >> ><bitcoin@olivere•de>
          >> >> >> wrote:
          >> >> >>>> Hello,
          >> >> >>>>
          >> >> >>>> just my two 'cents':
          >> >> >>>>
          >> >> >>>> Terms arises by itself. Just as most people speak of coins when
          >> >they
          >> >> >>>> mean bitcoins. I do not see that bitcoin is currently in common
          >> >use
          >> >> >>>> except for speculation. Therefore no term for smaller units has
          >> >> >>>> established yet. No problem in my eyes. Time will tell.
          >> >> >>>>
          >> >> >>>> - oliver
          >> >> >>>>
          >> >> >>>>
          >> >> >>>>
          >> >> >>
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> >>>> Learn Graph Databases - Download FREE O'Reilly Book
          >> >> >>>> "Graph Databases" is the definitive new guide to graph databases
          >> >and
          >> >> >> their
          >> >> >>>> applications. Written by three acclaimed leaders in the field,
          >> >> >>>> this first edition is now available. Download your free book
          >> >today!
          >> >> >>>> http://p.sf.net/sfu/NeoTech
          >> >> >>>> _______________________________________________
          >> >> >>>> Bitcoin-development mailing list
          >> >> >>>> Bitcoin-development@lists•sourceforge.net
          >> >> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >> >> >>>
          >> >> >>>
          >> >> >>
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> >>> Learn Graph Databases - Download FREE O'Reilly Book
          >> >> >>> "Graph Databases" is the definitive new guide to graph databases
          >> >and
          >> >> >> their
          >> >> >>> applications. Written by three acclaimed leaders in the field,
          >> >> >>> this first edition is now available. Download your free book
          >> >today!
          >> >> >>> http://p.sf.net/sfu/NeoTech
          >> >> >>> _______________________________________________
          >> >> >>> Bitcoin-development mailing list
          >> >> >>> Bitcoin-development@lists•sourceforge.net
          >> >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >> >> >>
          >> >> >>
          >> >> >>
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> >> Learn Graph Databases - Download FREE O'Reilly Book
          >> >> >> "Graph Databases" is the definitive new guide to graph databases
          >> >and
          >> >> their
          >> >> >> applications. Written by three acclaimed leaders in the field,
          >> >> >> this first edition is now available. Download your free book
          >> >today!
          >> >> >> http://p.sf.net/sfu/NeoTech
          >> >> >> _______________________________________________
          >> >> >> Bitcoin-development mailing list
          >> >> >> Bitcoin-development@lists•sourceforge.net
          >> >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >> >> >>
          >> >> > -------------- next part --------------
          >> >> > An HTML attachment was scrubbed...
          >> >> >
          >> >> > ------------------------------
          >> >> >
          >> >> >
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> > 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
          >> >> >
          >> >> >
          >> >> > End of Bitcoin-development Digest, Vol 35, Issue 72
          >> >> > ***************************************************
          >> >>
          >> >>
          >> >>
          >> >>
          >>
          >> >------------------------------------------------------------------------------
          >> >> 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
          >> -----BEGIN PGP SIGNATURE-----
          >> Version: APG v1.1.1
          >>
          >> iQFQBAEBCAA6BQJTVJlDMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
          >> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTbNB/4lHTsUN/iee7H0UyBn
          >> +TDRgf1BSoUx9HP+vtwXzS0JkVQoxoB5x4Pls+ex7qIXGNxdG9EPYi1RqQ5A8RUo
          >> X2ntOL2pj6qTmW4aYxqqyihiQayLs5ixHPmJxqHv343g5ekqsKmBeDuWR4hXjUyZ
          >> 0Pfcp40Xd3eJ38dSbq98letl5eD+ryBPKYtb91Trumqa9S0WB8kw9IqNaXjlpfG1
          >> lYuaVEllpaLpZW+4cx1mlPneS1GmLvloWhXf4Qh4X39VXECAjOAmNKh1atJCyT7H
          >> ugkOcx1F2Rxo5P3jNzBRJKyAD96sbOhKm4sX7rzSjhT3WJgyHtJm3wkeluDCOVbR
          >> QZqK
          >> =R7Tv
          >> -----END PGP SIGNATURE-----
          >>
          >>
          >>
          >> ------------------------------------------------------------------------------
          >> 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
          >>
          >
          >
          
          [-- Attachment #2: Type: text/html, Size: 34366 bytes --]
          
          ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • * Re: [Bitcoin-development] Economics of information propagation
          2014-04-21  4:06     ` Peter Todd
          2014-04-21  4:44       ` Daniel Lidstrom
        @ 2014-04-21 11:34       ` Tier Nolan
          2014-04-21 13:04         ` Jorge Timón
          2014-04-21 15:40       ` Ashley Holman
          2014-04-21 16:00       ` Mark Friedenbach
          3 siblings, 1 reply; 21+ messages in thread
        From: Tier Nolan @ 2014-04-21 11:34 UTC (permalink / raw)
          To: Bitcoin Dev
        
        [-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
        
        On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd <pete@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.
        
        [-- Attachment #2: Type: text/html, Size: 1864 bytes --]
        
        ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • • * Re: [Bitcoin-development] Economics of information propagation
            2014-04-21 11:34       ` Tier Nolan
          @ 2014-04-21 13:04         ` Jorge Timón
            0 siblings, 0 replies; 21+ messages in thread
          From: Jorge Timón @ 2014-04-21 13:04 UTC (permalink / raw)
            To: Tier Nolan; +Cc: Bitcoin Dev
          
          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.nolan@gmail•com> wrote:
          > On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd <pete@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/
          
          
          
          ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • * Re: [Bitcoin-development] Economics of information propagation
          2014-04-21  4:06     ` Peter Todd
          2014-04-21  4:44       ` Daniel Lidstrom
          2014-04-21 11:34       ` Tier Nolan
        @ 2014-04-21 15:40       ` Ashley Holman
          2014-04-21 15:58         ` Alan Reiner
          2014-04-21 16:00       ` Mark Friedenbach
          3 siblings, 1 reply; 21+ messages in thread
        From: Ashley Holman @ 2014-04-21 15:40 UTC (permalink / raw)
          To: Peter Todd; +Cc: bitcoin-development, Jonathan Levin
        
        [-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
        
        On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete@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.
        
        [-- Attachment #2: Type: text/html, Size: 1476 bytes --]
        
        ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • • * Re: [Bitcoin-development] Economics of information propagation
            2014-04-21 15:40       ` Ashley Holman
          @ 2014-04-21 15:58         ` Alan Reiner
            0 siblings, 0 replies; 21+ messages in thread
          From: Alan Reiner @ 2014-04-21 15:58 UTC (permalink / raw)
            To: bitcoin-development
          
          [-- Attachment #1: Type: text/plain, Size: 2279 bytes --]
          
          On 04/21/2014 11:40 AM, Ashley Holman wrote:
          > On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete@petertodd•org
          > <mailto:pete@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. 
          
          
          
          [-- Attachment #2: Type: text/html, Size: 3416 bytes --]
          
          ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • * Re: [Bitcoin-development] Economics of information propagation
          2014-04-21  4:06     ` Peter Todd
                                 ` (2 preceding siblings ...)
          2014-04-21 15:40       ` Ashley Holman
        @ 2014-04-21 16:00       ` Mark Friedenbach
          2014-04-21 16:22         ` Paul Lyon
          2014-04-21 16:45         ` Jonathan Levin
          3 siblings, 2 replies; 21+ messages in thread
        From: Mark Friedenbach @ 2014-04-21 16:00 UTC (permalink / raw)
          To: Peter Todd, Jonathan Levin; +Cc: bitcoin-development
        
        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.
        
        
        
        ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • • * Re: [Bitcoin-development] Economics of information propagation
            2014-04-21 16:00       ` Mark Friedenbach
          @ 2014-04-21 16:22         ` Paul Lyon
            2014-04-21 16:38           ` Mark Friedenbach
            2014-04-21 16:45         ` Jonathan Levin
            1 sibling, 1 reply; 21+ messages in thread
          From: Paul Lyon @ 2014-04-21 16:22 UTC (permalink / raw)
            To: Mark Friedenbach, Peter Todd, Jonathan Levin; +Cc: bitcoin-development
          
          [-- Attachment #1: Type: text/plain, Size: 3808 bytes --]
          
          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: mark@monetize•io
          > To: pete@petertodd•org; jonathan.levin@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
           		 	   		  
          
          [-- Attachment #2: Type: text/html, Size: 4384 bytes --]
          
          ^ permalink raw reply	[flat|nested] 21+ messages in thread

        • • * Re: [Bitcoin-development] Economics of information propagation
              2014-04-21 16:22         ` Paul Lyon
            @ 2014-04-21 16:38           ` Mark Friedenbach
              2014-04-21 16:39             ` Mike Hearn
              0 siblings, 1 reply; 21+ messages in thread
            From: Mark Friedenbach @ 2014-04-21 16:38 UTC (permalink / raw)
              To: Paul Lyon, Peter Todd, Jonathan Levin; +Cc: bitcoin-development
            
            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.
            > 
            
            
            
            ^ permalink raw reply	[flat|nested] 21+ messages in thread

          • • * Re: [Bitcoin-development] Economics of information propagation
                2014-04-21 16:38           ` Mark Friedenbach
              @ 2014-04-21 16:39             ` Mike Hearn
                0 siblings, 0 replies; 21+ messages in thread
              From: Mike Hearn @ 2014-04-21 16:39 UTC (permalink / raw)
                To: Mark Friedenbach; +Cc: bitcoin-development, Jonathan Levin
              
              [-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
              
              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 <mark@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
              >
              
              [-- Attachment #2: Type: text/html, Size: 2614 bytes --]
              
              ^ permalink raw reply	[flat|nested] 21+ messages in thread

        • * Re: [Bitcoin-development] Economics of information propagation
            2014-04-21 16:00       ` Mark Friedenbach
            2014-04-21 16:22         ` Paul Lyon
          @ 2014-04-21 16:45         ` Jonathan Levin
            1 sibling, 0 replies; 21+ messages in thread
          From: Jonathan Levin @ 2014-04-21 16:45 UTC (permalink / raw)
            To: Mark Friedenbach; +Cc: bitcoin-development
          
          [-- Attachment #1: Type: text/plain, Size: 4642 bytes --]
          
          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 <mark@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.
          
          
          [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
          [-- Type: application/pgp-signature, Size: 496 bytes --]
          
          ^ permalink raw reply	[flat|nested] 21+ messages in thread

  • * Re: [Bitcoin-development] Economics of information propagation
      2014-04-21  1:30 ` [Bitcoin-development] Economics of information propagation Jonathan Levin
      2014-04-21  3:58   ` Mark Friedenbach
    @ 2014-04-23  2:54   ` Tom Harding
      2014-04-23 15:05   ` Peter Todd
      2 siblings, 0 replies; 21+ messages in thread
    From: Tom Harding @ 2014-04-23  2:54 UTC (permalink / raw)
      To: bitcoin-development
    
    Jonathan -
    
    These are a few things I've been wishing for recent data on:
    
      - 95th percentile transaction propagation time vs. fees/kb, vs. total fees
      - Count of blocks bypassing well-propagated transactions vs. fees/kb, 
    vs. total fees
      - Signed-double-spend confirmation probability vs. broadcast time 
    offset from first spend
    
    On 4/20/2014 5:30 PM, Jonathan Levin wrote:
    > at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software.
    
    
    
    
    
    ^ permalink raw reply	[flat|nested] 21+ messages in thread

  • * Re: [Bitcoin-development] Economics of information propagation
      2014-04-21  1:30 ` [Bitcoin-development] Economics of information propagation Jonathan Levin
      2014-04-21  3:58   ` Mark Friedenbach
      2014-04-23  2:54   ` Tom Harding
    @ 2014-04-23 15:05   ` Peter Todd
           [not found]     ` <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>
      2 siblings, 1 reply; 21+ messages in thread
    From: Peter Todd @ 2014-04-23 15:05 UTC (permalink / raw)
      To: Jonathan Levin; +Cc: bitcoin-research, bitcoin-development
    
    [-- Attachment #1: Type: text/plain, Size: 8942 bytes --]
    
    On Mon, Apr 21, 2014 at 01:30:28AM +0000, Jonathan Levin wrote:
    
    CC'ing bitcoin-research - may be more appropriate to move the discussion
    there as this discussion is delving into future scenarios.
    
    > Hi all,
    > 
    > I am a post-graduate economist writing a paper on the incentives of mining. Even though this issue has been debated in the forums, I think it is important to get a sense of the magnitude of the incentives at play and determine what implications this has for the transaction fee market.
    > 
    > As it has been pointed out before the marginal cost for miners does not stem from the private cost of the miner validating the signature and including it in the list of transactions in the block but rather the increased probability that the block will be orphaned as a result of slower propagation. Gavin did some back of the envelope worst case calculations but these overstated the effect of propagation delay. The reason being the 80ms additional time to reach 50% of the network is spread throughout the time that it takes to reach 50% of the network. During this time miners are notified about the block and treat it as the longest chain and hence are no longer mining with the aim to produce a competing block. 
    > 
    > I am looking to calculate the change in the curvature of the probability mass function that a block hears about my block in any given second as a function of the block size. Although there is likely to be significant noise here, there seems to be some stable linear relationships with the time that it takes to reach different quartiles. Has anyone done this? I have used some empirical data that I am happy to share but ideally I would like analytical solutions.
    > 
    > Following Peter Todd, I also find the concerning result that propagation delays results in increasing returns to higher shares of the hashing power. Indeed it may well be in the interest of large pools to publish large blocks to increase propagation delays on the network which would increase orphan rates particularly for small miners and miners that have not invested in sufficient bandwidth / connectivity. If a small miner hears about a block after 4.5 seconds on average there is a 0.7% chance that there is already a block in circulation.  Large miners can increase the time that it takes for small miners to hear about blocks by increasing the size of their blocks. For example if the time that it takes for a small miner to hear about the block goes to 12 seconds there is a 2 percent chance there is already a block in circulation for the small miner. There is also a 1.2% chance that there will be a competing block published after a small miner propagates in the time that it gets to full propagation. Am I getting this right that the probability of a miner’s block being orphaned is comprised of the probability that the miner was not the first to find a valid block and the probability that given they are first, someone else in the absence of hearing about it finds a competing valid block. 
    > 
    > One question is: Are orphans probabilistic and only resolved after hearing about a new block that lengthens the chain or is there a way to know in advance?
    
    They're probabilistic; mining is progress free so per unit hashing power
    every miner has an equal chance of finding a block. As for resolution,
    well, currently nodes (and miners) mine on the block they saw first; if
    they learn about another block at the same height they stick to the
    block they are already mining on. First seen at same height is probably
    generally economically rational as the first block you see probably
    propagated to the most nodes, although tweaks to that are probably
    possible.
    
    > Is it frowned upon to mine on top of a block that you have just found even though it is very likely going to end up an orphan?
    
    Not at all, in fact mining on top of the block is the best thing to do
    because it *prevents* your block from ending up as an orphan. Basically
    imagine I find block b1a, and you find conflicting block b1b. What I
    need to do is find block b2a, which is on top of b1a, before you find
    block b1b to avoid my block being orphaned. The best way to do that is
    mining on top of my block - that's what's most rational for me.
    
    > Would be happy to share the draft form of the paper and receive any feedback.
    
    Sure thing.
    
    > Finally, at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software. 
    
    
    So looking at the replies your post got in the past few days it looks
    like there's some misinformation going around. First of all is the
    question of how harmful it is if miners mine on top of blocks that they
    haven't actually validated, and yes, that's extremely harmful. For
    instance if I were an attacker I could mine an invalid block that makes
    coins out of thin air and use it to defraud SPV-wallet-using clients;
    everyone who is mining without validating is helping me succesfully pull
    off that attack by increasing the chance I'll get enough confirms to
    trick my target into thinking the coins are real. (remember I could have
    stolen the hashing power by hacking into a pool)
    
    Mark Friedenbach suggested headers first where the block header and
    block contents are propagated around the network separately. What that
    results in has a few different scenarios:
    
    1) Fee's don't matter and miners aren't forced to validate
    
    This is the scenario we're in right now. The block reward comprises the
    supermajority of mining income, and it is possible to mine a block
    without first validating the contents of the previous block. When a
    miner receives a block header that extends the longest known blockchain
    they can immediately switch to it and start mining.
    
    Whether or not doing so is rational is just a matter of what's the
    probability that the previous block was invalid? If it was, the miner
    mining it just wasted 25BTC, $12.5k, so you can be almost sure it is
    valid and you don't need to wait. Of course, if you then find a block,
    you can pull the same trick all over again and the next guy might be
    mining on top of two blocks they haven't validated, and so on.
    
    Obviously this presents a very nasty failure mode if the majority of
    miners follow this behavior and a block is invalid, or even just gets
    lost. Similarly in the majority scenario there's no direct incentive to
    actually propagate your blocks - they'll still get accepted to the main
    chain anyway.
    
    That said, small and large miners make roughly the same amount as the
    block reward dominates and blocks of any size will get confirmations
    fairly quickly.
    
    
    2) Fee's do matter and miners aren't forced to validate
    
    Now transaction fees represent a non-trivial portion of a miner's
    income. Centralization incentives would depend on to what extent fees do
    matter. Again, there's some nasty failure modes possible. That large,
    slow-to-propagate blocks still get confirmed, yet small miners can't
    mine transaction fees is likely a major centralization incentive.
    
    3) Miners are forced to validate
    
    Or at least, we can force miners to actually have the previous block.
    Andrew Miller's Permacoin is one approach; some varients of UTXO
    commitments have this as a side-effect too. On the one hand this solves
    the really nasty failure modes that headers-first has; on the other hand
    you're back to the centralization incentives we have right now.
    
    
    What's important however to remember is that any attempt at saying
    things like "[A]s soon as [Miners] receive and process the contents of
    block A, they switch to that." - as Mark suggested(2) - doesn't belong
    in an economic analysis as such rules are unenforcable. For instance
    that'd suggest that in the forced-validation headers-first scenario a
    large miner who received a block header, then found block themselves,
    would switch to mining the block they *didn't* find simply because they
    "got the header first". Obviously this is not economically rational for
    them to do so they won't, leading to the same centralization incentives
    as always.
    
    As for why that's economically irrational: so the large miner finds that
    second block and broadcasts it around the network. Do you the small
    miner keep mining on the shorter chain just because the large miner
    broke the gentlemans agreement to respect header times? Of course not,
    time is relative and you have no idea whether or not anyone else is
    doing so. If you mine on the shorter chain you're side is going to need
    to find two blocks to catch up - not likely. Secondly you risk forking
    the network due to a consensus failure, say by a divergent times the
    headers were received.
    
    1) http://cs.umd.edu/%7Eamiller/permacoin.pdf
    
    -- 
    'peter'[:-1]@petertodd.org
    0000000000000000278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7
    
    [-- Attachment #2: Digital signature --]
    [-- Type: application/pgp-signature, Size: 685 bytes --]
    
    ^ permalink raw reply	[flat|nested] 21+ messages in thread

  • • [parent not found: <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>]

    • • * [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem
               [not found]     ` <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>
        @ 2014-05-02 11:48       ` Sergio Lerner
          2014-05-02 12:00         ` Sergio Lerner
          0 siblings, 1 reply; 21+ messages in thread
        From: Sergio Lerner @ 2014-05-02 11:48 UTC (permalink / raw)
          To: Joseph Bonneau; +Cc: bitcoin-research, bitcoin-development, Jonathan Levin
        
        The Bonneau's Kickbacks problem is interesting because it is a
        destabilizing incentive.
        Just by luck yesterday I was working on the same problem. I found a way
        to prevent Kickbacks and provide a conflict resolution strategy that
        benefits all member of the network.
        I will repost my blog post here, but the original has very nice diagrams
        and is full of hyperlinnk, so I recommend you see the original post...
        
        Even faster block-chains with DECOR protocol
        
        One of the most interesting papers ever written about the Bitcoin
        block-chain design is “Accelerating Bitcoin’s Transaction Processing” by
        Sompolinsky and Zohar. The paper presents the GHOST protocol which aims
        to achieve higher TPS securely by changing the way nodes decide which is
        the best chain fork. One of the issues that is not considered by the
        paper is the existence of a selfish bias independent of the miner’s
        hashing power. When a miner solves a block, and a competing block is
        also received, the miner will mine on top of his own solved block. This
        is not only a consequence of the best-chain selection policy, there is a
        strong incentive to do so. By mining on top of your own solved block,
        you double the expected reward while keeping the same winning
        probabilities. As a informal comparison, in Satoshi’s security model,
        the rogue miner is irrational and malicious. For example, the
        confirmation interval computations assume a rogue miner having 10% of
        the network hashing power will try to mine a selfish chain in order to
        try to outperform the global best-chain even if the odds are against
        him. In Sopolinky/Zohar security model, the miners are rational, but use
        a sub-optimal strategy. For example when two blocks compete, all miners
        will chose one of them arbitrarily (all choose the same block). Although
        this may be optimal for a fully cooperative network it’s not what miners
        will optimally choose for themselves. In Eyal/Sirer security model, the
        rogue miner is rational and uses an strategy believed by the authors to
        be optimal.
        In this post we improve Sopolinky/Zohar model assuming the attacker uses
        Eyal/Sirer selfish strategy and the standard double-betting strategy.
        
        Double-betting Strategy by Default
        
        The double-betting is a mining strategy pre-programmed in the in Satoshi
        reference miner. When a miner mines a block and a competing block is
        also detected, the miner won’t switch to the other chain because is has
        the same length, so mining will continue on the “selfish” fork. Of
        course there is nothing inherently selfish with this strategy since the
        miner has not enough information about which of the two forks is the one
        which the majority of the miners are mining on top of. Nevertheless the
        division of hashing power in forks is against the common good and
        reduces both the network TPS and the network confirmation time.
        
        Tit for Tat and identities
        
        If the two competing miners could detect the other miners identity in
        blocks, they could apply a cooperative strategy like Tit for Tat.
        Whenever two competing blocks are found by two miners without having any
        previous interaction, the conflict is resolved by both miners mining on
        top of the block with lower hash digest. If the two miners have
        interacted before, the conflict is resolved by both miners mining in the
        block that was solved by the opposite miner chosen in the previous
        interaction. If a miner acts selfishness and breaks the ties, then the
        other miner opts to apply an equivalent retaliation in the next block
        conflict. The retaliation is only considered successful if the miner who
        retaliates wins the ties. This strategy may in practice for at least
        four reasons:
        
        Sometimes a miner may solve two blocks in a row without noticing that
        the first one had a conflicting sibling. Then the competing miner would
        retaliate.
        If more than two miners are competing, it’s more complex to decide which
        block should be chosen as parent.
        All miners must dynamically maintain information of all previous
        interactions between all other miners.
        Some miners want to preserve anonymity and won’t publish identifying
        information.
        
        The first two reasons can be disregarded since the conflicting events
        may have a very low probability. The third is only a minor technical
        difficulty. But the last reason may be very strong.
        
        DECOR (DEterministic COnflict Resolution)
        
        I present here a reward strategy I called DECOR that incentives
        resolving conflicts in a deterministic way that benefits all conflicting
        miners at the same time. This strategy practically eliminates any
        possibly block-chain reversal when miners are rational. To make this
        explanation clearer we’ll assume that all block rewards and fees are
        equal so each miner receives exactly the same net payment for a block.
        Also the reward percentages proposed can be varied as long as some
        relations between are maintained. The idea is that whenever two miners
        Alice and Bob mine two competing blocks (a block conflict) both decide
        to mine on top of the block with the lower hash. First, all conflicting
        blocks headers that are not very old are forwarded to allow all peers to
        compare block hashes. If a miner Carol (or Alice or Bob) solves a
        following block, she includes in his block a reference to the uncle
        block header that was left out of the main chain. This reference is
        stored either in the block header, the coinbase field or in a special
        transaction. The uncle block owner will get automatically 50% of the
        reward of his main-chain sibling if uncle hash is higher than sibling
        hash or 35% if not. The sibling also pays a 10% to Carol. Also the
        sibling burns 10% if the uncle hash is higher than the sibling hash or
        35% if not. This strategy sets incentives for conflicting miners to
        choose always the parent with the lowest hash and to always reference a
        lost uncle in the following blocks.
        
        Mining strategy:
        
        If there is no block Y having a sibling X in the main chain whose reward
        has not matured then mine in the standard way and exit this procedure
        Add a reference to Y in the new block that is being prepared.
        Let x := BlockRewardPlusFees(X)
        Let q := x*0.5
        Let z :=x*0.1
        If Hash(X)>Hash(Y) then q :=q-(x*0.2) and z :=z+(x*0.2)
        Add a transaction that has as input the coinbase output of X and has
        four outputs: the first output pays q coins to the address specified in
        the coinbase output of block Y, the second output pays (x*0.1) coins to
        an owned address, the third output burns z coins, and the forth output
        pays the remaining coins to the same address as the input address. All
        users accept this transaction as valid even if it’s unsigned if a
        correct uncle is referenced.
        
        The following diagrams show an example of how two miners Alice and Bob
        will prefer mining on top of the same parent (A1) after a block A1
        (created by Alice) is in conflict with a block B1 created by Bob. Carol
        is a third miner that is not in conflict with neither Alice nor Bob. In
        the diagrams the first letter indicates who created the block and the
        number following indicates the block height. The arrows point to each
        block parent.Bob-op
        
        
        Although I’m giving no formal proof, It’s evident that the best strategy
        for Alice and Bob is to choose the same parent for the following block.
        
        GHOST+DECOR
        
        The DECOR strategy can be implemented along with the GHOST protocol. In
        fact both protocols have things in common, such as the need to forward
        block headers that are siblings of blocks in the best chain. Using both
        protocols together, along with route optimizations proposed here, maybe
        2000 TPS can be achieved today.
        
        
        
        Best regards,
        Sergio.
        
        
        
        ^ permalink raw reply	[flat|nested] 21+ messages in thread

      • • * Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem
            2014-05-02 11:48       ` [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem Sergio Lerner
          @ 2014-05-02 12:00         ` Sergio Lerner
                 [not found]           ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
            0 siblings, 1 reply; 21+ messages in thread
          From: Sergio Lerner @ 2014-05-02 12:00 UTC (permalink / raw)
            To: Joseph Bonneau; +Cc: bitcoin-research, bitcoin-development, Jonathan Levin
          
          The original post is here: http://bitslog.wordpress.com/2014/05/02/decor/
          
          
          
          ^ permalink raw reply	[flat|nested] 21+ messages in thread

        • • [parent not found: <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>]

          • • * Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem
                     [not found]           ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
              @ 2014-05-05 19:45             ` Sergio Lerner
                2014-05-05 20:27               ` Ittay
                2014-05-07  4:31             ` [Bitcoin-development] DECOR+ Better block selection rule Sergio Lerner
                1 sibling, 1 reply; 21+ messages in thread
              From: Sergio Lerner @ 2014-05-05 19:45 UTC (permalink / raw)
                To: Joseph Bonneau
                Cc: bitcoin-research, bitcoin-development, Emin Gün Sirer, Ittay Eyal
              
              
              On 02/05/2014 10:56 a.m., Joseph Bonneau wrote:
              > This is an interesting idea Sergio. I have two concerns:
              >
              > You mention "50% of the block reward" going to the uncle block. Does
              > this mean the parent gets 1, and the uncle 0.5, or both get 0.5? In
              > the first interpretation (which I assumed was the design), mining is
              > no longer a zero-sum game and this could have lots of unforeseen
              > implications. For example, selfish mining might be more profitable,
              > since you're less disincentivized to avoid conflicts.
              The second interpretation is the correct one.
              > In the second interpretation, there's pressure to have the next miner
              > ignore the uncle to not share the reward. This would encourage
              > kickback-style attacks and advantage large mining pools because they
              > can mine on their own blocks and ignore colliding uncles.
              Including an uncle can be done at any time before a coinbase matures
              (100 blocks) (of course the term "uncle" is misleading in those cases) .
              So, for example, the uncle can be included 50 blocks afterward. So it's
              very difficult that a miner prevents other miners from including the
              uncle and taking the reward given by uncle inclusion.
              
              Same ineffective attack:
              A big miner could try to bribe all other miners not to include the
              uncle, but this would be terribly costly. Suppose that I mine a block
              ignoring an uncle Z and then I publish this message: "Every miner from
              block number X to block number Y that does not include this uncle Z will
              be given Q Bitcoins". How much would Q be? Since by including the uncle
              the miner gets 5 BTC of reward (in the example case where block reward
              is 50 BTC), then each bribery payment would have to be higher than 5
              BTC, totaling 500 BTC ! much more than the 25 BTC the miner will loose
              by including the uncle.
              
              Just by sending a transaction with a lot of fees that depends on my
              block does not prevent subsequent miners from including the supposedly
              banned uncle.
              
              Then, I think there are no kickback-style attacks.
              
              >
              > Also, I think this came up in the Princeton meet-up, but it's not
              > ideal to just hash the blocks to decide the "winner" because this lets
              > you know in advance your block's likelihood of winning a collision by
              > looking at how high or low its hash is, in which case you can publish
              > a weak block right away or withhold a strong one and do selfish
              > mining. A better approach to break ties between blocks A and B is to
              > see if H(A||B) < H(B||A). That way neither block holder can find out
              > in advance if their block is likely to win a collision.
              >
              In the DECOR protocol, I think selfish miners cannot get any advantage,
              because the blocks that loose the latency race will come back as uncles
              and get their reward share anyway. Maybe Ittay Eyal and Emin Gun Sirer
              can say more about this...
              
              Best regards, Sergio.
              
              
              
              ^ permalink raw reply	[flat|nested] 21+ messages in thread

            • • * Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem
                  2014-05-05 19:45             ` Sergio Lerner
                @ 2014-05-05 20:27               ` Ittay
                  0 siblings, 0 replies; 21+ messages in thread
                From: Ittay @ 2014-05-05 20:27 UTC (permalink / raw)
                  To: Sergio Lerner
                  Cc: bitcoin-research, bitcoin-development, Joseph Bonneau,
                	Emin Gün Sirer, Ittay Eyal
                
                [-- Attachment #1: Type: text/plain, Size: 3640 bytes --]
                
                As far as I understand, the incentives Sergio suggests would work. So
                we can assume that the pruned uncle blocks would still win their creators
                at least partial revenue.
                
                As for selfish mining - I'm not sure how GHOST affects it. I don't think it
                does. The selfish miners just care about heaviest subtree rather than
                longest chain. DECOR changes revenue collection significantly, so it
                certainly affects selfish mining. I believe it changes the threshold at
                which
                selfish mining is profitable, but doesn't deter selfish mining completely:
                Selfish miners can still cause others to reduce their revenue by having
                them work on older blocks.
                
                Ittay
                
                
                
                On Mon, May 5, 2014 at 3:45 PM, Sergio Lerner <sergiolerner@certimix•com>wrote:
                
                >
                > On 02/05/2014 10:56 a.m., Joseph Bonneau wrote:
                > > This is an interesting idea Sergio. I have two concerns:
                > >
                > > You mention "50% of the block reward" going to the uncle block. Does
                > > this mean the parent gets 1, and the uncle 0.5, or both get 0.5? In
                > > the first interpretation (which I assumed was the design), mining is
                > > no longer a zero-sum game and this could have lots of unforeseen
                > > implications. For example, selfish mining might be more profitable,
                > > since you're less disincentivized to avoid conflicts.
                > The second interpretation is the correct one.
                > > In the second interpretation, there's pressure to have the next miner
                > > ignore the uncle to not share the reward. This would encourage
                > > kickback-style attacks and advantage large mining pools because they
                > > can mine on their own blocks and ignore colliding uncles.
                > Including an uncle can be done at any time before a coinbase matures
                > (100 blocks) (of course the term "uncle" is misleading in those cases) .
                > So, for example, the uncle can be included 50 blocks afterward. So it's
                > very difficult that a miner prevents other miners from including the
                > uncle and taking the reward given by uncle inclusion.
                >
                > Same ineffective attack:
                > A big miner could try to bribe all other miners not to include the
                > uncle, but this would be terribly costly. Suppose that I mine a block
                > ignoring an uncle Z and then I publish this message: "Every miner from
                > block number X to block number Y that does not include this uncle Z will
                > be given Q Bitcoins". How much would Q be? Since by including the uncle
                > the miner gets 5 BTC of reward (in the example case where block reward
                > is 50 BTC), then each bribery payment would have to be higher than 5
                > BTC, totaling 500 BTC ! much more than the 25 BTC the miner will loose
                > by including the uncle.
                >
                > Just by sending a transaction with a lot of fees that depends on my
                > block does not prevent subsequent miners from including the supposedly
                > banned uncle.
                >
                > Then, I think there are no kickback-style attacks.
                >
                > >
                > > Also, I think this came up in the Princeton meet-up, but it's not
                > > ideal to just hash the blocks to decide the "winner" because this lets
                > > you know in advance your block's likelihood of winning a collision by
                > > looking at how high or low its hash is, in which case you can publish
                > > a weak block right away or withhold a strong one and do selfish
                > > mining. A better approach to break ties between blocks A and B is to
                > > see if H(A||B) < H(B||A). That way neither block holder can find out
                > > in advance if their block is likely to win a collision.
                > >
                > In the DECOR protocol, I think selfish miners cannot get any advantage,
                > because the blocks that loose the latency race will come back as uncles
                > and get their reward share anyway. Maybe Ittay Eyal and Emin Gun Sirer
                > can say more about this...
                >
                > Best regards, Sergio.
                >
                
                [-- Attachment #2: Type: text/html, Size: 4491 bytes --]
                
                ^ permalink raw reply	[flat|nested] 21+ messages in thread

            • * [Bitcoin-development] DECOR+ Better block selection rule
                     [not found]           ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
                2014-05-05 19:45             ` Sergio Lerner
              @ 2014-05-07  4:31             ` Sergio Lerner
                1 sibling, 0 replies; 21+ messages in thread
              From: Sergio Lerner @ 2014-05-07  4:31 UTC (permalink / raw)
                To: Joseph Bonneau; +Cc: bitcoin-research, bitcoin-development
              
              [-- Attachment #1: Type: text/plain, Size: 3216 bytes --]
              
              This e-mail is an extract of my post:
              http://bitslog.wordpress.com/2014/05/07/decor-2/
              
              Some posts ago I presented the DECOR protocol. One of the assumptions I
              did was that the amount of coins each miner earned in competing blocks
              was approximately the same. This could be true for cryptocurrencies with
              never ending block subsidies (inflationary designs) because the block
              subsidy may be an order of magnitude higher than the fees collected in
              the block. In Bitcoin we don’t really know what will happen with fees
              when the reward is halved. Less we know if in that case the number of
              transactions per block (and fees collected) will be fairly constant or
              there will be high variability. If Alice and Bob compete for a certain
              block height with blocks A and B respectively, and Alice’s block reward
              (subsidy+fees) is half of Bob’s reward, then even if Hash(A) < Hash(B)
              (and the DECOR incentives are set to prefer A) it may be the case that
              both Alice and Bob would prefer to mine on top of B since they both earn
              much more even paying the higher penalty d of burnt coins. In limit
              cases, Alice’s optimal choice may not be the same as Bob’s optimal
              choice. I propose a slight modification of the protocol such that even
              with different block rewards the optimal choice of parent is always the
              same for all miners. Instead of choosing the block with less hash
              digest, miners will choose the block with higher reward (subsidy+fees).
              Splitting the higher reward block would always be more profitable than
              splitting lowest reward block. In the rare case both blocks have exactly
              the same reward, then the block with lowest hash is chosen. Even if
              rewards are approximately equal, the change adds a new monetary
              incentive to cooperate. Compared with the DECOR protocol, the only
              modification is in step 6.
              
              *DECOR+ Mining strategy*
              
               1. If there is no block Y having a sibling X in the main chain whose
                  reward has not matured then mine in the standard way and exit this
                  procedure
               2. Add a reference to Y in the new block that is being prepared.
               3. Let x  := BlockReward(X)
               4. Let q := x*a
               5. Let z :=x*b
               6. If (BlockReward(X)<BlockReward(Y)) OR
                  (BlockReward(X)=BlockReward(Y)) AND (Hash(X)>Hash(Y)) then
                  q :=q-(x*c)
                  z :=z+(x*d)
               7. Let w :=x*e
               8. Add a transaction that has as input the coinbase output of X and has
                  four outputs:
                        o pay q coins to the address specified in the coinbase output
                          of block Y
                        o pay w coins to an owned address
                        o burns z coins
                        o pay the remaining coins to the same address as the input
                          address.
              
               
              
              BlockReward() returns the block subsidy plus the transaction fees in the
              block.
              
              *Conditions on constants*
              
              If you want to choose different values of a,b,c,d,e that still force
              miners selections converge into a single parent then these conditions
              must be satisfied:
              
                * e > 0
                * 1-a-e-b > a-c
                * 1+e-a-e-b > a-c
                * a > 1-a-c-e-b-d
                * a+e > 1-a-c-e-b-d
              
              And all constants are between 0 and 1.
              
              It's interesting that now it's much easier to prove that for two
              competing miners the DECOR+ protocol cannot be abused, since there is no
              dependence on the block content.
              
              Best regards,
               Sergio.
              
              [-- Attachment #2: Type: text/html, Size: 4296 bytes --]
              
              ^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2014-05-07  4:30 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
2014-04-21  1:30 ` [Bitcoin-development] Economics of information propagation Jonathan Levin
2014-04-21  3:58   ` Mark Friedenbach
2014-04-21  4:06     ` Peter Todd
2014-04-21  4:44       ` Daniel Lidstrom
2014-04-21  5:46         ` Daniel Lidstrom
2014-04-21 11:34       ` Tier Nolan
2014-04-21 13:04         ` Jorge Timón
2014-04-21 15:40       ` Ashley Holman
2014-04-21 15:58         ` Alan Reiner
2014-04-21 16:00       ` Mark Friedenbach
2014-04-21 16:22         ` Paul Lyon
2014-04-21 16:38           ` Mark Friedenbach
2014-04-21 16:39             ` Mike Hearn
2014-04-21 16:45         ` Jonathan Levin
2014-04-23  2:54   ` Tom Harding
2014-04-23 15:05   ` Peter Todd
     [not found]     ` <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>
2014-05-02 11:48       ` [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem Sergio Lerner
2014-05-02 12:00         ` Sergio Lerner
     [not found]           ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
2014-05-05 19:45             ` Sergio Lerner
2014-05-05 20:27               ` Ittay
2014-05-07  4:31             ` [Bitcoin-development] DECOR+ Better block selection rule Sergio Lerner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox