[Bitcoin-development] Economics of information propagation

[Bitcoin-development] Economics of information propagation

[Jonathan Levin]

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

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

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

Re: [Bitcoin-development] Economics of information propagation

[Peter Todd]

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

Re: [Bitcoin-development] Economics of information propagation

[Daniel Lidstrom]

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

Re: [Bitcoin-development] Economics of information propagation

[Daniel Lidstrom]

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

Re: [Bitcoin-development] Economics of information propagation

[Tier Nolan]

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

Re: [Bitcoin-development] Economics of information propagation

[Jorge Timón]

I'm not convinced that headers first will result in miners hashing on
top of the block with more work without knowing if it's valid yet
instead of just keep hashing on top of the longest known-to-be-valid
chain.
Both options are risky for the miner in some way, and I guess the
probability of someone hashing an invalid block above difficulty is
too low to be the main concern, but there's intermediate solutions,
like say, waiting to validate at least 5% of the block.

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

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

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

On 4/21/14, Tier Nolan <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/

Re: [Bitcoin-development] Economics of information propagation

[Ashley Holman]

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

Re: [Bitcoin-development] Economics of information propagation

[Alan Reiner]

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

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

That wasn't what I was saying. Right now the primacy of a block is
determined by the time at which the `block` message is received, which
is delays due to both the time it takes to transmit the block data and
the time it takes to validate. Headers-first, on the other hand, has the
option of basing primacy on the time the block header is received, which
is O(1) time to transmit and to SPV-validate. Mining on that block
doesn't actually commence until the full block is received and validated.

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

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

The earlier, larger block A will only become stale if *two* blocks are
found in the extra time it takes for block A to propagate the network.
That is a substantially different risk, and probably a negligible
concern to most miners.

On 04/20/2014 09:06 PM, Peter Todd wrote:
> That is mistaken: you can't mine on top of just a block header,
> leaving small miners disadvantaged as they are earning no profit
> while they wait for the information to validate the block and update
> their UTXO sets. This results in the same problem as before, as the
> large pools who mine most blocks can validate either instantly - the
> self-mine case - or more quickly than the smaller miners.
> 
> Of course, in reality smaller miners can just mine on top of block
> headers and include no transactions and do no validation, but that is
> extremely harmful to the security of Bitcoin.

Re: [Bitcoin-development] Economics of information propagation

[Paul Lyon]

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

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

Yes, it certainly can be improved in this way. You can even extend the
idea to distribute partial proofs of work (block headers + Merkle lists
which represent significant but not sufficient work), and 'prime' your
memory pools with the transactions contained within.

This is, btw, basically what p2pool does, which is why last time I
calculated you get roughly 1% better return from p2pool than a zero-fee
mining pool would get you, specifically because of the lower stale rate.

On 04/21/2014 09:22 AM, Paul Lyon wrote:
> I haven't done the math on this, so it may be a terrible idea. :)
> 
> I've been wondering if block propagation times could also be improved by
> allowing peers to request the list of transaction hashes that make up a
> block, and then making a follow-up request to only download any
> transactions not currently known. I'm not sure what percentage of
> transactions a node will usually already have when it receives a new
> block, but if it's high I figure this could be beneficial.
> 

Re: [Bitcoin-development] Economics of information propagation

[Mike Hearn]

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

Re: [Bitcoin-development] Economics of information propagation

[Jonathan Levin]

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

Re: [Bitcoin-development] Economics of information propagation

[Tom Harding]

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.

Re: [Bitcoin-development] Economics of information propagation

[Peter Todd]

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

[Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem

[Sergio Lerner]

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.

Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem

[Sergio Lerner]

The original post is here: http://bitslog.wordpress.com/2014/05/02/decor/

Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem

[Sergio Lerner]

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.

Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem

[Ittay]

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

[Bitcoin-development] DECOR+ Better block selection rule

[Sergio Lerner]

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