Daniel Lidstrom [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-06-25 to 2014-04-21
💬 Posted a total of 10 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:19:10

- reply

📅 Original date posted:2014-04-21
📝 Original message: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 at 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 at 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 at 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 at 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 at lists.sourceforge.net> <
>> >> bitcoin-development-request at lists.sourceforge.net> wrote:
>> >>
>> >> > Send Bitcoin-development mailing list submissions to
>> >> > bitcoin-development at 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 at lists.sourceforge.net
>> >> >
>> >> > You can reach the person managing the list at
>> >> > bitcoin-development-owner at 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 at olivere.de>
>> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
>> >> > To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
>> >> > Message-ID: <5354154C.1080908 at 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 at gmail.com>
>> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
>> >> > To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
>> >> > Message-ID:
>> >> > <CANOOu=9=
>> >> TAnaCuyh_P2GqHaguyY39xjhj84HSA_x+6F4MOqM_A at 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 at 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 at 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 at gmail.com>
>> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
>> >> > Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
>> >> > Message-ID: <B687D4AD-263F-4594-BE7A-FF238B8DF7AF at 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 at swipeclock.com>
>> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
>> >> > To: Christophe Biocca <christophe.biocca at gmail.com>
>> >> > Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
>> >> > Message-ID: <4098C706-D67F-474E-9C13-E4C8F56B41ED at 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 at 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 at 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 at 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 at 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 at gmail.com>
>> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
>> >> > To: Mike Caldwell <mcaldwell at swipeclock.com>
>> >> > Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
>> >> > Message-ID:
>> >> > <
>> >> CAK2MuX3GufxU_AH0Kaw3pUkzgX_agok86ahCh+7r96UkxZwneQ at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/731cb618/attachment.html>

2023-06-07 15:19:09

- reply

📅 Original date posted:2014-04-21
📝 Original message:> 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 at 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 at 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 at 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 at lists.sourceforge.net> <
> >> bitcoin-development-request at lists.sourceforge.net> wrote:
> >>
> >> > Send Bitcoin-development mailing list submissions to
> >> > bitcoin-development at 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 at lists.sourceforge.net
> >> >
> >> > You can reach the person managing the list at
> >> > bitcoin-development-owner at 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 at olivere.de>
> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
> >> > To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
> >> > Message-ID: <5354154C.1080908 at 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 at gmail.com>
> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
> >> > To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
> >> > Message-ID:
> >> > <CANOOu=9=
> >> TAnaCuyh_P2GqHaguyY39xjhj84HSA_x+6F4MOqM_A at 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 at 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 at 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 at gmail.com>
> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
> >> > Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
> >> > Message-ID: <B687D4AD-263F-4594-BE7A-FF238B8DF7AF at 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 at swipeclock.com>
> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
> >> > To: Christophe Biocca <christophe.biocca at gmail.com>
> >> > Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
> >> > Message-ID: <4098C706-D67F-474E-9C13-E4C8F56B41ED at 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 at 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 at 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 at 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 at 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 at gmail.com>
> >> > Subject: Re: [Bitcoin-development] "bits": Unit of account
> >> > To: Mike Caldwell <mcaldwell at swipeclock.com>
> >> > Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
> >> > Message-ID:
> >> > <
> >> CAK2MuX3GufxU_AH0Kaw3pUkzgX_agok86ahCh+7r96UkxZwneQ at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/3e2600cd/attachment.html>

2023-06-07 15:09:05

- reply

📅 Original date posted:2013-11-07
📝 Original message:Hey Peter, something seems wrong with your above analysis: I think a miner
would withhold his block not because it leads to a greater probability of
winning the next one, but because it increases his expected revenue.
Suppose a cabal with fraction q of the total hashing power is n blocks
ahead on a secret branch of that has mined r_tot coins, and let r_next be
its next block's reward. If the cabal chooses not to broadcast its secret
chain until at least the next block, its expected revenue after the next
block is found is
(1 - (1-q)^(n+1))*(r_tot + r_next)
If it does broadcast, its expected revenue after the next block is found is
r_tot + q * r_next
If the cabal seeks only to maximize immediate revenue, then after a bit of
algebra we find that it will withhold its chain if
q > 1 - ( 1 + r_tot / r_next )^(-1/n)
So if the cabal has just mined his first block off of the public chain,
i.e. n = 1, and if the block reward is relatively stable, i.e. r_next =
r_tot, then it needs q > 50% to profitably withhold, not the 29.2% you
calculated.
>From this formula we can also see that if the miner wins the race and
withholds again, then he must grow q to compensate for the increase in
r_tot, and any decrease in n. So generally publication becomes
increasingly in the cabal's interest, and secret chains will tend not to
grow too large (intuition tells me that simulations using the above formula
should bear this out).
This seem correct to you?
On Thu, Nov 7, 2013 at 9:14 AM, Mike Hearn <mike at plan99.net> wrote:
> Once the ASIC race calms down because everyone has one, has more or less
> optimal power supplies, process improvements aren't easily reachable
> anymore etc then I'd expect people to dissipate from the large pools
> because eliminating their fees will become the next lowest hanging fruit to
> squeeze out extra profit. There's no particular reason we need only a
> handful of pools that control a major fraction of the hashpower.
>
> If we end up with a few hundred pools or lots of miners on p2pool, then a
> lot of these theoretical attacks become not very relevant (I don't think ID
> sacrifices will be so common or large as to justify a pile of custom mining
> code+strategies at any point ...)
>
>
> On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote:
>> > > P.S: If any large pools want to try this stuff out, give me a shout.
>> You
>> > > have my PGP key - confidentiality assured.
>> > >
>> >
>> > If I find out one of the large pools decides to run this 'experiment' on
>> > the main network, I will make it my mission to tell people to switch to
>> a
>> > more responsible pool.
>>
>> I hope they listen.
>>
>> A few months ago ASICMiner could have made use of that attack if my
>> memories of their peak hashing power were correct. They certainely could
>> have used the selfish miner version, (we need better name for that)
>> although development costs would eat into profits.
>>
>> GHash.IO, 22%, says they're a "private Bitfury ASIC mining pool" - dunno
>> what they mean by that, but they're involved with CEX.IO who has
>> physical control of a bunch of hashing power so I guess that means their
>> model is like ASICMiners. They're a bit short of 30%, but maybe some
>> behind-the-scenes deals would fix that, and/or lowering the barrier with
>> reactive block publishing. (a better name)
>>
>> > And if you think you can get away with driving up EVERYBODY's orphan
>> rate
>> > without anybody noticing, you should think again.
>>
>> ...and remember, if you only do the attack a little bit, you still can
>> earn more profit, and only drive up the orphan rate a little bit. So who
>> knows, maybe the orphans are real, or maybe they're an attack? ASICMiner
>> was involved with a bunch of orphans a while back...
>>
>> You know what this calls for? A witchhunt!
>>
>> BURN THE LARGE POOLS!
>>
>> > > P.P.S: If you're mining on a pool with more than, like, 1% hashing
>> > > power, do the math on varience... Seriously, stop it and go mine on a
>> > > smaller pool, or better yet, p2pool.
>> > >
>> >
>> > That I agree with.
>>
>> Glad to hear.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131107/a324be8f/attachment.html>

2023-06-07 15:07:16

- reply

📅 Original date posted:2013-10-03
📝 Original message:Names clearly solve a different problem than that, but we still use them,
so they must be solving _some_ problem :p In this case they're a unique
identifier humans can remember after a bit of use and easily communicate to
each other with little room for error. Securely mapping them to public
keys would make key verification simpler. Simpler than checking a much
larger key fingerprint, at least. Like I said, it's probably a niche
product ;)
I used to remember dozens of phone numbers before my phone did it for me,
but maybe I was just weird.
On Thu, Oct 3, 2013 at 9:22 AM, Mike Hearn <mike at plan99.net> wrote:
> 1) Generate sacrifice proof file using an app
> 2) Load file into browser
> 3) Surf
>
> Where are the names in that design? I'm not sure where NameCoin comes into
> this. The point of a sacrifice is it's an anonymous identity, there's no
> point attaching a name to it.
>
> BTW I keep phone numbers in an address book ;)
>
>
>
>
> On Thu, Oct 3, 2013 at 5:16 PM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:
>
>> Fair enough, though people still manage okay with phone numbers. And a
>> decentralized naming system seems to come at great cost - with namecoin you
>> need the whole blockchain to resolve names without trust. Strip out a bell
>> and whistle - meaningfulness and transferability of names - and you get a
>> simple, rudimentary (spam killing!) system that scales on any device. I'll
>> only argue that it seems to be Good Enough *for the types of people who
>> might care about decentralized names*. Probably a very small set :)
>>
>>
>> On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> Interesting observation, thanks.
>>>
>>> I'd think any competent implementation of such an identity scheme would
>>> not involve end users directly handling randomized nonsense words, however.
>>> I always imagined a sacrifice as being a file that you make with a GUI tool
>>> and load into a browser extension.
>>>
>>>
>>> On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:
>>>
>>>> A couple more thoughts on this:
>>>>
>>>> 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
>>>> per phoneme.
>>>> 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
>>>> information into the name, e.g. the first 5 bits could be input as the key
>>>> to a PRP that permutes the last 38 back to a standard encoding of a tx
>>>> location. This would give the user 32 random names per sacrifice to choose
>>>> from, and 38 bits to encode its location in the blockchain, which is enough
>>>> for pretty large blocks.
>>>>
>>>> Sample 4 phoneme names:
>>>> ~milmoz-vyrnyx
>>>> ~mypnoz-fojzas
>>>> ~sawfex-bovlec
>>>> ~fidhut-guvgis
>>>> ~bobfej-jessuk
>>>> ~furcos-diwhuw
>>>> ~wokryx-wilrox
>>>> ~bygbyl-caggos
>>>> ~vewcyv-jyjsal
>>>> ~daxsaf-cywkul
>>>>
>>>> They're not that bad IMHO, especially if you get to pick a decent one
>>>> from a bunch.
>>>>
>>>>
>>>> On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:
>>>>
>>>>> The location of a tx in the blockchain can be encoded in
>>>>> n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
>>>>> transactions in the block. Currently h~250,000 and t~500, so n~27. A CVC
>>>>> phoneme encodes ~10.7 bits *, so a transaction today can be located in the
>>>>> blockchain with 3 of these, e.g. reb-mizvig. This is reasonably short,
>>>>> readable and memorable.
>>>>>
>>>>> The identity protocol Jeff Garzik is working on will link a public key
>>>>> fingerprint to a miner sacrifice transaction. This tx could in turn be
>>>>> uniquely described with a short name as above. Associating this name with
>>>>> the public key becomes secure once the tx is sufficiently buried in the
>>>>> blockchain. In the identity protocol, lightweight clients check the
>>>>> validity of a sacrifice tx by checking that its merkle path is valid. But
>>>>> this path encodes, via the ordering of the hashes at each level, the
>>>>> location of the transaction in the block, so the lightweight client can
>>>>> verify the sacrifice tx's short name using only the information he already
>>>>> has.
>>>>>
>>>>> Some more random names:
>>>>> vec-halhic
>>>>> wom-vizpyd
>>>>> guv-zussof
>>>>> jog-copwug
>>>>> seg-rizges
>>>>> jyg-somgod
>>>>> pax-synjem
>>>>> zyg-zuxdyj
>>>>> gid-mutdyj
>>>>> rel-hyrdaj
>>>>>
>>>>> Sources of inspiration:
>>>>> urbit.org
>>>>> https://en.bitcoin.it/wiki/Identity_protocol_v1
>>>>>
>>>>> * This is somewhat restricted: I disallowed q for obvious reasons and
>>>>> k because it conflicts with c, and c looks much softer and less like
>>>>> Klingon. H is allowed for the first consonant, but not the second, and x
>>>>> is allowed for the last one, but not the first one. Y is a vowel, but not
>>>>> a consonant. Maybe these weren't quite the right choices. Paint away!
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> October Webinars: Code for Performance
>>>> Free Intel webinars can help you accelerate application performance.
>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> most from
>>>> the latest Intel processors and coprocessors. See abstracts and
>>>> register >
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131003/c437c1d1/attachment.html>

2023-06-07 15:07:15

- reply

📅 Original date posted:2013-10-03
📝 Original message:Fair enough, though people still manage okay with phone numbers. And a
decentralized naming system seems to come at great cost - with namecoin you
need the whole blockchain to resolve names without trust. Strip out a bell
and whistle - meaningfulness and transferability of names - and you get a
simple, rudimentary (spam killing!) system that scales on any device. I'll
only argue that it seems to be Good Enough *for the types of people who
might care about decentralized names*. Probably a very small set :)
On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <mike at plan99.net> wrote:
> Interesting observation, thanks.
>
> I'd think any competent implementation of such an identity scheme would
> not involve end users directly handling randomized nonsense words, however.
> I always imagined a sacrifice as being a file that you make with a GUI tool
> and load into a browser extension.
>
>
> On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:
>
>> A couple more thoughts on this:
>>
>> 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
>> per phoneme.
>> 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
>> information into the name, e.g. the first 5 bits could be input as the key
>> to a PRP that permutes the last 38 back to a standard encoding of a tx
>> location. This would give the user 32 random names per sacrifice to choose
>> from, and 38 bits to encode its location in the blockchain, which is enough
>> for pretty large blocks.
>>
>> Sample 4 phoneme names:
>> ~milmoz-vyrnyx
>> ~mypnoz-fojzas
>> ~sawfex-bovlec
>> ~fidhut-guvgis
>> ~bobfej-jessuk
>> ~furcos-diwhuw
>> ~wokryx-wilrox
>> ~bygbyl-caggos
>> ~vewcyv-jyjsal
>> ~daxsaf-cywkul
>>
>> They're not that bad IMHO, especially if you get to pick a decent one
>> from a bunch.
>>
>>
>> On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:
>>
>>> The location of a tx in the blockchain can be encoded in
>>> n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
>>> transactions in the block. Currently h~250,000 and t~500, so n~27. A CVC
>>> phoneme encodes ~10.7 bits *, so a transaction today can be located in the
>>> blockchain with 3 of these, e.g. reb-mizvig. This is reasonably short,
>>> readable and memorable.
>>>
>>> The identity protocol Jeff Garzik is working on will link a public key
>>> fingerprint to a miner sacrifice transaction. This tx could in turn be
>>> uniquely described with a short name as above. Associating this name with
>>> the public key becomes secure once the tx is sufficiently buried in the
>>> blockchain. In the identity protocol, lightweight clients check the
>>> validity of a sacrifice tx by checking that its merkle path is valid. But
>>> this path encodes, via the ordering of the hashes at each level, the
>>> location of the transaction in the block, so the lightweight client can
>>> verify the sacrifice tx's short name using only the information he already
>>> has.
>>>
>>> Some more random names:
>>> vec-halhic
>>> wom-vizpyd
>>> guv-zussof
>>> jog-copwug
>>> seg-rizges
>>> jyg-somgod
>>> pax-synjem
>>> zyg-zuxdyj
>>> gid-mutdyj
>>> rel-hyrdaj
>>>
>>> Sources of inspiration:
>>> urbit.org
>>> https://en.bitcoin.it/wiki/Identity_protocol_v1
>>>
>>> * This is somewhat restricted: I disallowed q for obvious reasons and k
>>> because it conflicts with c, and c looks much softer and less like
>>> Klingon. H is allowed for the first consonant, but not the second, and x
>>> is allowed for the last one, but not the first one. Y is a vowel, but not
>>> a consonant. Maybe these weren't quite the right choices. Paint away!
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131003/1e734bac/attachment.html>

2023-06-07 15:07:14

- reply

📅 Original date posted:2013-10-03
📝 Original message:The location of a tx in the blockchain can be encoded in n=log2(h)+log2(t)
bits, where h is the block height, and t is the number of transactions in
the block. Currently h~250,000 and t~500, so n~27. A CVC phoneme encodes
~10.7 bits *, so a transaction today can be located in the blockchain with
3 of these, e.g. reb-mizvig. This is reasonably short, readable and
memorable.
The identity protocol Jeff Garzik is working on will link a public key
fingerprint to a miner sacrifice transaction. This tx could in turn be
uniquely described with a short name as above. Associating this name with
the public key becomes secure once the tx is sufficiently buried in the
blockchain. In the identity protocol, lightweight clients check the
validity of a sacrifice tx by checking that its merkle path is valid. But
this path encodes, via the ordering of the hashes at each level, the
location of the transaction in the block, so the lightweight client can
verify the sacrifice tx's short name using only the information he already
has.
Some more random names:
vec-halhic
wom-vizpyd
guv-zussof
jog-copwug
seg-rizges
jyg-somgod
pax-synjem
zyg-zuxdyj
gid-mutdyj
rel-hyrdaj
Sources of inspiration:
urbit.org
https://en.bitcoin.it/wiki/Identity_protocol_v1
* This is somewhat restricted: I disallowed q for obvious reasons and k
because it conflicts with c, and c looks much softer and less like
Klingon. H is allowed for the first consonant, but not the second, and x
is allowed for the last one, but not the first one. Y is a vowel, but not
a consonant. Maybe these weren't quite the right choices. Paint away!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131003/d22dc584/attachment.html>

2023-06-07 15:07:14

- reply

📅 Original date posted:2013-10-03
📝 Original message:A couple more thoughts on this:
1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits per
phoneme.
2) An extra phoneme (4 encode 43 bits total) gives room to put extra
information into the name, e.g. the first 5 bits could be input as the key
to a PRP that permutes the last 38 back to a standard encoding of a tx
location. This would give the user 32 random names per sacrifice to choose
from, and 38 bits to encode its location in the blockchain, which is enough
for pretty large blocks.
Sample 4 phoneme names:
~milmoz-vyrnyx
~mypnoz-fojzas
~sawfex-bovlec
~fidhut-guvgis
~bobfej-jessuk
~furcos-diwhuw
~wokryx-wilrox
~bygbyl-caggos
~vewcyv-jyjsal
~daxsaf-cywkul
They're not that bad IMHO, especially if you get to pick a decent one from
a bunch.
On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:
> The location of a tx in the blockchain can be encoded in n=log2(h)+log2(t)
> bits, where h is the block height, and t is the number of transactions in
> the block. Currently h~250,000 and t~500, so n~27. A CVC phoneme encodes
> ~10.7 bits *, so a transaction today can be located in the blockchain with
> 3 of these, e.g. reb-mizvig. This is reasonably short, readable and
> memorable.
>
> The identity protocol Jeff Garzik is working on will link a public key
> fingerprint to a miner sacrifice transaction. This tx could in turn be
> uniquely described with a short name as above. Associating this name with
> the public key becomes secure once the tx is sufficiently buried in the
> blockchain. In the identity protocol, lightweight clients check the
> validity of a sacrifice tx by checking that its merkle path is valid. But
> this path encodes, via the ordering of the hashes at each level, the
> location of the transaction in the block, so the lightweight client can
> verify the sacrifice tx's short name using only the information he already
> has.
>
> Some more random names:
> vec-halhic
> wom-vizpyd
> guv-zussof
> jog-copwug
> seg-rizges
> jyg-somgod
> pax-synjem
> zyg-zuxdyj
> gid-mutdyj
> rel-hyrdaj
>
> Sources of inspiration:
> urbit.org
> https://en.bitcoin.it/wiki/Identity_protocol_v1
>
> * This is somewhat restricted: I disallowed q for obvious reasons and k
> because it conflicts with c, and c looks much softer and less like
> Klingon. H is allowed for the first consonant, but not the second, and x
> is allowed for the last one, but not the first one. Y is a vowel, but not
> a consonant. Maybe these weren't quite the right choices. Paint away!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131003/cb5995fb/attachment.html>

2023-06-07 15:03:01

- reply

📅 Original date posted:2013-06-10
📝 Original message:Reserving my judgement until I've though about it more (design by committee
scares me, and this voting sounds expensive), I think the SPV-verifiable
moving median can be done by binning the space of block size limits, and
for each node in the UTXO tree, a value for each bin is stored which is the
sum of the corresponding bins of each of the children. The childless nodes
- which correspond to the individual UTXOs - increment the appropriate bin
of their parents according to the rules you mentioned. The bin values in
the root node of the UTXO tree would then be added to those, weighted
appropriately, of the previous N blocks.
The hash of a node would be that of the bin values, concatenated with the
child nodes' hashes. In this way, any step of the calculation of the
median would produce a localized error in the UTXO tree that's easily
verified.
The number of bins would have to be kept relatively small in order to keep
this from adding too much data to the UTXO tree branches though.
On Mon, Jun 10, 2013 at 2:30 AM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jun 10, 2013 at 04:09:26AM +0000, John Dillon wrote:
>
> My general comments on the idea are that while it's hard to say if a
> vote by proof-of-stake is really representative, it's likely the closest
> thing we'll ever get to a fair vote. Proof-of-stake is certainely better
> than just letting miners choose; as you point out miners can always
> choose to decrease the blocksize anyway so we only need a vote on
> allowable increases. Proof-of-stake also clearly favors those who
> actually have invested in Bitcoin over those who only talk about
> Bitcoin.
>
> I'll also say that while I know people will complain about putting
> politics into a technical problem, as I keep saying, is *is* a political
> issue. The limitations may be technical, but the ultimate issue is a
> very political decision about what we want Bitcoin to be. Yes, there
> will be people campaigning left and right to get users to vote for
> various limits with their coins, deal with it. Democracy is messy.
>
> Voting would take a lot of the nastier politics out of the situation,
> perhaps somewhat ironically. It would quite clearly take control away
> from the core development team, and the Bitcoin Foundation, and put it
> back in the hands of the community; you can't argue conspiracy theories
> that the Foundation is trying to control Bitcoin when there is a
> completely transparent voting system in place. People will complain that
> big Bitcoin players are throwing their weight around, but the blockchain
> itself is a voting mechanism that is anything but 1 person = 1 vote.
>
> Of course I wouldn't be the slightest bit surprised if users happily
> vote themselves into something looking like a centralized PayPal
> replacement in the long run, but at least if that happens the process by
> which they get there will be transparent and relatively democratic.
>
>
> > A vote will consist of a txout with a scriptPubKey of the following form:
> >
> > OP_RETURN magic vote_id txid vout vote scriptSig
> >
> > Where scriptSig is a valid signature for a transaction with nLockTime
> > 500,000,000-1 spending txid:vout to scriptPubKey:
> >
> > OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL
>
> I just wanted to point out how general this mechanism is. Regardless of
> what the scriptPubKey form is, standard, P2SH, multisig, whatever to
> vote is to simply prove you could have spent the txout.
>
> > vote_id is the ID of the specific vote being made, and magic is included
> to
> > allow UTXO proof implementations a as yet unspecified way of identifying
> votes
> > and including the weighted median as part of the UTXO tree sums. (it also
> > allows SPV clients to verify the vote if the UTXO set is a Patricia tree
> of
> > scriptPubKeys) vote is just the numerical vote itself.
>
> Ah, you're assuming a direct Patricia tree. Keep in mind that
> scriptPubKey's can be up to 10,000 bytes long, and an attacker can use
> that (with 10,000 other txouts) to create some extremely deep trees. I
> said on IRC a few days ago about how skeptical I am of implementing
> consensus critical systems with such huge differences in average and
> worst case, but I'll admit this is a decent use-case.
>
> Having said that, proof to SPV clients leaves open the interesting
> possibility that a third-party holding Bitcoins on your behalf can prove
> that they voted according to your wishes, or even prove they voted
> according to all their users wishes. Basically we'd add a rule for the
> UTXO tree where a specific OP_RETURN form is included in the UTXO tree,
> even though it is unspendable, and is removed from the tree if the
> master txout is spent. Note that in this case by "prove they voted" we
> mean the service actually taking the step of ensuring their vote was
> recorded in the blockchain.
>
> > The vote must compute
> > the median, rather than the mean, so as to not allow someone to skew the
> vote
> > by simply setting their value extremely high. Someone who still
> remembers their
> > statistics classes should chime in on the right way to compute a median
> in a
> > merkle-sum-tree.
>
> I think the definition of the median requires knowledge of all the points
> so
> it'll have to be a separate sorted tree - kinda complex unfortunately if
> you really do want to be able to do full proof to SPV clients. Maybe
> just putting the hash of the overall results in the coinbase is enough
> for now.
>
> The term to google is "moving median" - looks complex.
>
> > Of course in the future the voting mechanism can be used for additional
> votes
> > with an additional vote_id. For instance the Bitcoin community could
> vote to
> > increase the inflation subsidy, another example of a situation where the
> wishes
> > of miners may conflict with the wishes of the broader community.
>
> Good idea on keeping the code general.
>
> > For any given block actual limit in effect is then the rolling median of
> the
> > blocks in the last year. At the beginning of every year the value
> considered to
> > be the status quo resets to the mean of the limit at the beginning and
> end of
> > the interval. (again, by "year" we really mean 52,560 blocks) The
> rolling
> > median and periodic reset process ensures that the limit changes
> gradually and
> > is not influenced by temporary events such as hacks to large exchanges or
> > malicious wallet software. The rolling median also ensures that for a
> miner
> > the act of including a vote is never wasted due to the txout later being
> spent.
>
> Good points, although keep in mind you've created a lot of consensus
> critical code that is easiest to implement with floating point... not a
> good thing.
>
> One way to mitigate that risk might be to take advantage of the fact
> that unless the rolling median code itself is buggy, a consensus failure
> in the calculation is likely to result in different implementations
> still having a close agreement on the limit. So maybe we write some code
> where we won't build on top of a block that is larger than, say, 95% of
> the hard-limit unless another miner does so too?
>
> > Implementing the voting system can happen prior to an actual hard-fork
> allowing
> > for an increase and can be an important part of determining if the
> hard-fork is
> > required at all.
>
> Step #0 would be to think about OP_RETURN actually. FWIW Jeff Garzik has
> a pull-req (https://github.com/bitcoin/bitcoin/pull/2738) to enable it,
> although only one txout per tx, and only with a 80-byte payload.
>
> Even just some ad-hoc voting by the "raise-the-limit" crowd would be a
> good first step to gaging interest.
>
> > Coercion and vote buying is of course possible in this system. A miner
> could
> > say that they will only accept transactions accompanied by a vote for a
> given
> > limit. However in a decentralized system completely preventing vote
> buying is
> > of course impossble, and the design of Bitcoin itself has a fundemental
>
> Is it really? There might be someone clever with a cryptographic voting
> protocol, although in the case of Bitcoin we have to let people vote
> with arbitrary scriptPubKeys, so almost anything less general than full
> on SCIP just means miners force people to use the protocol where
> vote-buying is possible.
>
> > A voting process ensures that any increase to the blocksize genuinely
> > represents the desires of the Bitcoin community, and the process
> described
> > above ensures that any changes happen at a rate that gives all
> participants
> > time to react. The process also gives a mechanism for the community to
> vote to
> > decrease the limit if it turns out that the new one was in fact too
> high. (note
> > how the way the status quo is set ensures the default action is for the
> limit
> > to gradually decrease even if everyone stops voting)
>
> Good idea. So it'd decrease to the mean of the old and new limits
> basically, and if Bitcoin becomes "too centralized" users can simply do
> nothing and the process gradually reverses.
>
> > As many of you know I have been quite vocal that the 1MB limit should
> stay. But
> > I would be happy to support the outcome of a vote done properly,
> whatever that
> > outcome may be.
>
> Same here.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000068a8ad033afa763246fe451e840eae5215eb3a64e8101a46c3
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130610/214bfa8e/attachment.html>

2023-06-07 11:34:33

- reply

📅 Original date posted:2013-03-07
📝 Original message:My views on censorship resistance in the face of scaling:
1) I expect if I'm not careful about preserving my privacy with the way I
use Bitcoin, then I will always run the risk of being censored by miners.
This means connecting to the network anonymously, not reusing addresses,
and perhaps even mixing my coins. The onus is on me here to avoid
censorship, but I'm optimistic that this privacy preservation can be made
pretty automatic.
2) I expect anonymity systems to scale to accommodate Bitcoin full nodes,
not Bitcoin to stay small to avoid putting pressure on anonymity systems to
scale.
3) If 2 is too tall an order, then mining in a pool is always an option.
There should always be some countries in the world free enough to allow
mining pools to operate, and miners in countries that ban Bitcoin can
simply connect to these anonymously. If not, then Bitcoin is toast anyway,
is it not? If these miners are really interested in avoiding censoring
transactions, then they will do their due diligence and choose a pool that
doesn't do this. But even if they don't, censorship can be personally
avoided by following 1.
On Thu, Mar 7, 2013 at 2:19 PM, Mike Hearn <mike at plan99.net> wrote:
> As an aside, there's a paper coming out in perhaps a few months that
> describes a new way to provide Chaum-style privacy integrated with
> Bitcoin, but without the use of blinding and without any need for
> banks. It's quite smart, I was reviewing the paper this week.
> Unfortunately the technique is too slow and too complicated to
> actually integrate, but you'd probably get a kick out of it. It's
> based on zero knowledge proofs. You can talk to Ian Miers if you like,
> perhaps he'll send you a copy for review.
>
> Back on topic.
>
> This idea is not new. I proposed the idea of regulating miners to
> freeze certain outputs two years ago:
>
> https://bitcointalk.org/index.php?action=printpage;topic=5979.0
>
> I concluded that it was not a real risk because both mining and
> transactions can be done anonymously.
>
> Your argument rests on the assumption that you can't mine large blocks
> anonymously because Tor doesn't scale. Even if we go along with the
> idea that Tor is the only way to escape regulation (it's not), you
> should maybe take up its inability to move data sufficiently fast with
> the developers. Given that they routinely push two gigabits/second
> today, with an entirely volunteer run network, I think they'll be
> surprised to learn that their project is doomed to never be usable by
> miners.
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130307/5873f60a/attachment.html>

2023-06-07 10:19:12

- reply

📅 Original date posted:2012-06-25
📝 Original message:Here's the conversation I had with Mike that Gregory requested a link to:
Thanks!
Bad or hacked client devs is indeed a huge, worrying problem. The
official client is addressing this with a system called gitian, where
multiple developers all compile the same source to the same binary and
then sign the results. Multi-signatures raise the bar for releasing
hacked clients a lot. We're starting to investigate this with bitcoinj
too, but it's a lot of work.
Generally, the more people you have to involve in a conspiracy, the less
likely it is to succeed. If a few miners started to dominate the system
they have strong financial incentives to cheat, alternatively, they may
be subjected to government pressure. Having to get the client developers
involved too makes it much harder, especially as users have to actually
upgrade.
I started a thread on the development mailing list with your suggestion,
by the way.
On Mon, Jun 25, 2012 at 1:00 AM, Daniel Lidstrom <lidstrom83 at gmail.com
<mailto:lidstrom83 at gmail.com>> wrote:
Hey Mike,
I put our conversation in the email for easy reference.
In the unlikely event of a miner conspiracy to print money, is it
really so much of a further stretch to think the developers of a
widely used client could also be involved? (Well, maybe, since
miners are unaccountable and developers are not. OTOH if most users
are apathetic...) Also, isn't the advantage for lightweight clients
of SPV over the server-client model that you don't have to trust any
operator? Maybe I'm being too much of a purist here...
Regarding errors being cheap to send and expensive to verify,
compartmentalizing them the way I suggested before would make them
individually cheaper to verify. Just throwing around ideas:
requiring the error message be received by a quorum of peers before
checking, and dropping misbehaving or unreliable peers could help.
Also, not verifying error messages unless the peers relaying them
are willing to send all the data necessary to do so would help.
Hashcash could also be used to balance the costs to send and to
verify a given type of error message. I like your idea to only
check errors in blocks that are split points, and the length of the
split could also be a consideration.
> Can we move further conversations to email please? SMF kind of
> sucks as an inbox.
>
> Anyway, yes, your proposal makes a lot of sense, although I think
> in practice this is unlikely to be an issue. If a majority of
> miners did start mining on a chain with new rules, even if SPV
> clients couldn't detect the switch automatically it's very likely
> the developers of those clients would notify the users out of band
> in some way. For example, by pushing an update to users that
> explains the new rules to them and tells them how they can cash
> out of the Bitcoin economy if they disagree with the new consensus.
>
> If users are on the losing side of a rule change and want to stay
> there (eg, maybe most non-miners want to stay on the slower
> chain), then the client can just checkpoint the first block after
> the rule change occurred. Now even though there's a harder chain
> with the new rules, the client will stay with the old rules
> despite being blind to them. There's nothing that says checkpoints
> have to be hard coded - clients could poll the client developers
> every day to get new ones. So as long as the SPV devs are on the
> ball, most users would stay on the old rules even if the software
> can't do it by itself.
>
> All that said, broadcasting messages proving a block broke the
> rules is a nice backstop if it can be done without excessive
> complexity. There are some details to think about. These messages
> would be cheap to create and expensive to verify. There has to be
> something that stops me claiming to SPV clients that every single
> block is invalid and forcing them to do tons of useless work.
> Perhaps only blocks that are split points would be eligible. Also,
> currently, SPV clients do not form their own P2P network. They are
> always leaves of full nodes. So propagation of the messages might
> prove difficult unless that was changed.
> Hi Mike,
>
> Thanks for your reply. It was actually an old post of yours on
> the forum that made me understand the importance of lightweight
> clients being able to audit the coinbase tx.
>
> Re: input tx download, I think that splitting the "invalid
> coinbase" error notification into separate "input n in tx m is
> invalid" and "invalid fee arithmetic" errors would mean mobile
> clients would only ever have to download at most one input tx to
> verify an invalid coinbase.
>
> The "invalid fee arithmetic" error could also be compartmentalized
> into "invalid fee arithmetic in tx batch n", where the fee
> subtotals are recorded in the block, so as to be separately
> verifiable. Then the necessary tx downloads would be completely
> capped.
>
> Anyway, I think most of my fears about lifting the block size
> limit are put to rest by these lines of thinking Smiley
> Hey Daniel,
>
> I think you're thinking along the right lines here. We should be
> looking at cheap and backwards compatible ways to upgrade the SPV
> trust model to more than just going along with the majority consensus.
>
> For the coinbase issue, it's actually really important because if
> you can't calculate fees, you can't check the size of the coinbase
> value and therefore a conspiracy of miners could try and change
> the inflation schedule. The worst that can happen today if miners
> decide to try and fork the ruleset against the best interests of
> other users, is that they produce chains that are not accepted by
> regular merchant/exchange/end-user nodes and tx confirmation slows
> down. But if most users are on SPV nodes they will happily accept
> the new blocks and the miner conspiracy will have successfully
> seized control of the money supply for the majority of end users.
>
> The problem with calculating fees is you actually need not only
> every tx in a block, but all the input txns too! You can't know
> the fee of a transaction without the input transactions being
> available too.
>
> So there's good news and bad news. The good news is you don't have
> to actually store every transaction on disk or check signatures,
> which is the expensive part, if you're an SPV node - you can still
> check the coinbase value asynchronously after receiving a block by
> requesting the entire contents and all the input transactions
> (+branches, of course). If you are in an environment that is
> always-on and not bandwidth constrained this can make a lot of
> sense. For example, if you're running an SPV client on a regular
> PC that is sitting in a shop somewhere, just downloading a lot of
> data is still very cheap compared to indexing it all and verifying
> all the signatures. I'm implementing support for this kind of
> async verification in bitcoinj at the moment.
>
> Where it doesn't really make sense is mobile clients, and your
> ideas of notification can help a lot there. The first type of
> error broadcast I'd add is actually for detected double spends
> because there's a paper from researchers at ETH which show this is
> needed to address a feasible attack on todays infrastructure. But
> adding more later to detect invalid blocks is not a bad idea.
> Hi Mike,
>
> I wanted to post this on the forum and figured that since, based
> on the subject, you'd probably end up reading it anyway, I thought
> I'd run it by you first to see if there's any merit to it.
>
> Quote
> I think similar ideas are currently being tossed around.
>
> The motivation here is to keep rule enforcement maximally
> decentralized while scaling Bitcoin. Basically, SPV clients could
> subscribe to peers' announcements of /invalid/ blocks + their
> specific failure mode. AFAICT, most of the possible failure modes
> are easily verifiable by smart phone SPV clients, even at scale.
> For example, inclusion of double spends or otherwise invalid txs
> are easy to verify /given the necessary data/, and Merkle tree
> nodes can be deemed invalid /if no peer can produce the data that
> hashes to it/ (gotta be careful to detect and deal with false
> positives here). The only failure mode I can think of that isn't
> easily verifiable at scale is an invalid quantity of fees spent in
> the coinbase tx, since that currently requires the download of the
> whole block. (I think I have an idea to fix this below.)
>
> This trust model relies upon having a single fully validating peer
> that will reliably announce invalid blocks. To help this, one or
> more peers could be periodically cycled, and new ones asked if the
> main chain contains any invalid blocks. Worst case scenario, an
> SPV client reverts to the current trust model, so this idea can
> only improve the situation. Best case, it takes advantage of the
> fact that public information is hard to suppress.
>
> *Verifying coinbase tx invalidity at scale with SPV clients*
>
> While this is currently not prohibitive for a smart phone if done
> only occasionally, this will not be the case if the block size
> limit is lifted. The idea is to split up the summing of the
> spendable fees into verifiable pieces. A new merkle tree is
> calculated where the i'th leaf's data is the total fees in the
> i'th chunk of 1024 txs, along with these txs' Merkle root (to
> prevent collisions). The Merkle root of this new tree is then
> included somewhere in the block.
>
> To verify a claim of invalidity of one of these leaves requires
> the download of ~1MB of tx data (along with a small amount of
> Merkle tree data to verify inclusion). If no claims are made
> against it, the leaf data is assumed to be valid. If this is the
> case, but shenanigans are called on the coinbase tx, downloading
> all of the leaf data, verifying inclusion, and calculating the
> total spendable fees is easily doable for a smart phone, even at
> very large tx volumes.
>
> Thanks for any thoughts/suggestions!
>
> Cheers,
> Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120625/bf142529/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 382 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120625/bf142529/attachment.gif>