Nick Simpson [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-07-09 to 2015-01-31
💬 Posted a total of 6 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:29:08

- reply

📅 Original date posted:2015-01-31
📝 Original message:This has been discussed before. I believe most people don't expect Bitcoin
to replace all of the various methods of payment. Scalability is always a
concern, just not to the level of Alipay this year (or the next or the
next for that matter.)
Nick
On Jan 30, 2015 7:08 PM, "Angel Leon" <gubatron at gmail.com> wrote:
> On the Chinese "Single's Day" (sort of like the american Black Friday)
> according to MIT's Tech Review
> <http://www.technologyreview.com/news/534001/alipay-leads-a-digital-finance-revolution-in-china/>
> magazine
>
> "Alipay handled up to 2.85 million transactions per minute, and 54 percent
> of its transactions are made via mobile device."
>
> For a few weeks I've been reading the conversations about block sizes and
> the experiments being done on the subject with larger blocks.
>
> On the day with the most transactions, the Bitcoin block chain averages
> about 73 transactions per minute. I kept wondering what blocksize we'd need
> for handling 100,000 transactions per minute, and estimated that roughly
> we'd need a blocksize of about 1300x times larger than what we have now, so
> bigger than 1Gb block... but seeing the numbers Alipay gets to handle just
> in China make me wonder how scalable is Bitcoin if it were to truly compete
> with worldwide financial services.
>
> If you were to include double the number Alipay can handle, you'd be
> shooting about 6 million transactions per minute, or roughly 60 million
> transactions per block.
>
> If you average every transaction around 250 bytes, then you'd need ~15
> Gigabytes per block to be broadcast and hashed by all the full nodes every
> 10 minutes, eating good 2Tb of storage daily... do miners have enough
> bandwidth and CPU power to handle this?
>
> are my scalability concerns absurd?
>
> http://twitter.com/gubatron
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> 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/20150130/249fbe2e/attachment.html>

2023-06-07 15:29:08

- reply

2023-06-07 15:21:51

- reply

📅 Original date posted:2014-05-20
📝 Original message:Referring to the subsidy for miners as "wasting it on miners" isn't going to garner you much favor.
On May 20, 2014 11:12:53 AM CDT, Stephen Reed <stephenreed at yahoo.com> wrote:
>I completed a whitepaper for Bitcoin a proof-of-stake version which
>uses a single nomadic verifiable mint agent and distributed replication
>of a single blockchain by compensated full nodes to achieve 6-hop,
>sub-second transaction acknowledgement times. Plus it pays dividends to
>holders instead of wasting it on miners. Subsidized transaction fees
>are thus lower.
>
>https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
>
>
>Because the code is not yet written, this idea is half-baked so to
>speak. Comments appreciated on my project thread, which will be a
>development diary. I plan a hard fork of the Bitcoin blockchain in
>early 2016, after a year of public system testing, and conditioned on
>wide approval.
>
>https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403
>
>-Steve
>
>Stephen L. Reed
>Austin, Texas, USA
>512.791.7860
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos.
>Get unparalleled scalability from the best Selenium testing platform
>available
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/20140520/34da049b/attachment.html>

2023-06-07 15:21:30

- reply

📅 Original date posted:2014-05-16
📝 Original message:Luke's server has been having issues with ipv4 routing lately anyway, even ignoring any DNS issues.
Nick
On May 16, 2014 12:17:17 PM CDT, Rob Golding <rob.golding at astutium.com> wrote:
>> > dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs
>
>dnsseed.bitcoin.dashjr.org. 60 IN NS jun.dashjr.org.
>but jun.dashjr.org isn't responding to dns queries (as at 18.10 GMT
>2014-05-16)
>
>that would be a fundamental problem with the dns infrastructure for
>that
>domain (and the sub-hosts/records) , with the authoritive server not
>replying to the dns query
>
>> > testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica
>
>Similarly no response from the alias'd aws dns service on 23.21.243.183
>(testnet-seed-ns1.bitcoin.petertodd.org) from various test locations in
>Europe
>
>If there's a requirement for a domain & highly redundant dns to
>hard-code
>into something, and one of the dev's drops me an email, I can get that
>organised FoC, but these issues look like 'common'
>firewall/transit/connectivity issues at first glance.
>
>Rob
>
>
>------------------------------------------------------------------------------
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos.
>Get unparalleled scalability from the best Selenium testing platform
>available
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>_______________________________________________
>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/20140516/f8042474/attachment.html>

2023-06-07 15:13:39

- reply

📅 Original date posted:2014-02-10
📝 Original message:You must be new here. MtGox very rarely comments on things like this publicly, outside of irc or their website.
Second, MtGox problem is a MtGox problem. You have no right to demand access to their private code. If you feel wronged as a customer, sue them. Otherwise, they have no obligation to you.
I believe you are "barking up the wrong tree".
Respectfully,
Nick
On February 10, 2014 10:14:02 AM CST, Troy Benjegerdes <hozer at hozed.org> wrote:
>Okay, why the everloving FUCK is there not someone on this list with a
>@mtgox.com address talking about this?
>
>I started using bitcoin because I could audit the code, and when the
>developer cabal does stuff 'off-list' what you do is hand over market
>manipulation power to the selected cabal of company insiders who are
>discussing things 'off-list'.
>
>The people having a 'private' discussion about how to solve this are
>TAKING MONEY from everyone else, by having access to insider
>information.
>
>I don't think any of the developers actually have a clue this is the
>result, because a good chunk of them are employed by for-profit
>companies
>funded by venture capital, and VC lawyers are very good at writing
>employment contracts that provide plausible deniability of insider
>trading.
>
>The press MAKES MONEY (okay, takes money) by manipulating markets,
>and venture capitalists pay lots of money to ensure the market is
>manipulated in ways they can profit from.
>
>Private market manipulation is one of the costs of anonymity and
>privacy,
>and I don't really like paying for some off-list discussion of what
>appears
>to be a serious scalability and usability problem.
>
>Bitcoin is such a powerful tool because it broadcasts transactions to
>the network for everyone to see.
>
>Can we please broadcast some more technical details to this mailing
>list,
>including exactly what MtGox is doing, and how they wish to resolve it?
>
>If you gave me the entire code stack that MtGox runs on under an AGPLv3
>license, I'm pretty sure I, along with everyone else here could come up
>with a workable solution. I think a code release would be a huge win
>for MtGox as well, and would cement their position as market leader in
>transparent cryptocurrency trading.
>
>Otherwise we are just a bunch of dinghys getting capsized one by one
>in a sea of market-manipulating white whales. Isn't the closed door
>market manipulation of the big banks one of the reasons we all started
>using Bitcoin in the first place?
>
>Why do revolutions always put the same old bullshit back in power?
>
>What we need is some transparent code evolution.
>
>On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote:
>> Hi all,
>>
>> I was a bit surprised to see MtGox's announcement. The malleability
>of
>> transactions was known for years already (see for example the wiki
>> article on it, https://en.bitcoin.it/wiki/Transaction_Malleability
>it,
>> or mails on this list from 2012 and 2013). I don't consider it a very
>> big problem, but it does make it harder for infrastructure to
>interact
>> with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to
>> avoid it altogether to make life easier for everyone.
>>
>> But we can't just change all infrastructure that exists today. We're
>> slowly working towards making malleability harder (and hopefully
>> impossible someday), but this will take a long time. For example, 0.8
>> not supporting non-DER encoded signatures was a step in that
>direction
>> (and ironically, the trigger that caused MtGox's initial problems
>> here). In any case, this will take years, and nobody should wait for
>> this.
>>
>> There seem to be two more direct problems here.
>> * Wallets which deal badly with modified txids.
>> * Services that use the transaction id to detect unconfirming
>transactions.
>>
>> The first is something that needs to be done correctly in software -
>> it just needs to be aware of malleability.
>>
>> The second is something I was unaware of and would have advised
>> against. If you plan on reissuing a transaction because on old
>version
>> doesn't confirm, make sure to make it a double spend of the first one
>> - so that not both can confirm.
>>
>> I certainly don't like press making this sound like a problem in the
>> Bitcoin protocol or clients. I think this is an issue that needs to
>be
>> solved at the layer above - the infrastructure building on the
>Bitcoin
>> system. Despite that, I do think that we (as a community, not just
>> developers) can benefit from defining a standard way to identify
>> transactions unambiguously. This is something Mark Karpeles suggested
>> a few days ago, and my proposal is this:
>>
>> We define the normalized transaction id as SHA256^2(normalized_tx +
>> 0x01000000), where normalized_tx is the transaction with all input
>> scripts replaced by empty scripts. This is exactly what would be
>> signed inside transaction signatures using SIGHASH_ALL (except not
>> substituting the previous scriptPubKey to be signed, and not dealing
>> with the input being signed specially). An implementation is here:
>> https://github.com/sipa/bitcoin/commits/normtxid.
>>
>> Note that this is not a solution for all problems related to
>> malleability, but maybe it can make people more aware of it, in
>> tangible way.
>>
>> --
>> Pieter
>>
>>
>------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common
>Pitfalls.
>> Read the Whitepaper.
>>
>http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>------------------------------------------------------------------------------
>Managing the Performance of Cloud-Based Applications
>Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>Read the Whitepaper.
>http://pubads.g.doubleclick.net/gampad/clk?id=121051231&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/20140210/7dc4dfba/attachment.html>

2023-06-07 15:04:31

- reply

📅 Original date posted:2013-07-09
📝 Original message:Not any more than sourceforge or github.. None of these solutions are replacements, but rather only supplements to self hosted files.
Jeff Garzik <jgarzik at bitpay.com> wrote:
>On Tue, Jul 9, 2013 at 11:32 AM, Nick Simpson <nick at mynicknet.com>
>wrote:
>> What about something like Cloudflare? Transparent to most and it'd
>help with
>> your bandwidth issues.
>
>Cloudflare is rapidly becoming a bitcoin community SPOF.
>--
>Jeff Garzik
>Senior Software Engineer and open source evangelist
>BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130709/0d8c3822/attachment.html>

2023-06-07 15:04:30

- reply

📅 Original date posted:2013-07-09
📝 Original message:What about something like Cloudflare? Transparent to most and it'd help with your bandwidth issues.
Mike Hearn <mike at plan99.net> wrote:
>That's true - we could serve new users off our own servers and auto
>updates
>off SF.net mirrors, potentially.
>
>
>On Tue, Jul 9, 2013 at 4:57 PM, Daniel F <nanotube at gmail.com> wrote:
>
>> on 07/09/2013 10:28 AM Mike Hearn said the following:
>> > SourceForge has a horrible UI and blocks some countries. It also
>exposes
>> > us to a large and potentially hackable mirror network. Whilst we're
>not
>> > bandwidth constrained on our own servers, let's try and keep using
>them.
>>
>> the point was just that "if need be" free capacity is available
>without
>> having to throw money at it. until there's no need, doesn't matter.
>>
>> also hackability (and ui) should be irrelevant for the autoupdate
>> process (which i presume will do all kinds of checksum and sig
>> verification). and it's likely the autoupdates that will create very
>> lumpy download demand.
>>
>>
>>
>>
>------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from
>AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>See everything from the browser to the database with AppDynamics
>Get end-to-end visibility with application monitoring from AppDynamics
>Isolate bottlenecks and diagnose root cause in seconds.
>Start your free trial of AppDynamics Pro today!
>http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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/20130709/c84812b7/attachment.html>

2023-06-07 15:04:30

- reply