Re: [Bitcoin-development] Block Size Increase

2015-05-13 Thread Angel Leon
 Personally, for privacy reasons I do not want to leave a footprint in the
blockchain for each pizza. And  why should this expense be good for trivial
things of everyday life?

Then what's the point?
Isn't this supposed to be an Open transactional network, it doesn't matter
if you don't want that, what matters is what people want to do with it, and
there's nothing you can do to stop someone from opening a wallet and buying
a pizza with it, except the core of the problem you ask yourself about,
which is, the minute this goes mainstream and people get their wallets out
the whole thing will collapse, regardless of what you want the blockchain
for.

Why talk about the billions of unbanked and all the romantic vision if you
can't let them use their money however they want in a decentralized
fashion. Otherwise let's just go back to centralized banking because the
minute you want to put things off chain, you need an organization that will
need to respond to government regulation and that's the end for the
billions of unbanked to be part of the network.


http://twitter.com/gubatron

On Wed, May 13, 2015 at 6:37 AM, Oliver Egginger bitc...@olivere.de wrote:

 08.05.2015 at 5:49 Jeff Garzik wrote:
  To repeat, the very first point in my email reply was: Agree that 7 tps
  is too low

 For interbank trading that would maybe enough but I don't know.

 I'm not a developer but as a (former) user and computer scientist I'm
 also asking myself what is the core of the problem? Personally, for
 privacy reasons I do not want to leave a footprint in the blockchain for
 each pizza. And why should this expense be good for trivial things of
 everyday life?

 If one encounters the block boundary, he or she will do more effort or
 give up. I'm thinking most people will give up because their
 transactions are not really economical. It is much better for them to
 use third-partys (or another payment system).

 And that's where we are at the heart of the problem. The Bitcoin
 third-party economy. With few exceptions this is pure horror. More worse
 than any used car dealer. And the community just waits that things get
 better. But that will never happen of its own accord. We are living in a
 Wild West Town. So we need a Sheriff and many other things.

 We need a small but good functioning economy around the blockchain. To
 create one, we have to accept a few unpleasant truths. I do not know if
 the community is ready for it.

 Nevertheless, I know that some companies do a good job. But they have to
 prevail against their dishonest competitors.

 People take advantage of the blockchain, because they no longer trust
 anyone. But this will not scale in the long run.

 - oliver









 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-19 Thread Angel Leon
I strongly suggest you take a look at swig for doing this. It's very
straightforward generating bindings in an automated fashion with it.
http://www.swig.org/

You could probably  have it done in one or two days with Swig.

Once you do the Java bindings with it, it'll be a few adjustments and
you'll have bindings for other languages as well.

http://twitter.com/gubatron

On Thu, Feb 19, 2015 at 4:43 PM, Sean Gilligan s...@msgilligan.com wrote:

 On 2/19/15 9:30 AM, Mike Hearn wrote:
 
  Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as
  well as dialects of Haskell, Lisp, Smalltalk and a bunch of more
  obscure languages like Scala, Kotlin, Ceylon, etc.
 
  It makes more sense to talk about bindings to particular runtimes
  these days, rather than particular languages.

 I'm definitely interested in helping to create and test JVM bindings.
 Where should such a project be launched? As a subproject of bitcoinj?




 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-01-31 Thread Angel Leon
My concerns come from 2 projects that could easily raise the current
transaction volume 10x daily in the short term,  perhaps even 100x a year
from now after the media blows it out.

Think legal bittorrent file sales: ebooks, indie music (albums and
singles), films, art, stock photography.

Think p2p amazon (OpenBazaar) and how that could grow exponentially in
terms of transactional volume when ecommerce penetrates geos currently
underserved.

Thanks for your explanations. it seems as of now we must rely on the likes
of centralized solutions like Bitpay, Coinbase to manage the transactional
volume we expect, or just wait for the technology to be ready finally
handle it in a real p2p fashion, no intermediaries.



On Sat, Jan 31, 2015, 6:04 PM Mike Hearn m...@plan99.net wrote:

 Alipay handled up to 2.85 million transactions per minute, and 54 percent
 of its transactions are made via mobile device.


 I know China is a very big place but even so - 47,500 transactions per
 second would be almost quintiple what Visa handles across the entire world.
 With only 300 million users and primarily online usage (?) this claim feels
 a little suspect to me.

 Given the wording up to 2.85 million I wonder if that is some freak
 spike caused by people's behaviour being synchronised externally (e.g. a
 fixed start time for the sale that people are waiting for). It's hard to
 imagine that they sustained anything close to that for the entire day.

 So this is really a discussion about peak performance.

 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?


 There's a discussion of such things here that might be useful:

 https://en.bitcoin.it/wiki/Scalability

 It discusses various optimisations, like not actually sending tx data
 twice.

 I wouldn't worry about it too much. It took decades for Visa to even
 approach 10,000 txns/sec. PayPal, I believe, still only handles a few
 hundred. And those services had the benefits of minimal competition,
 working in people's local currencies, integrated dispute mediation and not
 representing any real threat to the political status quo. Bitcoin isn't
 going to be needing to handle Alipay's level of traffic any time soon.

 Frankly, scaling is a nice problem to have, it means you're popular. It'd
 be a mistake to just blindly assume Bitcoin will take over the world.
 Growing market share is difficult. Worry more about how to get 300 million
 crazy users than the precise broadcast protocol that'd be needed to handle
 them ;)

--
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


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

2015-01-30 Thread Angel Leon
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-01-28 Thread Angel Leon
why not allow both serializations and keep serialization format a
parameter, keep everyone happy.

http://twitter.com/gubatron

On Wed, Jan 28, 2015 at 12:14 PM, Mike Hearn m...@plan99.net wrote:

 I think we'll just have to agree to disagree on this one. I've implemented
 BIP70 a couple of times now and didn't find it to be difficult. I know you
 had odd problems with the C# protobuf implementation you were using but
 library bugs can happen for any kind of programming.

 I forgot to mention the other reason it's done this way. One of the
 driving goals of BIP70 was to support the TREZOR and similar devices. For
 hardware wallets, it's critical to keep the amount of code they need to run
 as small as possible. Any bugs in the code there can cause security holes
 and lead to the device being hacked.

 Doing it the way you suggest would mean the secure code would have to
 contain complex and bug-prone text parsing logic as well as a full blown
 HTTP and SSL stack, that requires not only X.509 handling but also lots of
 other stuff on top. It'd increase cost, complexity and decrease security
 quite a bit.

 Whilst I appreciate if your platform provides a scripting-like API and
 nothing low level it might seem easier to use JSON+HTTPS, that isn't the
 case for one of the primary design targets.



 On Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier nicolas.dor...@gmail.com
 wrote:

 Mike, I am not denying it is impossible to do all of that.
 Just that it is not a trivial stuff to do to make it works everywhere,
 and I think that it is not a good thing for a client side technology.
 BIP70 has its use, and I understand why there is case where it is good to
 ship the certs in the message and not depends on the transport.

 But a standard that just use JSON and HTTPS, even if less flexible that
 BIP70, would make it easier and sufficient for today's use case.

 On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn m...@plan99.net wrote:

 My point is not that there is a limitation in BIP70. My point is that
 you put the burden of certificate verification on developer's shoulder when
 we can just leverage built in HTTPS support of the platform.


 Platforms that support HTTPS but not certificate handling are rare - I
 know HTML5 is such a platform but such apps are inherently dependent on the
 server anyway and the server can just do the parsing and validation work
 itself. If WinRT is such a platform, OK, too bad.

 The embedding of the certificates is not arbitrary or pointless, by the
 way. It's there for a very good reason - it makes the signed payment
 request verifiable by third parties. Effectively you can store the signed
 message and present it later to someone else, it's undeniable. Combined
 with the transactions and merkle branches linking them to the block chain,
 what you have is a form of digital receipt ... a proof of purchase that can
 be automatically verified as legitimate. This has all kinds of use cases.

 Because of how HTTPS works, you can't easily prove to a third party that
 a server gave you a piece of data. Doing so requires staggeringly complex
 hacks (see tls notary) and when we designed BIP70, those hacks didn't even
 exist. So we'd lose the benefit of having a digitally signed request.

 Additionally, doing things this way means BIP70 requests can be signed
 by things which are not HTTPS servers. For example you can sign with an
 email address cert, an EV certificate i.e. a company, a certificate issued
 by some user forum, whatever else we end up wanting. Not every payment
 recipient can be identified by a domain name + dynamic session.


 However, if you want to use your plateform's store, then you are toasted


 That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
 Windows and Mac certificate stores all using the same code or very minor
 variants on it (e.g. on Mac you have to specify you want the system store
 but it's a one-liner).

 Yes, that's not *every* platform. Some will require custom binding glue
 and it depends what abstractions and languages you are using.


 Have you tried to do that on windows RT and IOS ? I tried, and I
 quickly stopped doing that since it is not worth the effort. (Frankly I am
 not even sure you can on win rt, since the API is a stripped down version
 of windows)


 There is code to do iOS using the Apple APIs here:


 https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391


 Why have you not heard about the problem ? (until now, because I have
 this problem because I need to have the same codebase on
 winrt/win/android/ios/tablets)


 WinRT is a minority platform in the extreme, and all the other platforms
 you mentioned have the necessary APIs. Java abstracts you from them. So I
 think you are encountering this problem because you desire to target WinRT
 and other platforms with a single codebase. That's an unusual constraint.

 AFAIK the only other people who encountered this are BitPay, because
 they want to 

Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Angel Leon
-1

http://twitter.com/gubatron


On Tue, Aug 19, 2014 at 11:44 AM, Bryan Bishop kanz...@gmail.com wrote:

 On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik jgar...@bitpay.com wrote:
  As a first step, one possibility is putting the primary repo on
  bitcoin.org somewhere, and simply mirroring that to github for each
  push.

 Smaller first step would be to mirror the git repository on
 bitcoin.org, which is necessary anyway before switching primaries.

 - Bryan
 http://heybryan.org/
 1 512 203 0507


 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Building from git on OSX

2014-07-03 Thread Angel Leon
a million thanks for this FYI

http://twitter.com/gubatron


On Thu, Jul 3, 2014 at 11:56 AM, Gavin Andresen gavinandre...@gmail.com
wrote:

 Just FYI for anybody else building on OSX:

 libtool is a new dependency, so if you update to git HEAD and have trouble
 building:

 brew install libtool
   (or port install libtool -- see doc/build-osx.md for all the
 dependencies)
 ./autogen.sh
 ./configure   etc, whatever configure options you use. I develop with:
 ./configure --disable-hardening --disable-silent-rules CXXFLAGS='-g3 -O0
 -DDEBUG_LOCKORDER'



 --
 --
 Gavin Andresen


 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] have there been complains about network congestion? (router crashes, slow internet when running Bitcoin nodes)

2014-04-08 Thread Angel Leon
I was wondering if the level of traffic a Bitcoin node gets is or will be
so high that you have heard/will hear complains like the following:


   1. a home router that crashes or slows down when its NAT pin-hole table
   overflows, triggered by many TCP connections.
   2. a home router that crashes or slows down by UDP traffic
   3. a home DSL or cable modem having its send buffer filled up by
   outgoing data, and the buffer fits seconds worth of bytes. This adds
   seconds of delay on interactive traffic. For a web site that needs 10 round
   trips to load this may mean 10s of seconds of delay to load compared to
   without bittorrent. Skype or other delay sensitive applications would be
   affected even more.

These are issues the bittorrent community faced and eventually solved
brilliantly with uTP, which uses a congestion window algorithm that allows
you to use as much of the TCP bandwidth as possible and automatically
throttling down if there's any cross traffic, while also taking into
consideration things like the optimum MTUs (Path MTU discovery), Clock
Drift phenomena and other features.

I was wondering if we have or expect to have these issues in the future,
perhaps uTP could help greatly the performance of the entire network at
some point.

Detailed information about uTP here
http://www.libtorrent.org/utp.html

@gubatron
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] have there been complains about network congestion? (router crashes, slow internet when running Bitcoin nodes)

2014-04-08 Thread Angel Leon
Those clarifications are what I needed to hear. For some reason I started
thinking about this last night and wanted to bring it up just in case it
would help, but def. not necessary. Will get back to more low hanging fruit
in the UI/UX as I get to know the project more.

Gregory: But there doesn't have to be and shouldn't just be one
network transport
for Bitcoin.
is there a formal abstraction for a Transport layer? I suppose if there
isn't it'll be there when needed.

Thanks!

http://twitter.com/gubatron


On Tue, Apr 8, 2014 at 12:48 PM, Wladimir laa...@gmail.com wrote:


 On Tue, Apr 8, 2014 at 6:13 PM, Angel Leon gubat...@gmail.com wrote:

 I was wondering if the level of traffic a Bitcoin node gets is or will be
 so high that you have heard/will hear complains like the following:


1. a home router that crashes or slows down when its NAT pin-hole
table overflows, triggered by many TCP connections.


 The default maximum amount of connections is 125, which only happens if
 you have a stable node that accepts incoming connections. The maximum
 number of outgoing connections is always 8.
 Should be no problem even for cheapass routers.


1. a home router that crashes or slows down by UDP traffic

 N/A - We don't use UDP


1. a home DSL or cable modem having its send buffer filled up by
outgoing data, and the buffer fits seconds worth of bytes. This adds
seconds of delay on interactive traffic. For a web site that needs 10 
 round
trips to load this may mean 10s of seconds of delay to load compared to
without bittorrent. Skype or other delay sensitive applications would be
affected even more.

 Filling up the send buffer is certainly possible.
 Adding throttling wouldn't be horribly hard, but this is postponed until
 parallel block download is implemented, so that other peers will not get
 stuck on your throttled node.


1.

 I was wondering if we have or expect to have these issues in the future,
 perhaps uTP could help greatly the performance of the entire network at
 some point.


 There is enough lower-hanging fruit left.

 If you're interested in speeding up the performance I think it's important
 to start with benchmarking and analysis to find out where the pain points
 are.

 Wladimir


--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [QT] how to disable block verification for faster UI testing?

2014-03-19 Thread Angel Leon
the command line options mention a -checklevel  parameter.
I've been passing 0 assuming there'd be little to no verification, but it's
happened a few times that when I open the official binary (while not doing
development) there's some sort of database corruption and Bitcoin-Qt needs
to reindex blocks on disk, a process that can take probably a whole day.

how do you guys develop the UI and avoid these issues?

Cheers,
Angel

http://twitter.com/gubatron
--
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/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [QT] how to disable block verification for faster UI testing?

2014-03-19 Thread Angel Leon
If you have database problems are you perhaps switching between 0.8.x and
0.9.x with the same directory?
I think that may have been the issue.

Maybe now that I have a 0.9.0 official binary, when I switch to the source
builds I won't have the issue.

However, I think I'll do what you do and have separate bitcoin data
directories, that's probably the best.

not trying to test anything specifically, just codign, building, launching
over and over, would like to make the startup of the Qt client faster.

http://twitter.com/gubatron


On Wed, Mar 19, 2014 at 2:22 PM, Wladimir laa...@gmail.com wrote:


 On Wed, Mar 19, 2014 at 6:27 PM, Angel Leon gubat...@gmail.com wrote:

 the command line options mention a -checklevel  parameter.
 I've been passing 0 assuming there'd be little to no verification, but
 it's happened a few times that when I open the official binary (while not
 doing development) there's some sort of database corruption and Bitcoin-Qt
 needs to reindex blocks on disk, a process that can take probably a whole
 day.

 how do you guys develop the UI and avoid these issues?


 In general I do very little with the database while developing the UI. I
 have various seperate bitcoin data directories (both testnet and mainnet)
 to try things out. Before doing something risky I just make a copy.

 These days I also do a lot of development with -regtest, as it allows
 quickly setting up test scenarios.

 What are you trying to test specifically? The progress bar while
 reindexing?

 If you have database problems are you perhaps switching between 0.8.x and
 0.9.x with the same directory? In that case see the downgrading warning
 here: https://bitcoin.org/bin/0.9.0/README.txt .

 Wladimir


--
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/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development