Petr Praus [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-07 📝 Original message:I think it's worth noting ...
📅 Original date posted:2013-05-07
📝 Original message:I think it's worth noting that quite a large portion of Linux users
probably get the mainline Bitcoin client from the packages. I think Bitcoin
package maintainers are doing mostly a pretty good job :)
On 6 May 2013 18:13, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, May 6, 2013 at 3:51 PM, Adam Back <adam at cypherspace.org> wrote:
> > Maybe I could hack a pool to co-opt it into my netsplit and do the work
> for
> > me, or segment enough of the network to have some miners in it, and they
> do
> > the work.
>
> Or you can just let it mine honestly and take the Bitcoins. This is
> fast (doesn't require weeks of them somehow not noticing that they're
> isolated), and yields the values I listed as 'costs' if you would have
> otherwise been able to use it to mine the difficulty down to 1. Cost
> is just as much foregone income from the alternative attack you could
> have done instead.
>
> > nor even topological, nor even
> > particularly long-lived.
>
> At least for attacks that drive the difficulty down it does.
>
> If you want to talk about abusing a pool or creating a partition in
> order to create short reorgs— I agree, those don't have to be long
> lived and you can find many messages where I've written on that
> subject.
>
> It's inconsiderate to propose one attack and when I respond to it
> changing the attack out from under me. :( I would have responded
> entirely differently if you'd proposed people segmenting the network
> and creating short reorgs instead of mining the difficulty down.
>
> > Do you know if there is any downwards limit on difficulty? I know it
> takes
> > going slow for a long and noticeable time, but I am just curious on the
> > theoretical limit.
>
> Every 2016 blocks can at most lower the difficulty by a factor of 4,
> thats where the log4 (number of 2016 groups needed) and 4^n (factor in
> cost reduction for each group) come from in the formulas I gave
> previously.
>
> > I dont see the signatures.
>
>
> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download
>
> The signatures can't be inside the tarball because they sign the tarball.
>
> Seems like the website redesign managed to hide the signatures pretty
> good. They're in the release announcements in any case, but that
> should be fixed. Even when they were prominently placed, practically
> no one checked them. As a result they are mostly security theater in
> practice :(, — so— unfortunately, is SSL: there are many CA's who will
> give anyone a cert with your name on it who can give them a couple
> hundred bucks and MITM HTTP (not HTTPS!) between the CA's
> authentication server and your webserver. Bitcoin.org is hosted by
> github, even if it had SSL and even if the CA infrastructure weren't a
> joke, the number of ways to compromise that hosting enviroment would
> IMO make SSL mostly a false sense of security.
>
> The gpg signatures and gitian downloader signatures provide good
> security if actually used, solving the "getting people to use them"
> problem is an open question.
>
> And I agree, this stuff is a bigger issue than many other things like
> mining the difficulty down.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> 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/20130506/39286b04/attachment.html>;
📝 Original message:I think it's worth noting that quite a large portion of Linux users
probably get the mainline Bitcoin client from the packages. I think Bitcoin
package maintainers are doing mostly a pretty good job :)
On 6 May 2013 18:13, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, May 6, 2013 at 3:51 PM, Adam Back <adam at cypherspace.org> wrote:
> > Maybe I could hack a pool to co-opt it into my netsplit and do the work
> for
> > me, or segment enough of the network to have some miners in it, and they
> do
> > the work.
>
> Or you can just let it mine honestly and take the Bitcoins. This is
> fast (doesn't require weeks of them somehow not noticing that they're
> isolated), and yields the values I listed as 'costs' if you would have
> otherwise been able to use it to mine the difficulty down to 1. Cost
> is just as much foregone income from the alternative attack you could
> have done instead.
>
> > nor even topological, nor even
> > particularly long-lived.
>
> At least for attacks that drive the difficulty down it does.
>
> If you want to talk about abusing a pool or creating a partition in
> order to create short reorgs— I agree, those don't have to be long
> lived and you can find many messages where I've written on that
> subject.
>
> It's inconsiderate to propose one attack and when I respond to it
> changing the attack out from under me. :( I would have responded
> entirely differently if you'd proposed people segmenting the network
> and creating short reorgs instead of mining the difficulty down.
>
> > Do you know if there is any downwards limit on difficulty? I know it
> takes
> > going slow for a long and noticeable time, but I am just curious on the
> > theoretical limit.
>
> Every 2016 blocks can at most lower the difficulty by a factor of 4,
> thats where the log4 (number of 2016 groups needed) and 4^n (factor in
> cost reduction for each group) come from in the formulas I gave
> previously.
>
> > I dont see the signatures.
>
>
> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download
>
> The signatures can't be inside the tarball because they sign the tarball.
>
> Seems like the website redesign managed to hide the signatures pretty
> good. They're in the release announcements in any case, but that
> should be fixed. Even when they were prominently placed, practically
> no one checked them. As a result they are mostly security theater in
> practice :(, — so— unfortunately, is SSL: there are many CA's who will
> give anyone a cert with your name on it who can give them a couple
> hundred bucks and MITM HTTP (not HTTPS!) between the CA's
> authentication server and your webserver. Bitcoin.org is hosted by
> github, even if it had SSL and even if the CA infrastructure weren't a
> joke, the number of ways to compromise that hosting enviroment would
> IMO make SSL mostly a false sense of security.
>
> The gpg signatures and gitian downloader signatures provide good
> security if actually used, solving the "getting people to use them"
> problem is an open question.
>
> And I agree, this stuff is a bigger issue than many other things like
> mining the difficulty down.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> 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/20130506/39286b04/attachment.html>;