Frank F [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-03-17 to 2013-11-06
💬 Posted a total of 5 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:09:00

- reply

📅 Original date posted:2013-11-06
📝 Original message:The problem with academics is that they don't have to worry about the real
world. They get paid to publish things, not to be helpful to society.
On Tue, Nov 5, 2013 at 11:33 PM, kjj <bitcoin-devel at jerviss.org> wrote:
> One of the things that really gets me going is when someone devises a
> model, tests it against itself, and then pretends that they've learned
> something about the real world.
>
> Naturally, the Selfish Mining paper is exactly this sort of nonsense.
> Their model is one with no latency, and one where the attacker has total
> visibility across the network. An iterated FSM is not a suitable
> simulation of the bitcoin system. The bitcoin network does not have
> states, and to the extent that you can pretend that we do, you can't
> simulate transitions between them with static probabilities.
>
> The authors understand this deep down inside, even though they didn't
> work out the implications. They handwave the issue by assuming a total
> sybil attack, and in true academic spirit, they don't realize that the
> condition necessary for the attack is far, far worse than the attack
> itself.
>
> Greg said he'd like to run some simulations, and I'm thinking about it
> too. Unfortunately, he is busy all week, and I'm lazy (and also busy
> for most of tomorrow).
>
> If neither of us get to it first, I'm willing to pitch in 1 BTC as a
> bounty for building a general bitcoin network simulator framework. The
> simulator should be able to account for latency between nodes, and
> ideally within a node. It needs to be able to simulate an attacker that
> owns varying fractions of the network, and make decisions based only on
> what the attacker actually knows. It needs to be able to simulate this
> "attack" and should be generic enough to be easily modified for other
> crazy schemes.
>
> (Bounty offer is serious, but expires in one year [based on the earliest
> timestamp that my mail server puts on this email], and /may/ be subject
> to change if the price on any reputable exchange breaks 1000 USD per BTC
> in that period.)
>
> Basically, the lack of a decent network simulator is what allowed this
> paper to get press. If the author had been able to see the importance
> of the stuff he was ignoring, we wouldn't be wasting so much time
> correcting him (and sadly the reporters that have no way to check his
> claims).
>
> https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
--
*MONEY IS OVER!*
IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131106/a4337e71/attachment.html>

2023-06-07 15:06:21

- reply

📅 Original date posted:2013-08-19
📝 Original message:This sounds like an ideal compromise.
On Mon, Aug 19, 2013 at 3:16 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Aug 19, 2013 at 1:09 PM, Frank F <frankf44 at gmail.com> wrote:
> > If there are technical problems with getwork, maybe they should be
> addressed
> > and fixed instead of outright abandoned.
>
> They have been, resulting in a replacement called "getblocktemplate"
> which (presumably) almost everyone talking to bitcoin(d|-qt) has been
> using for a long time.
>
> I think removing the ability to mine in the stock package would be
> regrettable, but to be honest we already don't have it for the
> mainnet. I think we should do as Jeff suggests and remove getwork. But
> I think we should also package along a proper getblocktemplate miner
> to remove any doubt that we're providing a full network node here. (I
> note that the choice of miner is also easy: Regardless of people's
> preferences which way or another, AFAIK only luke's bfgminer stuff can
> mine directly against bitcoin getblocktemplate with no pool in the
> middle. It also supports a huge variety of hardware, and a superset
> of our target platforms)
>
--
*MONEY IS OVER!*
IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130819/dbbada07/attachment.html>

2023-06-07 15:06:21

- reply

2023-06-07 15:06:20

- reply

📅 Original date posted:2013-08-19
📝 Original message:Thank you for setting me straight. Please forgive my ignorance.
On Mon, Aug 19, 2013 at 3:14 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Mon, Aug 19, 2013 at 10:09 PM, Frank F <frankf44 at gmail.com> wrote:
> > I strongly object to removing the only mechanism that allows anyone to
> say
> > that bitcoin is p2p, in the truest sense of the word. Moves like this
> that
> > favor only the pool operators and private mining interests are signs that
> > bitcoin is headed towards a monopoly/cartel model, and that would be a
> > tragic outcome for something that holds a great promise. Nobody knows
> what
> > mining will look like in the future, and denying the individual novice
> the
> > ability to mine at a small scale, even if we may think it is inefficient
> > now, is not a good path to start down.
> >
> > If there are technical problems with getwork, maybe they should be
> addressed
> > and fixed instead of outright abandoned.
>
> They were addressed and fixed in a successor API, getblocktemplate.
> It's even more decentralization-friendly, as it allows the caller to
> see what transactions the daemon is trying to put into a block, and
> even modify it.
>
> The suggestion here is not to remove functionality - only to remove an
> obsolete API for doing so.
>
> --
> Pieter
>
--
*MONEY IS OVER!*
IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130819/0bf724a7/attachment.html>

2023-06-07 15:06:19

- reply

📅 Original date posted:2013-08-19
📝 Original message:I strongly object to removing the only mechanism that allows anyone to say
that bitcoin is p2p, in the truest sense of the word. Moves like this that
favor only the pool operators and private mining interests are signs that
bitcoin is headed towards a monopoly/cartel model, and that would be a
tragic outcome for something that holds a great promise. Nobody knows what
mining will look like in the future, and denying the individual novice the
ability to mine at a small scale, even if we may think it is inefficient
now, is not a good path to start down.
If there are technical problems with getwork, maybe they should be
addressed and fixed instead of outright abandoned.
On Mon, Aug 19, 2013 at 11:27 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to
> remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork
>
> On mainnet, almost everybody uses a pool (and therefore, not "getwork"
> directly to bitcoind). Those few who solo mine use a pool server to
> talk to bitcoind via "getblocktemplate" or other means. Tests show
> that attempts to solo mine on mainnet via "getwork" lead to delays and
> problems.
>
> On testnet, getwork has a better chance of continuing to work.
> Nevertheless, the same tools (open source pool servers or p2pool) are
> available for testnet, obviating the continued need to support
> getwork.
>
> However, at one time, getwork to bitcoind was widely used. I wanted
> to poke the audience, to gauge response to removing "getwork." If a
> driving use case remains of which we're unaware, speak up, please. We
> don't want to break anybody needlessly.
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
*MONEY IS OVER!*
IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130819/8e457133/attachment.html>

2023-06-07 11:40:29

- reply

📅 Original date posted:2013-03-17
📝 Original message:On Sat, Mar 16, 2013 at 9:03 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> On 03/16/2013 09:13 PM, Gavin Andresen wrote:
> > I chose May 15 arbitrarily; two months seems like a reasonable 'quick'
> > amount of time to give people to upgrade/workaround.
> >
>
> Maybe you should wait until after the Bitcoin Conference -- if something
> goes wacky on May 15th but then everyone is getting on a plane to go to
> San Jose two days later, it may create unnecessary stress. It's
> probably not a big deal, but if the date is arbitrary anyway, why not
> just push back one more week?
>
Well, he did make the bitcoin.org/may15.html page already. It would be
crazy to change that now.
>
> -Alan
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
*MONEY IS OVER!*
IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130316/c50f31c4/attachment.html>