Re: [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?

[Nick Simpson]

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"  wrote:

> On the Chinese "Single's Day" (sort of like the american Black Friday)
> according to MIT's Tech Review
> 
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper

[Nick Simpson]

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  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@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
"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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] DNS seeds unstable

[Nick Simpson]

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  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@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
"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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Malleability and MtGox's announcement

[Nick Simpson]

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  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 +
>> 0x0100), 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 dea

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Nick Simpson]

Not any more than sourceforge or github.. None of these solutions are 
replacements, but rather only supplements to self hosted files.

Jeff Garzik  wrote:
>On Tue, Jul 9, 2013 at 11:32 AM, Nick Simpson 
>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/
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Nick Simpson]

What about something like Cloudflare? Transparent to most and it'd help with 
your bandwidth issues.


Mike Hearn  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  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@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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development