Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 12:47 PM, Adam Weiss a...@signal11.com wrote:

 Hi Warren,

 If you set dmarc_moderation_action to Munge from, the list will detect
 when someone posts from a domain that publishes a request for strict
 signature checking for all mails originating from it (in DNS) and rewrite
 the envelope-from to the list's address.  Reply-to will be added and set to
 the original sender.


That seems to change Reply behavior for those recipients?  It would seem to
accidentally direct mail intended to DKIM-user + list to DKIM-user.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Jeff Garzik
 their transactions could be for the
  80% to not build on blocks containing doublespends by the 20%. There's
  no way in a decentralized network to come to consensus about what
  transactions are or are not valid without mining itself, so you could
  end up in a situation where unless you're part of one of the big pools
  you can't reliably mine at all because your blocks may get rejected for
  containing doublespends.
 
  One of my goal with standard replace-by-fee is to prevent this scenario
  by forcing merchants and others to implement ways of accepting zeroconf
  transactions safely that work in a decentralized environment regardless
  of what miners do; we have a stronger and safer Bitcoin ecosystem if
  we're relying on math rather than trust to secure our zeroconf
  transactions. We're also being more honest to users, who right now often
  have the very wrong impression that unconfirmed transactions are safe to
  accept - this does get people ripped off all too often!
 
 
  Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
  waiting to get some feedback:
 
  https://github.com/bitcoin/bitcoin/pull/6176
 
  Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
  working on porting it to v0.10.2, and once that's done I'm going to put
  up a bounty for anyone who can find a DoS attack in the patch. If no-one
  claims the bounty after a week or two I think I'll start feeling
  confident about using it in production.
 
 
  --
  'peter'[:-1]@petertodd.org
  03188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
 
 
 --
 
  ___
  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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd p...@petertodd.org wrote:

 Having said that... honestly, zeroconf is pretty broken already. Only
 with pretty heroic measures like connecting to a significant fraction of
 the Bitcoin network at once, as well as connecting to getblocktemplate
 supporting miners to figure out what transactions are being mined, are
 services having any hope of avoiding getting ripped off. For the average
 user their wallets do a terrible job of showing whether or not an


This is no excuse for further degrading the overall network security.

There are many issues to address in the bitcoin ecosystem.  It negatively
impacts users to roll out scorched earth replace-by-fee given today's
ecosystem.

Yes, zero conf security is poor.  An outright attack on zero conf degrades
user security even more.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Jeff Garzik
?
 ---

 First get the full-RBF patch to v0.10.2:

 https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2

 The above implementation of RBF includes additional code to find and
 preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
 Secondly, try out my replace-by-fee-tools at:

 https://github.com/petertodd/replace-by-fee-tools

 You can watch double-spends on the network here:

 http://respends.thinlink.com/


 References
 --

 1) Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
 variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet,
Peter Todd, May 23rd 2015, Bitcoin-development mailing list,

 http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html

 2) From Zero to Hero: Bitcoin Transactions in 8 Seconds,
June 2nd, 2014, Erik Voorhees,

 https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734

 3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations

 4) Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network,
March 14th 2015, Grace Caffyn, Coindesk,

 http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/

 5) First-Seen-Safe Replace-by-Fee,
May 25th 2015, Peter Todd, Bitcoin-development mailing list,

 http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html

 6) Cost savings by using replace-by-fee, 30-90%,
May 25th 2015, Peter Todd, Bitcoin-development mailing list,

 http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html

 7) Tampering with the Delivery of Blocks and Transactions in Bitcoin,
 Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan
 Capkun,
 Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
 http://eprint.iacr.org/2015/578

 --
 'peter'[:-1]@petertodd.org
 070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad


 --

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 9:44 AM, justusranv...@riseup.net wrote:

 If we have ECDSA proof that an entity intentionally made and publicly
 announced incompatible promises regarding the disposition of particular
 Bitcoins under their control, then why shouldn't that be assumed to be a
 fraud attempt unless shown otherwise?


Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 10:48 AM, justusranv...@riseup.net wrote:

 On 2015-06-19 17:40, Jeff Garzik wrote:

 Making multiple incompatible versions of a spend is a -requirement- of
 various refund contract protocols.


 Is there not a dedicated field in a transaction (nSequence) for express
 purpose of indicating when a protocol like this is in use?


No.  You cannot know which is the 'right' or wrong transaction.  One tx has
obvious nSequence adjustments, the other - the refund transaction - may not.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Jeff Garzik
On Thu, Jun 18, 2015 at 9:07 AM, justusranv...@riseup.net wrote:

 On 2015-06-18 14:53, Jeff Garzik wrote:

 Consensus changes - worded another way - change Bitcoin's Constitution -
 The Rules that everyone in the system is -forced- to follow, or be ignored
 by the system.


 Bitcoin does not and can not function as a set of rules imposed by some
 people onto other people.


This is an engineering list.  The quote precisely describes how the bitcoin
consensus system functions.

Users' choice is largely binary:  Follow the rules, or bitcoin software
ignores you.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] FYI - Mailing List Move Preparations

2015-06-18 Thread Jeff Garzik
Thanks for setting this up, Warren!


On Thu, Jun 18, 2015 at 9:57 PM, Warren Togami Jr. wtog...@gmail.com
wrote:

 After discussions in #bitcoin-dev in the past day we decided it would be a
 bad idea to link the old and new lists in some way during a transition
 period.  We decided we are better off announcing the switchover very soon,
 and after that point all posts to the old list will be rejected with a
 message telling them where to find the new list.

 The proposed switchover will be on Tuesday, June 23rd, 2015.  We will know
 an exact scheduled time for the move probably tomorrow.  At the time of the
 switchover, the old list will reject all messages, archives will be
 exported and imported into the new list server, then the new list will be
 opened.

 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 Please subscribe now and feel free to make test posts.  We are testing
 configuration options to fix some long standing spam filter-related
 issues.  Any posts to the new list prior to the final switchover will be
 wiped from the archives.

 If you have opinions on this, please join us in Freenode #bitcoin-dev and
 talk to warren.

 Warren Togami


 --

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Jeff Garzik
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach m...@friedenbach.org
wrote:

 On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote:


 The whole point is getting out in front of the need, to prevent
 significant negative impact to users when blocks are consistently full.

 To do that, you need to (a) plan forward, in order to (b) set a hard fork
 date in the future.


 Or alternatively, fix the reasons why users would have negative
 experiences with full blocks, chiefly:

   * Get safe forms of replace-by-fee and child-pays-for-parent finished
 and in 0.12.
   * Develop cross-platform libraries for managing micropayment channels,
 and get wallet authors to adopt
   * Use fidelity bonds, solvency proofs, and other tricks to minimize the
 risk of already deployed off-chain solutions as an interim measure until:
   * Deploy soft-fork changes for truly scalable solutions like Lightning
 Network.

 Not raising the block size limit does not mean doing nothing to solve the
 problem.


This is a long, unreasonable list of work.  None of this exists and it
equates to upgrade all wallets and websites everywhere  It requires all
exchanges, payment processors, merchants, etc. to  - basically everybody
but miners - to update.

It is a far, far larger amount of work to write, test and deploy than
simply increasing the block size limit.

Think through roll-out of these ambitious suggestions, before suggesting as
an alternative!

Not a realistic alternative except in an alternate universe where (a)
developer work at all companies is cost free, plus (b) we can pause the
business universe while we wait for The Perfect Solution.










-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-14 Thread Jeff Garzik
Exactly -- both block size proponents and block size change conservatives
seem to be glossing over this aspect - much to my dismay.

Choosing the size limit is choosing the size of a scarce resource.  By fiat.

It is wrong to think that a technical consensus can choose what is best
here.

The block size limit defines the scope of a resource for which all fee
market actors bid.  That, in turn, defines who is in the fee market and how
they behave, what market choices are made.

It doesn't matter how or why the limit was originally enacted, what Satoshi
meant to do.  What matters, economically, is what is.  What the software
and our $3B economy  market knows and sees today.  (I think some block
size change proponents miss this!)

The solution lies in transitioning this size limit to the free market.  In
the end, the users must choose their desired level of growth,
decentralization, etc.  We cannot rely on some dev's idea of the proper
level of fee, proper level of growth, proper level of decentralization.

And IMO, a floating limit with training wheels is better and stronger for
bitcoin's health from a governance, user choice and free market perspective
than simply hard fork to 2MB, come back again in 6 months.







On Sun, Jun 14, 2015 at 6:34 AM, Benjamin benjamin.l.cor...@gmail.com
wrote:

 The size limit is an economic policy lever that needs to be
 transitioned -away- from software and software developers, to the free
 market.

 Exactly right. Bitcoin does not have a free market for fee though, and
 literally all the discussion so far has neglected some fundamental
 aspect of this, as you described. It's not at all a technical or
 engineering decision. It's the question of how to potentially
 re-design a fundamental part of Bitcoin, and the proposals so far
 don't address this. What is the price of the scarce resource of the
 blockchain and the mechanism to decide on price, once the subsidy runs
 out?

 On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson m...@henricson.se
 wrote:
  Jeff,
 
  with all due respect, but I've seen you saying this a few times
  now, that this decision is oh so difficult and important.
 
  But this is not helpful. We all know that. Even I.
 
  Make a suggestion, or stay out of the debate!
 
  Mats
 
  On 06/14/2015 07:36 AM, Jeff Garzik wrote:
  The choice is very real and on-point.  What should the block size limit
  be?  Why?
 
  There is a large consensus that it needs increasing.  To what?  By what
  factor?
 
  The size limit literally defines the fee market, the whole damn thing.
 If
  software high priests choose a size limit of 300k, space is scarce, fees
  are bid high.  If software high priests choose a size limit of 32mb,
 space
  is plentiful, fees are near zero.  Market actors take their signals
  accordingly.  Some business models boom, some business models fail, as a
  direct result of changing this unintentionally-added speedbump.
 Different
  users value adoption, decentralization etc. differently.
 
  The size limit is an economic policy lever that needs to be transitioned
  -away- from software and software developers, to the free market.
 
  A simple, e.g. hard fork to 2MB or 4MB does not fix higher level
 governance
  problems associated with actors lobbying developers, even if a
 cloistered
  and vetted Technical Advisory Board as has been proposed.
 
 
 
 
 
 
 
  On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com
 wrote:
 
  I definitely think we need some voting system for metaconsensus…but if
  we’re going to seriously consider this we should look at the problem
 much
  more generally. Using false choices doesn’t really help, though ;)
 
  - Eric Lombrozo
 
 
  On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote:
 
  On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com
  wrote:
 
  2) BIP100 has direct economic consequences…and particularly for
 miners.
  It lends itself to much greater corruptibility.
 
 
  What is the alternative?  Have a Chief Scientist or Technical Advisory
  Board choose what is a proper fee, what is a proper level of
  decentralization, a proper growth factor?
 
 
 
 
 
 
 
 
 --
 
 
 
  ___
  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


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

Re: [Bitcoin-development] comments on BIP 100

2015-06-14 Thread Jeff Garzik
Adding - in re pay-to-FOO - these schemes are inherently short term, such
that it is near-impossible for the market to plan for what happens in 12+
months.

On Sun, Jun 14, 2015 at 10:28 PM, Jeff Garzik jgar...@bitpay.com wrote:

 On Sun, Jun 14, 2015 at 5:23 PM, Adam Back a...@cypherspace.org wrote:

 Hi

 I made these comments elsewhere, but I think really we should be
 having these kind of conversations here rather than scattered around.

 These are about Jeff Garzik's outline draft BIP 100 I guess this is
 the latest draft:  (One good thing about getting off SF would be
 finally JGarzik's emails actually not getting blocked!).

 http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

 may have changed since the original [1]

 Over the original proposal:

 1. there should be a hard cap, not indefinitely growing.


 In the latest draft there is an explicit 32MB ceiling now.

 Users will need to opt into growth beyond 32MB via a 2nd hard fork.



 2. there should be  a growth limiter (no more than X%/year)


 As a general principle, this is an area of market disagreement, and should
 not be our call.  Encoding this into software veers into personal opinion
 about what economic policy should be.

 That said  -- BIP 100, as a compromise, includes a growth limiter.  Abrupt
 change (1MB - 32MB!) is awful on markets.  Good policies include a
 measured pace of transition from policy A to policy B.  It gives the
 community time to assess system effectiveness - while also allowing free
 market input.

 In the long run I hope the cap is removed (see below), and the intention
 is to -slowly- and -transparently- move from the tightly controlled limit
 to something the free market and users are choosing.




 3. I think the miners should not be given a vote that has no costs to
 cast, because their interests are not necessarily aligned with users
 or businesses.

 I think Greg Maxwell's difficulty adjust [2] is better here for that
 reason.  It puts quadratic cost via higher difficulty for miners to
 vote to increase block-size, which miners can profitably do if there
 are transactions with fees available to justify it. There is also the
 growth limiter as part of Greg's proposal. [3]


 paying with difficulty has severe negative elements that will likely
 cause it never to be used:
 - complex and difficult for miners to reason
 - fails the opportunity cost test - dollar cost lost losing the block race
 versus value gained by increasing block size
 - inherently unpredictable in the short term - user experience is that
 it's possibly difficult to see a gain in utility versus the revenue you are
 giving up
 - REQUIRES informal miner collusion - probably less transparent than BIP
 100 - in order to solve the who-goes-first problem.
 - net result: tough sell

 Paying bitcoins to future miners makes a lot more sense.  Initially I was
 a fan of pay-with-diff, but freezing bitcoins (CLTV) or timelock'd
 anyone-can-spend has much more clear incentives, if you want to go down
 that road.

 Problems with pay-to-increase-block-size:
 - how much to pay?  You are inherently setting your growth policy on top
 of bitcoin by choosing a price here.
 - another who-goes-first problem

 Anyway, there is a natural equilibrium block size that the free market and
 user choice will seek.

 Related:  There is a lot of naive miner = max income = max block size
 reasoning going on, with regards to fees.  This is defining the bounds of
 an economically scarce resource.  There are many reasons why a miner will
 today, in the real world, limit their block size. WRT fee income, if block
 size is too large the fee competition in the overall market is low-to-zero,
 fee income rapidly collapses.  Then factor in price and demand elasticity
 on top of that.

 Quite frankly, there seems to be a natural block size equilibrium ceiling,
 and I worry about miners squeezing the market by maximizing their fee
 income through constrained block sizes and competition at the low end.
 This is of course already possible today - miners may openly or covertly
 collude to keep the block size low.














 I think bitcoin will have to involve layering models that uplift
 security to higher layers, but preserve security assurances, and
 smart-contracts even, with protocols that improve the algorithmic
 complexity beyond O(n^2) in users, like lightning, and there are
 multiple other candidates with useful tradeoffs for various use-cases.

 One thing that is concerning is that few in industry seem inclined to
 take any development initiatives or even integrate a library.  I
 suppose eventually that problem would self-correct as new startups
 would make a more scalable wallet and services that are layer2 aware
 and eat the lunch of the laggards.  But it will be helpful if we
 expose companies to the back-pressure actually implied by an O(n^2)
 scaling protocol and don't just immediately increase the block-size to
 levels that are dangerous

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote:

 2) BIP100 has direct economic consequences…and particularly for miners. It
 lends itself to much greater corruptibility.


What is the alternative?  Have a Chief Scientist or Technical Advisory
Board choose what is a proper fee, what is a proper level of
decentralization, a proper growth factor?


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang 1240...@gmail.com wrote:

 To tell you the truth. It is only because most miners are not located
 in the West. If Slush, Eligius and BTC Guild still on top 3, the core
 developers, including brain-dead Mike Hearn, would be very happy to do
 BIP100 just like they did BIP34 and BIP66. Shame on you!


BIP 100 requires a hard fork to engage.  Users proactively opt-in.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
The choice is very real and on-point.  What should the block size limit
be?  Why?

There is a large consensus that it needs increasing.  To what?  By what
factor?

The size limit literally defines the fee market, the whole damn thing.  If
software high priests choose a size limit of 300k, space is scarce, fees
are bid high.  If software high priests choose a size limit of 32mb, space
is plentiful, fees are near zero.  Market actors take their signals
accordingly.  Some business models boom, some business models fail, as a
direct result of changing this unintentionally-added speedbump.  Different
users value adoption, decentralization etc. differently.

The size limit is an economic policy lever that needs to be transitioned
-away- from software and software developers, to the free market.

A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
problems associated with actors lobbying developers, even if a cloistered
and vetted Technical Advisory Board as has been proposed.







On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote:

 I definitely think we need some voting system for metaconsensus…but if
 we’re going to seriously consider this we should look at the problem much
 more generally. Using false choices doesn’t really help, though ;)

 - Eric Lombrozo


 On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote:

 On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com
 wrote:

 2) BIP100 has direct economic consequences…and particularly for miners.
 It lends itself to much greater corruptibility.


 What is the alternative?  Have a Chief Scientist or Technical Advisory
 Board choose what is a proper fee, what is a proper level of
 decentralization, a proper growth factor?





-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
Miner voting, while imperfect, is the least-worst of various solutions
which inject market input into the system.  It is is known quantity, field
tested, and must be sustained, in public, over a time span of months.  As
this thread shows, stakeholder and direct user voting is nigh impossible to
get right.

Choosing block size is fundamentally a central bank directive shaping the
fee market.  Whatever actor or algorithm or natural equilibrium picks the
block size, that choice will dictate the level of competition for fees, the
level of scarcity of an economically scarce resource.  Picking the block
size advantages some businesses over others, some business models over
others.  Software (and software devs) should not be the ones picking that
limit.

Checks-and-balances are also important.  BIP 100 notably includes two steps
at which user input is visibly and actively injected:   1) hard fork to
enable, and 2) a second hard fork if the system is to scale beyond 32MB.
The network users (not miners) twice approve the system.  Further, one must
remember all the basic miner incentives that do align with users, notably
that of maintaining the value of bitcoin tokens as their primary income
stream.


















On Sun, Jun 14, 2015 at 12:16 AM, Stephen stephencalebmo...@gmail.com
wrote:

 While this idea is theoretically interesting because it involves many
 stakeholders, rather than just miners, I think in practice this would not
 work very well. Users don't want to worry about this kind of technicality,
 they just want to be able to make a transaction and have it be processed.

 In addition, while this gives stakeholders some weight with the fees they
 supply, these fees are marginal compared to the block size subsidy. If this
 proposal were actually implemented, I think miners would vote for whatever
 they think is best, and users would not contradict them with their votes to
 ensure a fast confirmation time. Users are incentivized to be in agreement
 with miners because the miners provide them with the confirmations they
 need, but fees do not provide a great incentive for miners to be in
 agreement with users, and likely won't for some time.

 Best,
 Stephen




  On Jun 12, 2015, at 2:11 PM, Peter Todd p...@petertodd.org wrote:
 
  Jeff Garzik recently proposed that the upper blocksize limit be removed
  entirely, with a soft limit being enforced via miner vote, recorded by
  hashing power.
 
  This mechanism within the protocol for users to have any influence over
  the miner vote. We can add that back by providing a way for transactions
  themselves to set a flag determining whether or not they can be included
  in a block casting a specific vote.
 
  We can simplify Garzik's vote to say that one of the nVersion bits
  either votes for the blocksize to be increased, or decreased, by some
  fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
  nVersion bit in transactions themselves, also voting for an increase or
  decrease. Transactions may only be included in blocks with an
  indentical vote, thus providing miners with a monetary incentive via
  fees to vote according to user wishes.
 
  Of course, to cast a don't care vote we can either define an
  additional bit, or sign the transaction with both versions. Equally we
  can even have different versions with different fees, broadcast via a
  mechanism such as replace-by-fee.
 
 
  See also John Dillon's proposal for proof-of-stake blocksize voting:
 
 
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
 
  --
  'peter'[:-1]@petertodd.org
  127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
 
 --
  ___
  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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?

2015-06-10 Thread Jeff Garzik
On Wed, Jun 10, 2015 at 11:59 AM, Andy Schroder i...@andyschroder.com
wrote:

  Hello,

 A couple of motivations for a mailing list switch:

1. Sometimes the mailing list delays delivery for 10 minutes to
several days.
2. There are usually lots of ads at the footer of the messages. Really
confuses new readers (for me at least), and seems like it really pollutes
such a historical dialog that may be referenced long into the future. How
would it be if the 10 Commandments, Magna Carta, Bill of Rights, The Sermon
on the Mount, or The Gettysburg Address had ads intertwined within them?
 3. Don't think HTML messages are allowed.
4. Seems like digital signatures are always broken on messages because
the list server slightly modifies them (?), so my e-mail client doesn't
verify them all.

 Not only -- mail header rewrites cause all my emails to go into people's
spam folders, if they were not directly listed in the To/CC headers...





1.



 Andy Schroder

 On 06/10/2015 02:36 PM, s7r wrote:

 The mail list is public, so it's not like the data on it is somehow
 sensitive. Sourcefoge is fine, it has a nice web UI where you can browse
 the message and sort/order them as you want, etc.

 Why would you want to move to a paid solution? And why would you want
 users to have to pay per message? This is the worst idea ever from my
 point of view. We want to encourage people to join the community, run
 full nodes, ask questions, come with solutions, ideas for improvements
 and so on. Everyone should read and write and contribute as much as
 possible with ideas in debates. You never know who can have bright ideas
 in some contexts.

 Bottom line is so far sourceforge handles the mail lists just fine. I
 don't see a single advantage another mail list provider / system could
 offer, except some headache and extra work for migration. The software
 distribution via sourcefoge was cancelled for obvious reasons which I
 fully understand and agree to, but it has nothing to do with the mail
 lists. We have way more important things to brainstorm about.

 On 6/10/2015 7:46 PM, Andy Schroder wrote:

  Regarding changing the e-mail list provider. Is anyone interested in
 sponsoring it? There are non-free options, but it may be difficult to
 always ensure the fee is being paid to the provider. I think finding an
 agreeable free solution may have been the issue before? I've also
 thought of trying to make a pay per message or byte solution (and this
 cost could be dynamic based upon the number of current mailing list
 subscribers). This could solve the who pays problem (the sender pays),
 as well as motivate people to be more concise and clear with their
 messages, and at the same time limit spam.



 Any thoughts?

 Andy Schroder

 On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote:

  On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:

  
 http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/

  All our downloads (even old ones) have recently been deleted from 
 sourceforge, for this reason. They haven't been mentioned in Bitcon Core 
 release announcements for a long time.

 No opinion on the mailing list. Though I think it's less urgent. The issue of 
 moving the mailinglist has come up before a few times and people can't agree 
 where to move to.

 Wladimir


 --

  
 --
 ___
 Bitcoin-development mailing 
 listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Jeff Garzik
That attitude and doxxing is not appropriate for this list.


On Tue, May 26, 2015 at 4:30 PM, joli...@airmail.cc wrote:

 You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
 and you have big banks as clients. Shit like replace-by-fee and leading
 the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Virtual Notary.

2015-05-20 Thread Jeff Garzik
On Wed, May 20, 2015 at 3:25 AM, Emin Gün Sirer el33th4...@gmail.com
wrote:

 Hi everyone,

 Given the recent discussions on projects that use the Bitcoin blockchain
 to record factoids, people on this list might be interested in the Virtual
 Notary project. Virtual Notary is essentially an online witness (aka
 attestor) to online factoids. It can provide:

   * proof of Bitcoin funds (without revealing public addresses or fund
 location on the blockchain)

   * proof of Bitcoin address ownership

   * proof of Tweet



For what it's worth, a subsidiary of Dunvegan Space Systems is pursuing
exactly this as a business.

EMail jgar...@dss.co if you want to know more.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Proposed additional options for pruned nodes

2015-05-12 Thread Jeff Garzik
A general assumption is that you will have a few archive nodes with the
full blockchain, and a majority of nodes are pruned, able to serve only the
tail of the chains.


On Tue, May 12, 2015 at 8:26 AM, gabe appleton gapplet...@gmail.com wrote:

 Hi,

 There's been a lot of talk in the rest of the community about how the 20MB
 step would increase storage needs, and that switching to pruned nodes
 (partially) would reduce network security. I think I may have a solution.

 There could be a hybrid option in nodes. Selecting this would do the
 following:
 Flip the --no-wallet toggle
 Select a section of the blockchain to store fully (percentage based,
 possibly on hash % sections?)
 Begin pruning all sections not included in 2
 The idea is that you can implement it similar to how a Koorde is done, in
 that the network will decide which sections it retrieves. So if the user
 prompts it to store 50% of the blockchain, it would look at its peers, and
 at their peers (if secure), and choose the least-occurring options from
 them.

 This would allow them to continue validating all transactions, and still
 store a full copy, just distributed among many nodes. It should overall
 have little impact on security (unless I'm mistaken), and it would
 significantly reduce storage needs on a node.

 It would also allow for a retroactive --max-size flag, where it will prune
 until it is at the specified size, and continue to prune over time, while
 keeping to the sections defined by the network.

 What sort of side effects or network vulnerabilities would this introduce?
 I know some said it wouldn't be Sybil resistant, but how would this be less
 so than a fully pruned node?


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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Proposed additional options for pruned nodes

2015-05-12 Thread Jeff Garzik
True.  Part of the issue rests on the block sync horizon/cliff.  There is a
value X which is the average number of blocks the 90th percentile of nodes
need in order to sync.  It is sufficient for the [semi-]pruned nodes to
keep X blocks, after which nodes must fall back to archive nodes for older
data.

There is simply far, far more demand for recent blocks, and the demand for
old blocks very rapidly falls off.

There was even a more radical suggestion years ago - refuse to sync if too
old (2 weeks?), and force the user to download ancient data via torrent.



On Tue, May 12, 2015 at 1:02 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Tue, May 12, 2015 at 7:38 PM, Jeff Garzik jgar...@bitpay.com wrote:
  One general problem is that security is weakened when an attacker can
 DoS a
  small part of the chain by DoS'ing a small number of nodes - yet the
 impact
  is a network-wide DoS because nobody can complete a sync.

 It might be more interesting to think of that attack as a bandwidth
 exhaustion DOS attack on the archive nodes... if you can't get a copy
 without them, thats where you'll go.

 So the question arises: does the option make some nodes that would
 have been archive not be? Probably some-- but would it do so much that
 it would offset the gain of additional copies of the data when those
 attacks are not going no. I suspect not.

 It's also useful to give people incremental ways to participate even
 when they can't swollow the whole pill; or choose to provide the
 resource thats cheap for them to provide.  In particular, if there is
 only two kinds of full nodes-- archive and pruned; then the archive
 nodes take both a huge disk and bandwidth cost; where as if there are
 fractional then archives take low(er) bandwidth unless the fractionals
 get DOS attacked.




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Proposed additional options for pruned nodes

2015-05-12 Thread Jeff Garzik
One general problem is that security is weakened when an attacker can DoS a
small part of the chain by DoS'ing a small number of nodes - yet the impact
is a network-wide DoS because nobody can complete a sync.


On Tue, May 12, 2015 at 12:24 PM, gabe appleton gapplet...@gmail.com
wrote:

 0, 1, 3, 4, 5, 6 can be solved by looking at chunks chronologically. Ie,
 give the signed (by sender) hash of the first and last block in your range.
 This is less data dense than the idea above, but it might work better.

 That said, this is likely a less secure way to do it. To improve upon
 that, a node could request a block of random height within that range and
 verify it, but that violates point 2. And the scheme in itself definitely
 violates point 7.
 On May 12, 2015 3:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 It's a little frustrating to see this just repeated without even
 paying attention to the desirable characteristics from the prior
 discussions.

 Summarizing from memory:

 (0) Block coverage should have locality; historical blocks are
 (almost) always needed in contiguous ranges.   Having random peers
 with totally random blocks would be horrific for performance; as you'd
 have to hunt down a working peer and make a connection for each block
 with high probability.

 (1) Block storage on nodes with a fraction of the history should not
 depend on believing random peers; because listening to peers can
 easily create attacks (e.g. someone could break the network; by
 convincing nodes to become unbalanced) and not useful-- it's not like
 the blockchain is substantially different for anyone; if you're to the
 point of needing to know coverage to fill then something is wrong.
 Gaps would be handled by archive nodes, so there is no reason to
 increase vulnerability by doing anything but behaving uniformly.

 (2) The decision to contact a node should need O(1) communications,
 not just because of the delay of chasing around just to find who has
 someone; but because that chasing process usually makes the process
 _highly_ sybil vulnerable.

 (3) The expression of what blocks a node has should be compact (e.g.
 not a dense list of blocks) so it can be rumored efficiently.

 (4) Figuring out what block (ranges) a peer has given should be
 computationally efficient.

 (5) The communication about what blocks a node has should be compact.

 (6) The coverage created by the network should be uniform, and should
 remain uniform as the blockchain grows; ideally it you shouldn't need
 to update your state to know what blocks a peer will store in the
 future, assuming that it doesn't change the amount of data its
 planning to use. (What Tier Nolan proposes sounds like it fails this
 point)

 (7) Growth of the blockchain shouldn't cause much (or any) need to
 refetch old blocks.

 I've previously proposed schemes which come close but fail one of the
 above.

 (e.g. a scheme based on reservoir sampling that gives uniform
 selection of contiguous ranges, communicating only 64 bits of data to
 know what blocks a node claims to have, remaining totally uniform as
 the chain grows, without any need to refetch -- but needs O(height)
 work to figure out what blocks a peer has from the data it
 communicated.;   or another scheme based on consistent hashes that has
 log(height) computation; but sometimes may result in a node needing to
 go refetch an old block range it previously didn't store-- creating
 re-balancing traffic.)

 So far something that meets all those criteria (and/or whatever ones
 I'm not remembering) has not been discovered; but I don't really think
 much time has been spent on it. I think its very likely possible.


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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-10 Thread Jeff Garzik
*

  *This message was created with 100% recycled electrons. Please think
 twice before printing.*
  !DSPAM:554e4e5450787476022393!

 --

 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

 !DSPAM:554e4e5450787476022393!

 --

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


 !DSPAM:554e4e5450787476022393!


 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAlVPXp0ACgkQjwioWRGe9K1+2ACfViY0D2ksVFe29SwhxbtmNSC3
 TQAAnRoJLI9wW3DQRPqQ7PorKxelC2S2
 =Er51
 -END PGP SIGNATURE-


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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-08 Thread Jeff Garzik
That reminds me - I need to integrate the patch that automatically sweeps
anyone-can-pay transactions for a miner.


On Thu, May 7, 2015 at 7:32 PM, Tier Nolan tier.no...@gmail.com wrote:

 One of the suggestions to avoid the problem of fees going to zero is
 assurance contracts.  This lets users (perhaps large merchants or
 exchanges) pay to support the network.  If insufficient people pay for the
 contract, then it fails.

 Mike Hearn suggests one way of achieving it, but it doesn't actually
 create an assurance contract.  Miners can exploit the system to convert the
 pledges into donations.

 https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770

 Consider a situation in the future where the minting fee has dropped to
 almost zero.  A merchant wants to cause block number 1 million to
 effectively have a minting fee of 50BTC.

 He creates a transaction with one input (0.1BTC) and one output (50BTC)
 and signs it using SIGHASH_ANYONE_CAN_PAY.  The output pays to OP_TRUE.
 This means that anyone can spend it.  The miner who includes the
 transaction will send it to an address he controls (or pay to fee).  The
 transaction has a locktime of 1 million, so that it cannot be included
 before that point.

 This transaction cannot be included in a block, since the inputs are lower
 than the outputs.  The SIGHASH_ANYONE_CAN_PAY field mean that others can
 pledge additional funds.  They add more input to add more money and the
 same sighash.

 There would need to be some kind of notice boeard system for these
 pledges, but if enough pledge, then a valid transaction can be created.  It
 is in miner's interests to maintain such a notice board.

 The problem is that it counts as a pure donation.  Even if only 10BTC has
 been pledged, a miner can just add 40BTC of his own money and finish the
 transaction.  He nets the 10BTC of the pledges if he wins the block.  If he
 loses, nobody sees his 40BTC transaction.  The only risk is if his block is
 orphaned and somehow the miner who mines the winning block gets his 40BTC
 transaction into his block.

 The assurance contract was supposed to mean If the effective minting fee
 for block 1 million is 50 BTC, then I will pay 0.1BTC.  By adding his
 40BTC to the transaction the miner converts it to a pure donation.

 The key point is that *other* miners don't get 50BTC reward if they find
 the block, so it doesn't push up the total hashing power being committed to
 the blockchain, that a 50BTC minting fee would achieve.  This is the whole
 point of the assurance contract.

 OP_CHECKLOCKTIMEVERIFY could be used to solve the problem.

 Instead of paying to OP_TRUE, the transaction should pay 50 BTC to 1
 million OP_CHECKLOCKTIMEVERIFY OP_TRUE and 0.01BTC to OP_TRUE.

 This means that the transaction could be included into a block well in
 advance of the 1 million block point.  Once block 1 million arrives, any
 miner would be able to spend the 50 BTC.  The 0.01BTC is the fee for the
 block the transaction is included in.

 If the contract hasn't been included in a block well in advance, pledgers
 would be recommended to spend their pledged input,

 It can be used to pledge to many blocks at once.  The transaction could
 pay out to lots of 50BTC outputs but with the locktime increasing by for
 each output.

 For high value transactions, it isn't just the POW of the next block that
 matters but all the blocks that are built on top of it.

 A pledger might want to say I will pay 1BTC if the next 100 blocks all
 have at least an effective minting fee of 50BTC


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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Block Size Increase

2015-05-08 Thread Jeff Garzik
On Fri, May 8, 2015 at 10:59 AM, Alan Reiner etothe...@gmail.com wrote:


 This isn't about everyone's coffee.  This is about an absolute minimum
 amount of participation by people who wish to use the network.   If our
 goal is really for bitcoin to really be a global, open transaction network
 that makes money fluid, then 7tps is already a failure.  If even 5% of the
 world (350M people) was using the network for 1 tx per month (perhaps to
 open payment channels, or shift money between side chains), we'll be above
 100 tps.  And that doesn't include all the non-individuals (organizations)
 that want to use it.

 The goals of a global transaction network and everyone must be able to
 run a full node with their $200 dell laptop are not compatible.  We need
 to accept that a global transaction system cannot be fully/constantly
 audited by everyone and their mother.  The important feature of the network
 is that it is open and anyone *can* get the history and verify it.  But not
 everyone is required to.   Trying to promote a system where the history can
 be forever handled by a low-end PC is already falling out of reach, even
 with our miniscule 7 tps.  Clinging to that goal needlessly limits the
 capability for the network to scale to be a useful global payments system


To repeat, the very first point in my email reply was: Agree that 7 tps is
too low  Never was it said that bit

Therefore a reply arguing against the low end is nonsense, and the relevant
question remains on the table.

How high do you want to go - and can Layer 1 bitcoin really scale to get
there?

It is highly disappointing to see people endorse moar bitcoin volume!
with zero thinking behind that besides adoption!  Need to actually
project what bitcoin looks like at the desired levels, what network
resources are required to get to those levels -- including traffic to serve
those SPV clients via P2P -- and then work backwards from that to see who
can support it, and then work backwards to discern a maximum tps.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com wrote:

  (1) Blocks are essentially nearing full now.  And by full he means
 that the reliability of the network (from the average user perspective) is
 about to be impacted in a very negative way


Er, to be economically precise, full just means fees are no longer zero.
Bitcoin behaves as it always has.  It is no longer basically free to dump
spam into the blockchain, as it is today.

In the short term, blocks are bursty, with some on 1 minute intervals, some
with 60 minute intervals.  This does not change with larger blocks.



 (2) Leveraging fee pressure at 1MB to solve the problem is actually really
 a bad idea.  It's really bad while Bitcoin is still growing, and relying on
 fee pressure at 1 MB severely impacts attractiveness and adoption potential
 of Bitcoin (due to high fees and unreliability).  But more importantly, it
 ignores the fact that for a 7 tps is pathetic for a global transaction
 system.  It is a couple orders of magnitude too low for any meaningful
 commercial activity to occur.  If we continue with a cap of 7 tps forever,
 Bitcoin *will* fail.  Or at best, it will fail to be useful for the vast
 majority of the world (which probably leads to failure).  We shouldn't be
 talking about fee pressure until we hit 700 tps, which is probably still
 too low.

 [...]

1) Agree that 7 tps is too low

2) Where do you want to go?  Should bitcoin scale up to handle all the
world's coffees?

This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day -- just
for a single feed.  If you include relaying to multiple nodes, plus serving
500 million SPV clients en grosse, who has the capacity to run such a
node?  By the time we get to fee pressure, in your scenario, our network
node count is tiny and highly centralized.

3) In RE fee pressure -- Do you see the moral hazard to a software-run
system?  It is an intentional, human decision to flood the market with
supply, thereby altering the economics, forcing fees to remain low in the
hopes of achieving adoption.  I'm pro-bitcoin and obviously want to see
bitcoin adoption - but I don't want to sacrifice every decentralized
principle and become a central banker in order to get there.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
 More generally, consider the situation we're in now. Gavin is going off
 pitching this idea to the general public (which, I agree, is an
 important step in pulling off a hardfork) while people who actually
 study the issues are left wondering why they're being ignored (ie why is
 there no consensus-building happening on this list?).

This sub-thread threatens to veer off into he-said-she-said.

 If, instead, there had been an intro on the list as I think we should
 do the blocksize increase soon, what do people think?, the response
 could likely have focused much more around creating a specific list of
 things we should do before we (the technical community) think we are
 prepared for a blocksize increase.

Agreed, but that is water under the bridge at this point.  You - rightly -
opened the topic here and now we're discussing it.

Mike and Gavin are due the benefit of doubt because making a change to a
leaderless automaton powered by leaderless open source software is breaking
new ground.  I don't focus so much on how we got to this point, but rather,
where we go from here.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 9:40 PM, Tom Harding t...@thinlink.com wrote:

 On 5/7/2015 12:54 PM, Jeff Garzik wrote:
  2) Where do you want to go?  Should bitcoin scale up to handle all the
  world's coffees?

 Alan was very clear.  Right now, he wants to go exactly where Gavin's
 concrete proposal suggests.


G proposed 20MB blocks, AFAIK - 140 tps
A proposed 100MB blocks - 700 tps
For ref,
Paypal is around 115 tps
VISA is around 2000 tps (perhaps 4000 tps peak)

I ask again:  where do we want to go?   This is the existential question
behind block size.

Are we trying to build a system that can handle Paypal volumes?  VISA
volumes?

It's not a snarky or sarcastic question:  Are we building a system to
handle all the world's coffees?  Is bitcoin's main chain and network -
Layer 1 - going to receive direct connections from 500m mobile phones,
broadcasting transactions?

We must answer these questions to inform the change being discussed today,
in order to decide what makes the most sense as a new limit.  Any
responsible project of this magnitude must have a better story than zomg
1MB, therefore I picked 20MB out of a hat  Must be able to answer /why/
the new limit was picked.

As G notes, changing the block size is simply kicking the can down the
road: http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
Necessarily one must ask, today, what happens when we get to the end of
that newly paved road.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
I have a lot more written down, a WIP; here are the highlights.

- The 1MB limit is an ancient anti-spam limit, and needs to go.

- The 1MB limit is economically entrenched at this point, and cannot be
removed at a whim.

- This is a major change to the economics of a $3.2B system.  This change
picks winners and losers.  There is attendant moral hazard.

- The core dev team is not and should not be an FOMC.

- The bar for major economic change to a $3.2B system should necessarily
be high.  In the more boring world of investments, this would accompanied
by Due Diligence including but not limited to projections for success,
failure scenarios, upside risks and downside risks.  Projections and
fact-based simulations.

- There are significant disruption risks on the pro (change it) and con
(keep 1MB) sides of the debate.

- People are privately lobbying Gavin for this.  That is the wrong way to
go.   I have pushed for a more public debate, and public endorsements (or
condemnations) from major miners, merchants, payment processors,
stackholders, ...   It is unfair to criticize Gavin to doing this.
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:12 AM, Mike Hearn m...@plan99.net wrote:


 That's why I conclude the opposite - if there is no fork, then people's
 confidence in Bitcoin will be seriously damaged.


Yes, that is a possibility.



 If it's impossible to do something as trivial as removing a temporary hack
 Satoshi put in place, then what about bigger challenges?


This is absolutely not a trivial change.

It is a trivial *code* change.  It is not a trivial change to the economics
of a $3.2B system.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net
wrote:

 To be extremely specific: should Bitcoin development intenionally
 limit the network's capabilities to leave room for other projects, or
 should Bitcoin attempt to be the best system possible and let the
 other projects try to keep up as best they can?



Avoid such narrow, binary thinking.

Referencing the problem described in
http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
(not the solution - block size change - just the problem, tx/block Poisson
mismatch)

This problem - block creation is bursty - is fundamental to bitcoin.
Raising block size does not fix this problem (as [1] notes), but merely
kicks the can down the road a bit, by hiding it from users a bit longer.

Bitcoin is a settlement system, at the most fundamental engineering level.
It will never be an instant payment system for all the world's coffees (or
all the world's stock trades).  It is left to Layer 2 projects to
engineer around bitcoin's gaps, to produce an instant, secure, trustless,
egalitarian payment system using the bitcoin token.  [1] also notes this.

It is therefore not a binary decision of leaving room for other projects,
or not.  Layer-2 projects are critical to the success of bitcoin, and
complement bitcoin.






[1] http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea

Holistic thinking implies you build a full-stack system with bitcoin
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
Yes - but you must recognize that is precisely 50% of the picture.

Others have made different assumptions - taking the [1MB-constrained]
market *as it exists today*, rather than in some projected future.

Raising the block size limit then becomes a *human decision* to favor some
users over others, a *human decision* to prevent an active and competitive
free fee market developing at 1MB, a *human decision* to keep transaction
fees low to incentivize bitcoin adoption, a *human decision* to value
adoption over decentralization.

These statements are not value judgements - not saying you are wrong -
these are observations of some rather huge, relevant blind spots in this
debate.





On Thu, May 7, 2015 at 11:29 AM, Mike Hearn m...@plan99.net wrote:

 It is a trivial *code* change.  It is not a trivial change to the
 economics of a $3.2B system.


 Hmm - again I'd argue the opposite.

 Up until now Bitcoin has been unconstrained by the hard block size limit.

 If we raise it, Bitcoin will continue to be unconstrained by it. That's
 the default continue as we are position.

 If it's not raised, then ... well, then we're in new territory
 entirely. Businesses built on the assumption that Bitcoin could become
 popular will suddenly have their basic assumptions invalidated. Users will
 leave. The technical code change would be zero, but the economic change
 would be significant.




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
Dear list,

Apparently my emails are being marked as spam, despite being sent from
GMail's web interface.  I've pinged our sysadmin.  Thanks for letting
me know.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier justusranv...@riseup.net
wrote:

 In summary, I asked a question neither you, nor Peter Todd, want to
 answer and want to actively discourage people from even asking at all.


Incorrect; your question included built-in assumptions with which I
disagree.

Bitcoin needs to be the best it can be (Layer 1), but all solutions cannot
and should not be implemented at Layer 1.

We need to scale up both bitcoin (L1) and solutions built on top of bitcoin
(L2).
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 10:38 AM, Justus Ranvier justusranv...@riseup.net
wrote:

 On 05/07/2015 04:04 PM, Jeff Garzik wrote:
  - This is a major change to the economics of a $3.2B system.  This
  change picks winners and losers.  There is attendant moral hazard.

 This is exactly true.

 There are a number of projects which aren't Bitcoin that benefit from
 filling in the gap left by Bitcoin's restricted transaction rate
 capability.

 If Bitcoin fills that gap, Bitcoin wins and those other projects lose.

 Should decisions about Bitcoin development take into account the
 desires of competing projects?


heh - I tend to think people here want bitcoin to succeed.  My statement
refers to picking winners and losers from within the existing bitcoin
community  stakeholders.

The existential question of the block size increase is larger - will
failing to increase the 1MB limit permanently stunt bitcoin's growth?
--
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] Block Size Increase

2015-05-07 Thread Jeff Garzik
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Looking for a good bitcoin script decompiler in Python

2015-04-29 Thread Jeff Garzik
python-bitcoinlib supports script parsing and execution.


On Wed, Apr 29, 2015 at 6:16 PM, Richard Moore m...@ricmoo.com wrote:

 I have a library, pycoind (https://github.com/ricmoo/pycoind) you might
 find useful.


  import pycoind

 
 str(pycoind.script.Tokenizer('76a9143f320f852a51643d3ffbaa1f49bfe521dd97764a88ac'.decode('hex')))
 'OP_DUP OP_HASH160 3f320f852a51643d3ffbaa1f49bfe521dd97764a OP_EQUALVERIFY
 OP_CHECKSIG'




 On Apr 29, 2015, at 1:12 PM, Braun Brelin bbre...@gmail.com wrote:

 Hi all,

 I'm trying to find a good python script that will take the hash of the
 locking and
 unlocking tx scripts and output the actual op codes.

 Any ideas where to look?

 Thanks,



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


 .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º

 Richard Moore ~ Founder
 Genetic Mistakes Software inc.
 phone: (778) 882-6125
 email: ric...@geneticmistakes.com
 www: http://GeneticMistakes.com



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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Build your own nHashType

2015-04-09 Thread Jeff Garzik
On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse stephencalebmo...@gmail.com
wrote:

 Is hashing transaction data once for each input really a huge bottleneck,
 though? Do mobile devices have an issue with this?



Think about what slow transaction verification speed means.  Slower
propagation across the network.  More work per node.  Greater opportunity
for algorithmic attacks, races and other shenanigans by attackers.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-23 Thread Jeff Garzik
On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo elombr...@gmail.com wrote:
 As for 0-conf security, there are instances where 0-conf transactions make a
 lot of sense - i.e. paying for utilities, ISP, web hosting, or other such
 services which could be immediately shut off upon detection of a
 double-spend.

Indeed.  0-conf risk calculus must include business conditions.

Business cases such as placing an order for a physical good, making an
in-person purchase at a brick-n-mortar store, or subscriptions already
have countermeasures in place if funds go astray.  Order fulfilment
can be stopped, subscriptions cancelled, photos handed to police.

A thief wants to maximize return, which usually means either stealing
a few large amounts or many small amounts.  Double-spending against a
SatoshiDICE clone is easy to automate.  Many other purchase situations
are difficult to repeat without getting caught, or the level of effort
(cost) is greater than the payout of double-spending a small amount.
0-conf is typically only used for small amounts, where useful theft
relies on high repetition.

Purely online, mostly anonymous services like SatoshiDICE will be
easily attacked if they accept 0-conf transactions as there is little
customer/reputation relationship to leverage.  However, that
observation cannot be easily applied to most other businesses.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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] replace-by-fee v0.10.0rc4

2015-02-21 Thread Jeff Garzik
 big to fail'.
 
  Where the blockchain improves on everything else is in transparency. If
  you
  reverse transactions a lot, it will be obvious from an analysis. I would
  much
  rather deal with a known, predictable, and relatively continous
  transaction
  reversal rate (percentage) than have to deal with sudden failures where
  some anonymous bad actor makes off with a fortune.
 
  We already have zero-conf double-spend transaction reversal, why not
  explicitly
  extend that a little in a way that senders and receivers have a choice
  to
  use it, or not?
 
 
  [1]
  http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
 
 
  --
  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


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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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] replace-by-fee v0.10.0rc4

2015-02-21 Thread Jeff Garzik
On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote:
 On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote:
 This isn't some theoretical exercise.  Like it or not many use
 insecure 0-conf transactions for rapid payments.  Deploying something
 that makes 0-conf transactions unusable would have a wide, negative
 impact on present day bitcoin payments, thus scorched earth

 And maybe by maintaining first seen policies we're harming the system
 in the long term by encouraging people to widely deploy systems based
 on extremely weak assumptions.

Lacking a coded, reviewed alternative, that's only a platitude.
Widely used 0-conf payments are where we're at today.  Simply ceasing
the maintaining [of] first seen policies alone is simply not a
realistic option.  The negative impact to today's userbase would be
huge.

Instant payments need a security upgrade, yes.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Jeff Garzik
Repeating past statements, it is acknowledged that Peter's scorched
earth replace-by-fee proposal is aptly named, and would be widely
anti-social on the current network.

At a high level, we can see that this thread is contentious because
this covers _what we want bitcoin to be_, and that is an opinion
(versus engineering fact), and it varies from person to person.

However, hope is the denial of reality...instead we should walk
forward with our eyes open[1].  My interest in bitcoin originates from
the science fiction concept of credits[2], a universal money that
transcends national borders and even planets.  That is what I hoped
bitcoin would be.  universal payments is both a laudable goal and a
shopworn bitcoin marketing slogan.

The fundamental engineering truths diverge from that misty goal:
Bitcoin is a settlement system, by design.

The process of consensus settles upon a timeline of transactions,
and this process -- by design -- is necessarily far from instant.
Alt-coins that madly attempt 10-second block times etc. are simply a
vain attempt to paper over this fundamental design attribute:
consensus takes time.

As such, the blockchain can never support All The Transactions, even
if block size increases beyond 20MB.  Further layers are -- by design
-- necessary if we want to achieve the goal of a decentralized payment
network capable of supporting full global traffic.

Bitcoin payments are like IP packets -- one way, irreversible.  For
larger value transfers this attaches attendent risk of loss -- as
we've seen in the field time  again.  The world's citizens en masse
will not speak to each other with bitcoin (IP packets), but rather
with multiple layers (HTTP/TCP/IP) that enable safe and secure value
transfer or added features such as instant transactions.

This opinion is not a conspiracy to put the bankers back in charge
-- it is a simple acknowledgement of bitcoin's design.  The consensus
system settles on a timeline.

Bitcoin transactions are, by definition, not instant.
Zero confirmation transactions are, by definition, not secure.

Proposals such as Oleg's are _necessary_ to fully build out the
bitcoin system.  Avoid short-sighted, short-term thinking that views
the lowest layer (one-way value xfer) at the most optimal layer at
which free persons will transact freely  instantly across planet
Earth.

It is foolish to think the entire world will connect directly to the
P2P block network and broadcast all the morning coffees to all the
miners.  That's not how the system works.  It is a settlement layer.
We _must_ build decentralized layered solutions on top of bitcoin,
rather than stuffing everything into bitcoin itself.















[1] 
http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot
[2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html




On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn m...@plan99.net wrote:
 I know you will ignore this as usual, but the entire replace-by-fee folly is
 based on your fundamental misunderstanding of miner incentives.

 Miners are not incentivised to earn the most money in the next block
 possible. They are incentivised to maximise their return on investment.
 Making Bitcoin much less useful reduces demand for the bitcoins they are
 mining, reducing coinbase and fee income in future blocks. Quite possibly,
 to the point where those miners are then making a loss.

 Your scorched earth plan is aptly named, as it's guaranteed to make
 unconfirmed payments useless. If enough miners do it they will simply break
 Bitcoin to the point where it's no longer an interesting payments system for
 lots of people. Then miners who have equipment to pay off will be really
 screwed, not to mention payment processors and all the investors in them.

 I'm sure you can confuse a few miners into thinking your ideas are a
 super-duper way to maximise their income, and in the process might
 facilitate a pile of payment fraud. But they aren't. This one is about as
 sensible as your let's never increase the block size  and let's kill SPV
 clients crusades - badly thought out and bad for Bitcoin.

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Dive into the World

Re: [Bitcoin-development] determining change addresses using the least significant digits

2015-02-06 Thread Jeff Garzik
Yes.  You can certainly add additional inputs and outputs -- and as such
you can increase privacy and defrag your wallet at the same time.


On Fri, Feb 6, 2015 at 2:11 AM, Wladimir laa...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
 cryptocurrenc...@quidecco.de wrote:

  A possible approach to handle this issue would be to add a randomized
  offset amount to the payment amount. This offset amount can be small
  in comparison to the payment amount.
 
  Any thoughts?

 Adding/subtracting a randomized offset amount is one way, but there
 have also been more sophisticated ideas to obfuscate the amount, e.g.
 by adding multiple change outputs or even distributing over multiple
 transactions (potentially coinjoined for further privacy).

 Mike Hearn had some ideas regarding obfuscation of payment amounts,
 which still make sense, and he wrote about them here:
 https://medium.com/@octskyward/merge-avoidance-7f95a386692f

 Wladimir


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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] [softfork proposal] Strict DER signatures

2015-02-03 Thread Jeff Garzik
+1   I just ran an it-works test on #5743.  Not exhaustive, but I do agree
it should be included w/ other DERSIG changes.


On Tue, Feb 3, 2015 at 1:19 PM, Gavin Andresen gavinandre...@gmail.com
wrote:

 I think we should just do it, and include it with the other DERSIG changes
 for 0.10.

 On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille pieter.wui...@gmail.com
 wrote:


 I understand it's late, which is also why I ask for opinions. It's
 also not a priority, but if we release 0.10 without, it will first
 need a cycle of making this non-standard, and then in a further
 release doing a second softfork to enforce it.

 It's a 2-line change; see #5743.

 --
 Pieter


 --
 --
 Gavin Andresen


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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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 Jeff Garzik
It is not fear, it is field experience.

JSON has proven to be a bug generator for the reasons already stated.

JSON does not include type marshalling and input validation.
Protobufs/msgpack/etc. engineered those to occur automatically, because
that is an area shown by field experience to be a constant source of bugs
and inconsistent parsing/validation behavior.




On Wed, Jan 28, 2015 at 11:52 AM, Nicolas DORIER nicolas.dor...@gmail.com
wrote:

 For the number of field there is in the spec, I don't consider having a
 JSON to schama really worthwhile.
 If you fear it is error prone, then we should provide some testing data
 for the BIP70. (Which I already did for protobuf, but was rejected, because
 deemed no useful thanks to the code generator... But such code generator
 gave me inconsistencies with gavin's implementation for example)

 Why do you think type support is very useful in our case ? we have 3
 types, and dealing only with bytes, int, and string.
 It cost me more time to find a suitable cross plateform lib for protobuf
 (in c#, that works in ios and winrt) than I would by just coding the json
 wrapper classes by hand. (JSON libs are more wildspread and supported than
 protobuf)

 2015-01-28 17:04 GMT+01:00 Jeff Garzik jgar...@bitpay.com:

 Not to mention the tiresome and error-prone task of writing your own
 JSON-to-schema marshalling code -- or something equivalent to the protobufs
 compiler and libs for JSON.

 protobufs -- and its modern competitors such as msgpack -- natively
 provide type support in a way that must be hacked into JSON or XML.

 The protobuf/msgpack design is engineered to avoid bugs routinely found
 in JSON parsing code; due to the amount of code  effort involved in JSON
 input sanity checking, bugs and inconsistencies inevitable arise.  We have
 seen this in bitcoind with JSON-RPC.



 On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn m...@plan99.net wrote:

 On the other hand, if you charge the developer (and not the plateform)
 to check certificate validity, it means that you have to develop a
 different codebase for all plateform you are targeting, because each
 plateform store trusted root certificate in a different manner with
 different APIs, and also have different types representing a X509
 Certificate.


 That's what cross-platform abstraction libraries are for. Both Java and
 Qt provide a key store library that can load from either the OS root store
 or a custom one. If your chosen app platform doesn't, OK, then you'll have
 to make or find one yourself. Perhaps contribute it upstream or make it a
 library. But that's not a limitation of BIP70.

 Just as a reminder, there is no obligation to use the OS root store. You
 can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
 etc stores and load it in your app. We do this in bitcoinj by default to
 avoid cases where BIP70 requests work on some platforms and not others,
 although the developer can easily override this and use the OS root store
 instead.

 Of all possible solutions, using a third party service to convert things
 to JSON is one of the least obvious and highest effort. I don't know anyone
 else who arrived at such a conclusion and respectfully disagree that this
 is a problem with the design choices in BIP70. It sounds like a bizarre
 hack around lack of features in whatever runtime you're using.



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




 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/





-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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 Jeff Garzik
Not to mention the tiresome and error-prone task of writing your own
JSON-to-schema marshalling code -- or something equivalent to the protobufs
compiler and libs for JSON.

protobufs -- and its modern competitors such as msgpack -- natively provide
type support in a way that must be hacked into JSON or XML.

The protobuf/msgpack design is engineered to avoid bugs routinely found in
JSON parsing code; due to the amount of code  effort involved in JSON
input sanity checking, bugs and inconsistencies inevitable arise.  We have
seen this in bitcoind with JSON-RPC.



On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn m...@plan99.net wrote:

 On the other hand, if you charge the developer (and not the plateform) to
 check certificate validity, it means that you have to develop a different
 codebase for all plateform you are targeting, because each plateform store
 trusted root certificate in a different manner with different APIs, and
 also have different types representing a X509 Certificate.


 That's what cross-platform abstraction libraries are for. Both Java and Qt
 provide a key store library that can load from either the OS root store or
 a custom one. If your chosen app platform doesn't, OK, then you'll have to
 make or find one yourself. Perhaps contribute it upstream or make it a
 library. But that's not a limitation of BIP70.

 Just as a reminder, there is no obligation to use the OS root store. You
 can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
 etc stores and load it in your app. We do this in bitcoinj by default to
 avoid cases where BIP70 requests work on some platforms and not others,
 although the developer can easily override this and use the OS root store
 instead.

 Of all possible solutions, using a third party service to convert things
 to JSON is one of the least obvious and highest effort. I don't know anyone
 else who arrived at such a conclusion and respectfully disagree that this
 is a problem with the design choices in BIP70. It sounds like a bizarre
 hack around lack of features in whatever runtime you're using.



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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] IMPULSE: Instant Payments using the Bitcoin protocol

2015-01-22 Thread Jeff Garzik
The user experience is significantly more secure than today.

Presumably the future supports many payment facilitators, including m-of-n
oracles, and this is perfectly compatible with that.


On Thu, Jan 22, 2015 at 10:19 AM, Tom Harding t...@thinlink.com wrote:

 On 1/17/2015 12:45 PM, Rune Kjær Svendsen wrote:
  PDF: http://impulse.is/impulse.pdf
 
  I'd love to hear this list's thoughts.
 

 Will success be defined by BitPay Payment Channels Accepted Here signs
 appearing in shop windows?



 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
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-19 Thread Jeff Garzik
None of those listed were in the context of performance.  Parsing of binary
or text is quite fast these days, and is not really a consideration versus
other needs such as a predictable encoding for a single data
representation.  XML and JSON both can represent the same post-evaluation
user data a million different ways, which is awful for anything you are
signing and hashing.  Text formats also transit binary data very poorly,
leading to unnecessary wrapping and unwrappiing (a programmatic, visibility
 bug; again performance not a primary concern).

This is evident because both XML and JSON have standards efforts under way
to correct some of these problems and make them more deterministic.
However, such standards are not field deployed and widely supported by
parsers and generators alike.




On Mon, Jan 19, 2015 at 2:16 PM, Richard Brady rnbr...@gmail.com wrote:

 Fair points, although for me the line is blurred between which of those
 are security considerations vs performance considerations.

 Richard

 On 19 January 2015 at 19:09, Jeff Garzik jgar...@bitpay.com wrote:

 Text formats such as XML or JSON are far less deterministic, are more
 loosely specified, have wide variance in parsing, are not very hash-able,
 the list goes on.


 On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady rnbr...@gmail.com wrote:

 Hi Gavin, Mike and co

 Is there a strong driver behind the choice of Google Protocol Buffers
 for payment request encoding in BIP-0070?

 Performance doesn't feel that relevant when you think that:
 1. Payment requests are not broadcast, this is a request / response
 flow, much more akin to a web request.
 2. One would be cramming this data into a binary format just so you can
 then attach it to a no-so-binary format such as HTTP.

 Some great things about protocols/encodings such as HTTP/JSON/XML are:
 1. They are human readable on-the-wire. No Wireshark plugin required,
 tcpdump or ngrep will do.
 2. There are tons of great open source libraries and API for parsing /
 manipulating / generating.
 3. It's really easy to hand-craft a test message for debugging.
 4. The standards are much easier to read and write. They don't need to
 contain code like BIP-0070 currently does and they can contain examples,
 which BIP70 does not.
 5. They are thoroughly specified by independent standards bodies such as
 the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
 6. They're a family ;-)

 Keen to hear your thoughts on this and very keen to watch the payment
 protocol grow regardless of encoding choice! My background is SIP / VoIP
 and I think that could be a fascinating use case for this protocol which
 I'm hoping to do some work on.

 Best,
 Richard




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
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-19 Thread Jeff Garzik
Text formats such as XML or JSON are far less deterministic, are more
loosely specified, have wide variance in parsing, are not very hash-able,
the list goes on.


On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady rnbr...@gmail.com wrote:

 Hi Gavin, Mike and co

 Is there a strong driver behind the choice of Google Protocol Buffers for
 payment request encoding in BIP-0070?

 Performance doesn't feel that relevant when you think that:
 1. Payment requests are not broadcast, this is a request / response flow,
 much more akin to a web request.
 2. One would be cramming this data into a binary format just so you can
 then attach it to a no-so-binary format such as HTTP.

 Some great things about protocols/encodings such as HTTP/JSON/XML are:
 1. They are human readable on-the-wire. No Wireshark plugin required,
 tcpdump or ngrep will do.
 2. There are tons of great open source libraries and API for parsing /
 manipulating / generating.
 3. It's really easy to hand-craft a test message for debugging.
 4. The standards are much easier to read and write. They don't need to
 contain code like BIP-0070 currently does and they can contain examples,
 which BIP70 does not.
 5. They are thoroughly specified by independent standards bodies such as
 the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
 6. They're a family ;-)

 Keen to hear your thoughts on this and very keen to watch the payment
 protocol grow regardless of encoding choice! My background is SIP / VoIP
 and I think that could be a fascinating use case for this protocol which
 I'm hoping to do some work on.

 Best,
 Richard



 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
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-19 Thread Jeff Garzik
ASN.1 is not nearly as flexible when it comes to well-supported libraries,
generators, and the ecosystem that surrounds the actual encoding.  You
don't see ASN.1 compilers + language support packages for [all popular
programming languages], as you do with protobufs.

Google engineers were well aware it existed I'm sure.  There are wider
considerations beyond the low-level specified format.

Protobufs have their problems and aren't perfect, but ASN.1 ecosystem is
far less developed in the programming ecosystem, far less approachable for
programmers.  BIP70 wouldn't have been as easily and widely adopted if
ASN.1 had been chosen.




On Mon, Jan 19, 2015 at 2:19 PM, Matt Whitlock b...@mattwhitlock.name
wrote:

 Even if a compact binary encoding is a high priority, there are more
 standard choices than Google Protocol Buffers. For example, ASN.1 is a
 very rigorously defined standard that has been around for decades, and
 ASN.1 even has an XML encoding (XER) that is directly convertible to/from
 the binary encoding (BER/DER), given the schema. In practice, I'm mostly
 agnostic about what encoding is actually used in BIP70, and I wouldn't
 fault BIP70 for choosing Google Protocol Buffers, but the very existence of
 Protobuf perplexes me, as it apparently re-solves a problem that was solved
 40 years ago by ASN.1. It's as though the engineers at Google weren't aware
 that ASN.1 existed.


 On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:
  Hi Gavin, Mike and co
 
  Is there a strong driver behind the choice of Google Protocol Buffers for
  payment request encoding in BIP-0070?
 
  Performance doesn't feel that relevant when you think that:
  1. Payment requests are not broadcast, this is a request / response flow,
  much more akin to a web request.
  2. One would be cramming this data into a binary format just so you can
  then attach it to a no-so-binary format such as HTTP.
 
  Some great things about protocols/encodings such as HTTP/JSON/XML are:
  1. They are human readable on-the-wire. No Wireshark plugin required,
  tcpdump or ngrep will do.
  2. There are tons of great open source libraries and API for parsing /
  manipulating / generating.
  3. It's really easy to hand-craft a test message for debugging.
  4. The standards are much easier to read and write. They don't need to
  contain code like BIP-0070 currently does and they can contain examples,
  which BIP70 does not.
  5. They are thoroughly specified by independent standards bodies such as
  the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
  6. They're a family ;-)
 
  Keen to hear your thoughts on this and very keen to watch the payment
  protocol grow regardless of encoding choice! My background is SIP / VoIP
  and I think that could be a fascinating use case for this protocol which
  I'm hoping to do some work on.
 
  Best,
  Richard


 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
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-19 Thread Jeff Garzik
Correct.  I should have said more likely to be deterministic  Bitcoin
Core does not *rely* on determinism in BIP70; I was referring to recent
upstream efforts to make protobufs usable in a deterministic fashion by
default.

On Mon, Jan 19, 2015 at 3:03 PM, Alan Reiner etothe...@gmail.com wrote:

  I'm a bit confused.  It's been a long time since I looked at protobuf
 (and will have to dig into it soon), but I seem to recall it doesn't have
 any of the determinism properties you guys just said.  It is intended to
 allow you to skip details of the on-the-wire representations and just send
 a bunch of named fields between systems.  I thought there was no guarantee
 that two identical protobuf structures will get serialized identically...?





 On 01/19/2015 02:57 PM, Richard Brady wrote:

   Thanks guys, great answers.

  The design choice certainly makes a lot more sense now regardless of
 whether one agrees with it or not.

  Regards,
 Richard



 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely 
 compliant.http://p.sf.net/sfu/gigenet



 ___
 Bitcoin-development mailing 
 listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions

2015-01-14 Thread Jeff Garzik
Sounds like this warrants a micro-BIP just to get everybody on the same
page.


On Wed, Jan 14, 2015 at 11:37 AM, Ruben de Vries ru...@blocktrail.com
wrote:

 For p2sh multisig TXs the order of the public keys affect the hash and
 there doesn't seem to be an agreed upon way of sorting the public keys.

 If there would be a standard (recommended) way of sorting the public keys
 that would make it easier for services that implement some form of multisig
 to be compatible with each other without much hassle and making it possible
 to import keys from one service to another.

 I'm not suggesting forcing the order, just setting a standard to
 recommend, there doesn't seem to be much reason for (new) services to not
 follow that recommendation.

 Ryan from BitPay broad this up before (
 https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in
 bitcore they've implemented lexicographical sorting on the hex of the
 public key.
 In a short search I can't find any other library that has a sorting
 function, let alone using it by default, so bitcore is currently my only
 reference.


 ​Ruben de Vries
 ​CTO, BlockTrail


 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Jeff Garzik
Mike, Can you be more specific?  You reference original design without
saying how it was different/better.



On Fri, Jan 9, 2015 at 8:20 AM, Mike Hearn m...@plan99.net wrote:

 A limitation on most existing micropayment channel ideas is that payments
 can only flow in one direction.


 It's worth noting that the original protocol as designed by Satoshi did
 not have this limitation. It has evolved this way because of ad-hoc DoS
 fixes over time (btw I'm not saying they were the wrong thing to do, as non
 ad hoc solutions are significantly more work). But it seems like
 eventually a different approach to handling DoS attacks based on resource
 prioritisation and scheduling will become needed / implemented, and at that
 point the original design could be safely brought back to life.



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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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] Area of Focus

2014-12-20 Thread Jeff Garzik
Getting back to the original topic...

I would recommend first taking a look at how the current tests are built
(via autoconf/automake) in src/test.  There are several surfaces to test,
RPC, REST, P2P, internal unit tests, and more.  Then, Travis applies a
second level of testing via the bitcoinj-based regression tests.

Some automated tests that operate at the Qt level would be interesting.  In
general, the current tests only scratch the surface of what Needs To Be
Tested...  but part of figuring out a good test is (a) knowing bitcoin and
(b) knowing the current test regimes.

Join #bitcoin-dev IRC and ask questions.  Read the bitcoin wiki.




On Sat, Dec 20, 2014 at 2:42 AM, Will Bickford wbi...@gmail.com wrote:

 Hi all, I'm looking to help with Bitcoin core development in my spare time
 (a few hours per week).

 A little bit about me:
 * I use C++ and Qt daily
 * I love to automate and enhance software systems
 * I enjoy root causing and fixing issues

 I saw Gavin say we needed help with testing in a Reddit AMA a while ago.
 I'm curious where I can make the best impact. Any feedback would be
 appreciated. Thanks!

 Will Bickford
 In Google We Trust


 --
 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=164703151iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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=164703151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Open development processes and reddit charms

2014-12-16 Thread Jeff Garzik
  release.  It probably seems chaotic at times.  In effect,
git[hub] and the Internet enable a dynamic system of review and feedback,
where each stage provides a check-and-balance for bad ideas and bad
software changes.  It's a human process, designed to acknowledge and handle
that human engineers are fallible and might make mistakes (or be
coerced/under duress!).  History and field experience will be the ultimate
judge, but I think Bitcoin Core is doing good on this score, all things
considered.

At the end of the day, while no change is without risk, version 0.10 work
was done with attention to consensus risk at multiple levels (not just
short term).




*Technical and social debt*
Working on the Linux kernel was an interesting experience that combined
git-driven parallel development and a similar source code hairball.  One of
the things that quickly became apparent is that cosmetic patches,
especially code movement, was hugely disruptive.  Some even termed it
anti-social.  To understand why, it is important to consider how modern
software changes are developed:

Developers work in parallel on their personal computers to develop XYZ
change, then submit their change upstream as a github pull request.  Then
time passes.  If code movement and refactoring changes are accepted
upstream before XYZ, then the developer is forced update XYZ -- typically
trivial fixes, re-review XYZ, and re-test XYZ to ensure it remains in a
known-working state.

Seemingly cosmetic changes such as code movement have a ripple effect on
participating developers, and wider developer community.  Every developer
who is *not* immediately merged upstream must bear the costs of updating
their unmerged work.

Normally, this is expected.  Encouraging developers to build on top of
upstream produces virtuous cycles.

However, a constant stream of code movement and cosmetic changes may
produce a constant stream of disruption to developers working on
non-trivial features that take a bit longer to develop before going
upstream.  Trivial changes are encouraged, and non-trivial changes face a
binary choice of (a) be merged immediately or (b) bear added re-base,
re-view, re-test costs.

Taken over a timescale of months, I argue that a steady stream of cosmetic
code movement changes serves as a disincentive to developers working with
upstream.  Each upstream breakage has a ripple effect to all developers
downstream, and imposes some added chance of newly introduced bugs on
downstream developers.  I'll call this social debt, a sort of technical
debt[4] for developers.
[4] http://en.wikipedia.org/wiki/Technical_debt

As mentioned above, the libconsensus and code movement work is a net gain.
The codebase needs cleaning up.  Each change however incurs a little bit of
social debt.  Life is a little bit harder on people trying to get work into
the tree.  Developers are a little bit more discouraged at the busy-work
they must perform.  Non-trivial pull requests take a little bit longer to
approve, because they take a little bit more work to rebase (again).

A steady flow of code movement and cosmetic breakage into the tree may be a
net gain, but it also incurs a *lot* of social debt.  In such situations,
developers find that tested, working out-of-tree code repeatedly stops
working *during the process of trying to get that work in-tree*.  Taken
over time, it discourages working on the tree.  It is rational to sit back,
*not* work on the tree, let the breakage stop, and then pick up the pieces.




*Paradox Unwound*
Bitcoin Core, then, is pulled in opposite directions by a familiar
problem.  It is generally agreed that the codebase needs further
refactoring.  That's not just isolated engineer nit-picking.  However, for
non-trivial projects, refactoring is always anti-social in the short term.
It impacts projects other than your own, projects you don't even know
about. One change causes work for N developers.  Given these twin opposing
goals, the key, as ever, is finding the right balance.

Much like feature freeze in other software projects, developing a policy
that opens and closes windows for code movement and major disruptive
changes seems prudent.  One week of code movement  cosmetics followed by 3
weeks without, for example.  Part of open source parallel development
is *social
signalling*:  Signal to developers when certain changes are favored or not,
then trust they can handle the rest from there.

While recent code movement commits themselves are individually ACK-worthy,
professionally executed and moving towards a positive goal, I think the
project could strike a better balance when it comes to disruptive cosmetic
changes, a balance that better encourages developers to work on more
involved Bitcoin Core projects.


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Download BIRT iHub F-Type - The Free Enterprise-Grade

Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

2014-12-15 Thread Jeff Garzik
On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak btcd...@gmail.com wrote:

 We all want to see more modular code, but the first steps should just be
 to relocate blocks of code so everything is more logically organised in
 smaller files (especially for consensus critical code). Refactoring should
 come in a second wave preferably after a stable release.


This is my opinion as well.  In the Linux kernel, we often were faced with
a situation where you have a One Big File driver with  1MB of source
code.  The first step was -always- raw code movement, a brain-dead breaking
up of code into logical source code files.

Refactoring of data structures comes after that.

While not always money-critical, these drivers Had To Keep Working.  We had
several situations where we had active users, but zero hardware access for
debugging, and zero access to the vendor knowledge (hardware documentation,
engineers).  Failure was not an option.  ;p

Performing the dumb Break Up Files step first means that future, more
invasive data structures are easier to review, logically segregated, and
not obscured by further code movement changes down the line.  In code such
as Bitcoin Core, it is important to think about the _patch stream_ and how
to optimize for reviewer bandwidth.

The current stream of refactoring is really a turn-off in terms of
reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly.  It
is a seemingly never-ending series of tiny
refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work.
Some change is in order, gentlemen.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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=164703151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

2014-12-15 Thread Jeff Garzik
If code movement is not compressed into a tight time window, code movement
becomes a constant stream during development.  A constant stream of code
movement is a constant stream of patch breakage, for any patch or project
not yet in-tree.  The result is to increase the work and cost on any
contributor whose patches are not immediately merged.

For the record, since this is trending reddit, I __do__ support the end
result of 0.10 refactoring, the work towards the consensus lib.

My criticism is of a merge flow which _unintentionally_ rewards only
certain types of patches, and creates disincentives for working on other
types of patches.







On Mon, Dec 15, 2014 at 4:19 PM, Cory Fields li...@coryfields.com wrote:

 On Mon, Dec 15, 2014 at 2:35 PM, Jeff Garzik jgar...@bitpay.com wrote:
  On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields li...@coryfields.com
 wrote:
 
  That's exactly what happened during the modularization process, with
  the exception that the code movement and refactors happened in
  parallel rather than in series. But they _were_ done in separate
  logical chunks for the sake of easier review.
 
 
  That's exactly what was done except it wasn't
 
  Yes, in micro, at the pull request level, this happened
  * Code movement
  * Refactor
 
  At a macro level, that cycle was repeated many times, leading to the
  opposite end result:  a lot of tiny movement/refactor/movement/refactor
  producing the review and patch annoyances described.
 
  It produces a blizzard of new files and new data structures, breaking a
  bunch of out-of-tree patches, complicating review quite a bit.  If the
 vast
  majority of code movement is up front, followed by algebraic
  simplifications, followed by data structure work, further patches are
 easy
  to review/apply with less impact on unrelated code.
 

 I won't argue that at all because it's perfectly logical, but in
 practice that doesn't translate from the macro level to the micro
 level very well. At the micro level, minor code changes are almost
 always needed to accommodate useful code movement. Even if they're not
 required, it's often hard to justify code movement for the sake of
 code movement with the promise that it will be useful later.

 Rather than arguing hypotheticals, let's use a real example:
 https://github.com/bitcoin/bitcoin/pull/5118 . That one's pretty
 simple. The point of the PR was to unchain our openssl wrapper so that
 key operations could be performed by the consensus lib without
 dragging in bitcoind's structures. The first commit severs the
 dependencies. The second commit does the code movement from the
 now-freed wrapper.

 I'm having a hard time coming up with a workflow that would handle
 these two changes as _separate_ events, while making review easier.
 Note that I'm not attempting to argue with you here, rather I'm
 genuinely curious as to how you'd rather see this specific example
 (which is representative of most of my other code movement for the
 libbitcoinconsensus work, i believe) handled.

 Using your model above, I suppose we'd do the code movement first with
 the dependencies still intact as a pull request. At some later date,
 we'd sever the dependencies in the new files. I suppose you'd also
 prefer that I group a bunch of code-movement changes together into a
 single PR which needs little scrutiny, only verification that it's
 move-only. Once the code-movement PRs are merged, I can begin the
 cleanups which actually fix something.

 In practice, though, that'd be a massive headache for different
 reasons. Lots in flux with seemingly no benefits until some later
 date. My PR's can't depend on eachother because they don't actually
 fix issues in a linear fashion. That means that other devs can't
 depend on my PRs either for the same reason. And what have we gained?

 Do you find that assessment unreasonable?

 Cory



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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=164703151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-26 Thread Jeff Garzik
I don't recall being contacted directly, but the attack has been
discussed.  It relies on a number of conditions.  For example, if you are
over Tor, they try to kick the machine off Tor, _assuming_ that it will
fall back to non-Tor.  That's only true for dual stack nodes, which are not
really 100% anonymous anyway -- you're operating from your public IP anyway.


On Wed, Nov 26, 2014 at 2:47 AM, Jean-Paul Kogelman jeanpaulkogel...@me.com
 wrote:

 This paper was just posted on reddit that describes how an attacker can
 de-anonymize clients on the bitcoin network. It mentions that the core devs
 were contacted prior to publication. I was just wondering, how many of
 these issues have already been addressed?


 Paper (University of Luxembourg):
 http://orbilu.uni.lu/handle/10993/18679


 Kind regards,

 Jean-Paul


 --
 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=157005751iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Update on mobile 2-factor wallets

2014-11-08 Thread Jeff Garzik
Overall, super duper awesome.  :)  Tweeted this post.

I do have a concern about 2-of-2 arrangements.  To me, this screams
twice as fragile if not done properly; and I've seen a few naive
implementations in the field that seemed quite fragile.

2FA/2-of-2 does solve the common problem of single device compromise.
It also makes funds unspendable if -either- device's keys become lost.



On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn m...@plan99.net wrote:
 Here is a summary of current developments in the space of decentralised
 2-factor Bitcoin wallets. I figured some people here might find it
 interesting.

 There has been very nice progress in the last month or two. Decentralised
 2FA wallets run on a desktop/laptop and have a (currently always Android)
 smartphone app to go with them. Compromise of the wallet requires compromise
 of both devices.

 Alon Muroch and Chris Pacia have made huge progress on Bitcoin
 Authenticator, their (HD) wallet app. The desktop side runs on
 Win/Mac/Linux and the mobile side runs on Android. Sending money from the
 desktop triggers a push notification to the mobile side, which presents the
 transaction for confirmation. Additionally the desktop wallet has a variety
 of other features like OneName integration. It's currently in alpha, but I
 suspect it will be quite popular once released due to its focus on UI and
 the simple mobile security model. I've tried it out and it worked fine.

 https://www.bitcoinauthenticator.org/
 https://github.com/cpacia/BitcoinAuthenticator/commits/master(mobile)
 https://github.com/negedzuregal/BitcoinAuthWallet   (desktop)

 Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor
 functionality. However, this has various downsides that are well known:
 less support for the address type and larger transactions that waste block
 chain space + result in higher fees.

 To solve this problem Christopher Mann and Daniel Loebenberger from Uni Bonn
 have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and
 Reiter to ECDSA, and implemented their own desktop/Android wallet app pair
 showing that it works and has good enough performance. This means that P2SH
 / CHECKMULTISIG is no longer required for the two factor auth case, and thus
 it's as cheap as using regular addresses.

 https://github.com/ChristopherMann/2FactorWallet
 https://eprint.iacr.org/2014/629.pdf

 Their protocol uses an interesting combination of ECDSA, Paillier
 homomorphic encryption and some zero knowledge proofs to build a working
 solution for the 2-of-2 case only. Their app bootstraps from a QR code that
 includes a TLS public key and IP address of the desktop: the mobile app then
 connects to it directly, renders the transaction and performs the protocol
 when the user confirms. The protocol is online, so both devices must be
 physically present.

 Their code is liberally licensed and looks easy to integrate with Alon and
 Chris' more user focused work, as both projects are built with Android and
 the latest bitcoinj. If someone is interested, merging Christopher/Daniel's
 code into the bitcoinj multisig framework would be a useful project, and
 would make it easier for wallet devs to benefit from this work. I can write
 a design doc to follow if needed.

 Currently, neither of these projects implement support for BIP70, so the
 screen you see when signing the transaction is hardly user friendly or
 secure: you just have to trust that the destination address you're paying to
 isn't tampered with. Support for sending a full payment request between
 devices is the clear next step once these wallets have obtained a reasonable
 user base and are stable.



 --

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Jeff Garzik
IMO, CHECKLOCKTIMEVERIFY should be included in that list, too.

RE soft fork vs. hard fork:  It's about this time at Mike Hearn will
chime in, on the side of hard forks.  Hard forks are in a sense much
cleaner, and permit solving problems not otherwise solvable with a
hard fork.  However, hard forks clearly have risks, notably the Big
Risk akin to a US Constitutional Convention:  once you open the door,
anything can happen, any rule no matter how sacred can be changed.

Soft forks are not without their own risks, e.g. reducing some things
to SPV levels of security.

Leaning towards soft fork, but it is a good discussion to have.  A
poorly implemented soft fork may potentially require a hard fork to
fix rollout bugs.


On Thu, Nov 6, 2014 at 11:05 PM, Matt Corallo bitcoin-l...@bluematt.me wrote:
 Depends, without BIP62 a /lot/ of the even basic contracts that people
 want to use today (or wanted to use 18 months ago) are unusable, in
 fact, without BIP62, the atomic swaps suggested as important for
 sidechains are not secure. While redoing Bitcoin in a hardfork is nice,
 its a very long-term thing, so I'm not sure about making people wait for
 a large hardfork just to use payment channels.

 Also, I echo the difficulty of writing consensus-compatible code and
 highly suggest anyone with money behind an implementation that is doing
 script verification in code that isnt Bitcoin Core rethink that decision.

 Matt

 On 11/06/14 21:58, Tamas Blummer wrote:
 Thanks Peter,

 Having tried to write a bug-for-bug compatible code with Satoshi, I can only 
 second that it is rather close to impossible.

 The aim of BIP62 is noble, still it does not feel right for me to increase 
 the complexity of the code with e.g. soft-fork-ready versioning.
 Freezing the consensus code, studying its bugs appears more appropriate to 
 me. What we learn could define a hard fork or a better
 chain we migrate to as discussed by blockstream.

 Tamas Blummer

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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] BIP62 and future script upgrades

2014-11-04 Thread Jeff Garzik
On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote:
 On another topic, I'm skeptical of the choice of nVersion==3 - we'll
 likely end up doing more block.nVersion increases in the future, and
 there's no reason to think they'll have anything to do with
 transactions. No sense creating a rule that'll be so quickly broken.

Moderately agreed.

Earlier in BIP 62 lifetime, I had commented on ambiguity that arose
from bumping tx version simply because we were bumping block version.
The ambiguity was corrected, but IMO remains symptomatic of potential
problems and confusion down the road.

Though I ACK'd the change, my general preference remains to disconnect
TX and block version.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] Increasing regularity of block times?

2014-10-30 Thread Jeff Garzik
That's what we do for testnet today:  https://en.bitcoin.it/wiki/Testnet

If no block is found for 20 minutes, one minimum-diff block may be mined.


On Thu, Oct 30, 2014 at 7:18 PM, Rusty Russell ru...@rustcorp.com.au wrote:
 Hi all,

 I've been toying with an algorithm to place a ceiling on
 confirmation latency by allowing weaker blocks after a certain time.
 Hope this isn't noise, but thought someone must have considered this
 before, or know of flaws in the scheme?

 Gory details:
 http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html

 Thanks,
 Rusty.

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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] Death by halving (pro-active proposals)

2014-10-29 Thread Jeff Garzik
Seconded - IMO a key future use of the chain will be securing other
chains.  I'm interested in pursuing the merged-mining angle.

Getting chain hashes to a miner, and getting that miner payment from
the chain, is key to this.  Consider a future where there are 10,000
chains secured by one block...


On Wed, Oct 29, 2014 at 10:34 AM, Sergio Lerner
sergioler...@certimix.com wrote:
 Instead of discussing what will happen when the subsidy is halved (which
 nobody really knows) maybe we can think about of what we can do to
 mitigate any damage in case something unwanted happens. Let's be proactive.

 For instance, any form of merged-mining (like higher frequency
 side-chains) will end-up increasing miners profit, even by a small
 margin. Then that margin can compensate miners not to turn off their
 equipment. Then we can encourage merge-mining on SHA-256, instead of
 discouraging SHA-256 alt-coins.

 Also we can encourage mining during the trouble period by creating a
 donation pool: suppose we manage to convince miners to donate 1% of
 their revenue in order to pay back to the miners for the first month
 after the reward halving. If every block pays 1% for 10 months, then
 every block during the first month of halving will earn 20% more.  Of
 course, convincing miners of this may be difficult, but not impossible.
 It could be done automatically with nLockTime freeze of transactions
 with high fees, so no TTP is necessary.

 So here are two proposals, any other idea?

 Best regards,
  Sergio.



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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-27 Thread Jeff Garzik
On Mon, Oct 27, 2014 at 7:24 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
 Do you think it would a reasonable idea to put down some thoughts and
 proposals in a BIP?

It would certainly be nice to start with a document that reflects the
new REST interface.  That makes a good starting point for further
discussion.

In general the interface exports what information is already
available.  As Wladimir notes, there is no plan to turn this into a
full fledged block explorer, if that implies adding indices etc.

Feedback on the HTTP headers and form, and additional thoughts 
proposals are welcome.  My pull request is intended to present
something minimal, that is easy to review and merge.  My own list of
further to-dos includes

* last-modified and etag headers
* export UTXOs a la Mike Hearn's getutxos query
* eventually rebuild the RPC server to something multithreaded a la
https://github.com/jgarzik/rpcsrv

PR #2844 @ https://github.com/bitcoin/bitcoin/pull/2844

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] death by halving

2014-10-25 Thread Jeff Garzik
On Sat, Oct 25, 2014 at 2:06 PM, Alex Mizrahi alex.mizr...@gmail.com wrote:
 Hashrate might drop by more than 50% immediately after the halving (and
 before difficulty is updated), thus a combination of the halving and slow
 difficulty update pose a real threat.

Flag day herd behavior like this is unlikely for well informed and
well prepared market participants.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] death by halving

2014-10-25 Thread Jeff Garzik
It is an overly-simplistic miner model to assume altruism is
necessary.  The hashpower market is maturing in the direction of
financial instruments, where the owner of the hashpower is not
necessarily the one receiving income.  These are becoming tradeable
instruments, and derivatives and hedging are built on top of that.
Risk is hedged at each layer.  Market players also forge agreements
with miners, and receive -negative- value if hashpower is simply shut
down.

Simplistic models cannot predict what hashpower does in the face of
business-to-business medium- and long-term contracts.


On Sat, Oct 25, 2014 at 2:22 PM, Alex Mizrahi alex.mizr...@gmail.com wrote:


 Flag day herd behavior like this is unlikely for well informed and
 well prepared market participants.


 It is simply rational to turn your mining device off until difficulty
 adjusts.
 Keeping mining for 2+ weeks when it costs you money is an altruistic
 behavior, we shouldn't rely on this.

 --

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-10-22 Thread Jeff Garzik
Take the discussion of this site to another M-L, please.  It is off-topic.

Actual discussion of the paper and side-chains is on-topic.

This M-L is publicly archived.


On Wed, Oct 22, 2014 at 6:52 PM, Daniel Murrell dsmurr...@gmail.com wrote:
 Sorry Bryan, this was the first paper posted to this list since I've
 been on it that I added to my site. I was quite excited about this.

 I was not planning on and certainly won't be making this advertisement
 after every paper posted on this list (I may do it on reddit). I did
 post on reddit a few times yes, but I assumed that this list's user
 base didn't overlap extremely (does it?). I'm not sure why my posts
 got down voted there. The down voters gave me no constructive feedback
 about the usefulness of my site, and neither have you.

 Are you able to give me your feedback on the site I've spent quite
 some time setting up privately so that we don't spam this list again?



 On Wed, Oct 22, 2014 at 11:35 PM, Bryan Bishop kanz...@gmail.com wrote:
 On Wed, Oct 22, 2014 at 5:01 PM, Daniel Murrell dsmurr...@gmail.com wrote:
 p.s. I'm not trying to monetize this site. I just tried to make
 something I thought could be useful.

 [Unsolicited administrivia follows.]

 You have been posting this in a bunch of places for a while now, at
 least three times today by my count on other mediums. I also observed
 negative karma scores associated with these posts. Maybe you could
 consider toning down the message frequency? I think by now everyone
 knows you want them to use your site. I also think that in the limit
 that it would be inappropriate for /everyone/ to post all possible
 research sites, or even vaguely topical discussion sites, for every
 paper posted. Personally, I would much rather have discussions happen
 on the mailing list anyway, although if I had a different opinion I
 certainly hope I would still send this message.

 Thank you.

 - 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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue

2014-10-10 Thread Jeff Garzik
The whole issue is a troll, and I'm afraid you got sucked in.

There are no plans to add a blacklist to Bitcoin Core.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-03 Thread Jeff Garzik
RE  It's not like other software where people can choose to skip an
upgrade and things still work just like before.

If you're a minority, sure you can.  Still a few nutters out there on
a 0.3.x codebase, including one or two inattentive,
now-inconsequential miners.

There is some headroom built in for just that... less disruptive
upgrades that don't require 100%.



On Fri, Oct 3, 2014 at 4:58 PM, Mike Hearn m...@plan99.net wrote:
 Alright. It seems there's no real disagreement about how the opcode behaves.
 Perhaps a time limit would be appropriate to stop people creating outputs
 locked for 100 years  is bitcoin even likely to exist in 100 years? The
 entire history of computing is not even that old, seems hard to imagine that
 it'd be good for anything beyond wasting space in the database. But this is
 a minor point.

 So I guess it's time to start the deployment discussion.

 Bitcoin is a consensus system. It works best when everyone is following
 exactly the same rules at the same time. A soft fork works against this
 principle by allowing nodes to think they're following the majority ruleset,
 even if they aren't, effectively downgrading them to something a bit like
 SPV security without them realising.

 A hard fork has multiple desirable properties. Most importantly, it means a
 node can detect it's no longer in the consensus because it'll find its own
 chain height has diverged significantly from its peers. Core already has
 code that knows how to detect this condition and log errors about it as well
 as running the alertnotify script i.e. emailing the admin. Ideally it would
 also stop serving work so miners shut down or fail over, but this is easily
 added to the CheckForkWarningConditions() function.

 In other words, this gives the cleanest failure we can give, such that any
 procedures a node operator has put in place to alert them of divergence will
 be triggered.  Any code which is waiting for confirmations will wait forever
 at this point, thus minimising the risk of loss.

 Additionally, forcing old peers to fall behind means SPV clients will pick
 the right chain, and not end up downloading transactions or blocks that are
 about to be doomed at the next re-org. They can easily choose to ignore
 transactions relayed by peers that are too far behind and thus not end up
 accepting transactions that are no longer valid according to the majority (a
 scenario which can cause monetary loss).

 I don't think hard forks should be scary. Mechanisms are in place to warn
 people and they can be scheduled with plenty of time in advance. The main
 stated justification for a soft fork is backwards compatibility, but in a
 system like Bitcoin you really don't want to be running behind the consensus
 and it's hard to imagine any node operator deliberately choosing to stay on
 the wrong side of the fork. It's not like other software where people can
 choose to skip an upgrade and things still work just like before.

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Applying clang-format to Bitcoin Core

2014-09-20 Thread Jeff Garzik
We are slowly applying a consistent style to the C++ source, via
clang-format (LLVM) and $repo/src/.clang-format.

If you have a patch that is difficult to apply to the tree due to
reformatting, simply apply clang-format and then rediff.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

2014-09-15 Thread Jeff Garzik
On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander tho...@thomaszander.se wrote:
 Any and all PGP related howtos will tell you that you should not trust or sign
 a formerly-untrusted PGP (or GPG for that matter) key without seeing that
 person in real life, verifying their identity etc.

Such guidelines are a perfect example of why PGP WoT is useless and
stupid geek wanking.

A person's behavioural signature is what is relevant.  We know how
Satoshi coded and wrote.  It was the online Satoshi with which we
interacted.  The online Satoshi's PGP signature would be fine...
assuming he established a pattern of use.

As another example, I know the code contributions and PGP key signed
by the online entity known as sipa.  At a bitcoin conf I met a
person with photo id labelled Pieter Wuille who claimed to be sipa,
but that could have been an actor.  Absent a laborious and boring
signed challenge process, for all we know, sipa is a supercomputing
cluster of 500 gnomes.

The point is, the online entity known as Satoshi is the relevant
fingerprint.  That is easily established without any in-person
meetings.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

2014-09-15 Thread Jeff Garzik
It applies to OP, bitcoin community development and Satoshi.

value of in person vetting of identity is undeniable...  no it is
quite deniable. Satoshi is the quintessential example. We value brain
output, code.  The real world identity is irrelevant to whether or not
bitcoin continues to function.

The currency of bitcoin development is code, and electronic messages
describing cryptographic theses.  _That_ is the relevant fingerprint.

Governmental id is second class, can be forged or simply present a
different individual from that who is online.  PGP WoT wanking does
not solve that problem at all.






On Mon, Sep 15, 2014 at 9:32 AM, Brian Hoffman brianchoff...@gmail.com wrote:
 I would agree that the in person aspect of the WoT is frustrating, but to 
 dismiss this as geek wanking is the pot calling the kettle.

 The value of in person vetting of identity is undeniable. Just because your 
 risk acceptance is difference doesn't make it wanking. Please go see if you 
 can get any kind of governmental clearance of credential without in-person 
 vetting. Ask them if they accept your behavioral signature.

 I know there is a lot of PGP hating these days but this comment doesn't 
 necessarily apply to every situation.



 On Sep 15, 2014, at 9:08 AM, Jeff Garzik jgar...@bitpay.com wrote:

 On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander tho...@thomaszander.se 
 wrote:
 Any and all PGP related howtos will tell you that you should not trust or 
 sign
 a formerly-untrusted PGP (or GPG for that matter) key without seeing that
 person in real life, verifying their identity etc.

 Such guidelines are a perfect example of why PGP WoT is useless and
 stupid geek wanking.

 A person's behavioural signature is what is relevant.  We know how
 Satoshi coded and wrote.  It was the online Satoshi with which we
 interacted.  The online Satoshi's PGP signature would be fine...
 assuming he established a pattern of use.

 As another example, I know the code contributions and PGP key signed
 by the online entity known as sipa.  At a bitcoin conf I met a
 person with photo id labelled Pieter Wuille who claimed to be sipa,
 but that could have been an actor.  Absent a laborious and boring
 signed challenge process, for all we know, sipa is a supercomputing
 cluster of 500 gnomes.

 The point is, the online entity known as Satoshi is the relevant
 fingerprint.  That is easily established without any in-person
 meetings.

 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/

 --
 Want excitement?
 Manually upgrade your production database.
 When you want reliability, choose Perforce
 Perforce version control. Predictably reliable.
 http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Jeff Garzik
Indeed -- Every byte added to the QR code makes it more difficult to
be used in restaurants, pubs and other low-light conditions.  BitPay
tested some of these scenarios.

Scannability is absolutely impacted.

On Fri, Sep 12, 2014 at 9:49 AM, Mike Hearn m...@plan99.net wrote:
 A few thoughts on this:

 (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
 here is that a MITM intercepts the payment request, which will be typically
 requested just seconds after the QR code is vended. 80 bits of entropy would
 still be a lot and take a long time to brute force, whilst keeping QR codes
 more compact, which impacts scannability.

 (2) This should not be necessary in the common HTTPS context. The QR code
 itself is going to be fetched from some service, over HTTPS. I see no
 reasonable attacker that can MITM the request for the BIP70 message but not
 the request to get the QR code. Adding a hash makes QR codes more bloated
 and harder to scan, all on the assumption that HTTPS is broken in some odd
 way that we haven't actually ever seen in practice.

 (3) This can be useful in the Bluetooth context, but then again, we could
 also do things a different way by signing with the key in the first part of
 the URI, thus avoiding the need for a hash.

 I know I've been around the loop on this one with Andreas many times. But
 this BIP doesn't fix any actually existing problem in the previous spec. It
 exists because Andreas thinks SSL is useless. If SSL is useless we all have
 much bigger problems.

 --
 Want excitement?
 Manually upgrade your production database.
 When you want reliability, choose Perforce
 Perforce version control. Predictably reliable.
 http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Reconsidering github

2014-08-19 Thread Jeff Garzik
It would be nice if the issues and git repo for Bitcoin Core were not
on such a centralized service as github, nice and convenient as it is.

To that end, I note that Linux does its own git repo, and now requires
2FA: 
http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication

As a first step, one possibility is putting the primary repo on
bitcoin.org somewhere, and simply mirroring that to github for each
push.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Jeff Garzik
Encryption is of little value if you may deduce the same information
by observing packet sizes and timings.


On Tue, Aug 19, 2014 at 7:38 PM, J Ross Nicoll j...@jrn.me.uk wrote:
 The concern is that if you can monitor traffic in and out of a single node,
 you can determine which transactions originate from it vs those which it
 relays. That's not great, certainly, but how many nodes actually require
 that level of security, and surely they can use Tor or VPN services if so?

 Further, unless the remote nodes are in some way trusted, you're changing
 the attack from read-only to requiring the ability to perform  a man in the
 middle attack - that doesn't seem much harder to me.

 As Gregory states, there's been at least two recent serious if not
 catastrophic OpenSSL bugs, and the consequences of Heartbleed if the Bitcoin
 network had been vulnerable are the stuff of nightmares.

 Very difficult to see the risk/reward payoff being worthwhile.

 Ross


 On 19/08/2014 18:35, Johnathan Corgan wrote:

 On 08/19/2014 09:38 AM, Gregory Maxwell wrote:

 We've dodged several emergency scale vulnerabilities by not having TLS.

 I'm still trying to understand the original premise that we want
 encrypted communications between nodes.

 I can certainly see the value of having *authenticated* traffic with
 specific nodes, using an HMAC for the protocol messages in place of the
 current checksum.



 --



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



 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Jeff Garzik
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd p...@petertodd.org wrote:
 On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik jgar...@bitpay.com wrote:
Encryption is of little value if you may deduce the same information
by observing packet sizes and timings.

 That is simply incorrect. The resources required to do that kind of 
 monitoring are very high; even the NSA can't pull it off consistently for

Hardly.  For example, when a new block arrives on the network, a
single observer at a single location may obtain a binary likely|not
bitcoin protocol decision from a spike in usage correlated with
sudden, global network activity after a period of inactivity.  I'll
not detail all such metrics.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Jeff Garzik
Simply by observing timing from sufficiently geo-graphically and
network-ly dispersed nodes, you may deduce the original broadcaster of
a transaction.  Rotating peers doesn't help.

That said, periodic rotation can be helpful.  Every 2-10 minutes is excessive.


On Mon, Aug 18, 2014 at 12:46 PM, Ivan Pustogarov
ivan.pustoga...@uni.lu wrote:
 Hi there,

 I'd like to start a discussion on periodic rotation of outbound connections.
 E.g. every 2-10 minutes an outbound connections is dropped and replaced
 by a new one.

 Motivation:
 Each bitcoin non-UPnP client behind NAT has 8 outbound connections
 which change only rarely (due to occasional remote side disconnections).
 A subset of these 8 entry nodes uniquely identifies a user.
 An attacker can listen for transactions in Bitcoin network and for each
 transaction record the first 8 peers which forwarded the transaction.
 If two distinct transactions (with unrelated bitcoin addresses)
 come from the same set of 8 peers, the attacker can conclude that they
 originated from the same user. This gives another method (in addition
 to transaction graph analysis) for an attacker to link different BC
 addresses of the same user.
 Also note that by default bitcoin clients advertise their public IP
 addresses. The attacker can link the advertised IP's to corresponding
 8 entry nodes and use it to deanonymise Bitcoin clients.

 If a bitcoin client periodically rotates his set of outbound
 connections, his 8-peers fingerprint is blurred over time.

 Corresponding pull request is #4723.

 Some details are here: https://www.cryptolux.org/index.php/Bitcoin

 --
 Ivan

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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] Synchronization: 19.5 % orphaned blocks at height 197'324

2014-08-10 Thread Jeff Garzik
This issue is being worked on, under the category of headers first
synchronization.

Until that is finished, it is recommended that you download
bootstrap.dat via torrent:
https://bitcointalk.org/index.php?topic=145386.0


On Sun, Aug 10, 2014 at 9:42 AM, m...@bitwatch.co m...@bitwatch.co wrote:
 Hello all,

 I'm currently synchronizing a new node and right now, at a progress of a
 height of 197'324 blocks, I count in my debug.log an aweful amount of
 38'447 orphaned blocks which is about 19.5 %.

 It has been I while since I watched the synchronization process closely,
 but this number seems pretty high to me.

 I'm wondering about the following: would it be possible for a malicious
 party to generate chains of blocks with low difficulity which are not
 part of the main chain to slow down the sync process?


 Build and version information:
 https://github.com/jmcorgan/bitcoin/tree/026686c7de76dfde6fcacfc3d667fb3418a946a7
 (sipa/jmcorgan address index)
 Rebased with:
 https://github.com/bitcoin/bitcoin/tree/94e1b9e05b96e4fe639e5b07b7a53ea216170962
 (almost up-to-date mainline)

 Compressed debug.log attached:
 https://www.dropbox.com/s/uvtd91xiwmdmun7/debug.7z?m=
 (filesize: 7.67 MB, uncompressed: 41.3 MB)

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



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

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


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
This is not a generic I run a website! advertisement feature.
NODE_EXT_SERVICES is tightly focused on services that exist
if-any-only-if a P2P bitcoin node (bitcoind) is reachable via the same
advertised address.

You may usefully create overlay networks of specialized services.



On Fri, Aug 8, 2014 at 6:41 AM, Christian Decker
decker.christ...@gmail.com wrote:
 I wonder whether we actually want to support this kind of advertisement in
 the P2P protocol. We have a working mechanism for protocol extensions in the
 P2P network (service flags) so this is obviously only for services that are
 not P2P extensions, so why have them in there at all?

 I'd argue that a parallel network, external to Bitcoin, could take over the
 task of advertising external services.

 Regards,
 Chris

 --
 Christian Decker


 On Fri, Aug 8, 2014 at 11:26 AM, Wladimir laa...@gmail.com wrote:

 On Fri, Aug 8, 2014 at 12:15 PM, Wladimir laa...@gmail.com wrote:
  On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net wrote:
  He wants to use it to advertise services that are not part of the P2P
  protocol itself, but run on a different port. Reserving services bits
  for those is not acceptable.
 
 
  Why not? Does the port matter much?
 
  Yes. The services bits are for advertising services on the P2P
  network. That's not open for discussion.

 It also wouldn't work. A bit is not enough to find an external service
 except in the naive case where the advertised service would have a
 fixed port. Not even bitcoind has a fixed port. So there needs to be a
 mechanism to find how to connect to the 'external service'. This is
 provided by the proposed extension.

 It would in principle be possible to advertise an extra service bit
 *in addition to* this one, to make it easier to find through the addr
 mechanism. But it  would be confusing and IMO an abuse of P2P service
 bits.

 Wladimir


 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
n Fri, Aug 8, 2014 at 6:01 AM, Mike Hearn m...@plan99.net wrote:
 What's wrong
 with the existing mechanism exactly?

It would be wrong to add NODE_INSIGHT, NODE_ELECTRUM_SERVER, etc. bits
even though you do have useful bitcoin-related APIs that exist on the
same system as bitcoind.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
Yes, that is the one change I am still pondering:  adding categories
(classes), rather than one single bit.

Thus the modified proposal would become:
- eliminate NODE_EXT_SERVICES
- for a class of services, such as insight w/ added blockchain indexes
 queries, add NODE_EXT_INDEXED_CHAIN
- for another class of services, add NODE_EXT_
- Re-use the same P2P message and structure (CExtService,
extservices P2P message) for all NODE_EXT_xxx classes.

This preserves vendor/API neutrality, while saving effort on the part
of clients seeking these services.  The point about service discovery
necessitating some node walking is valid, which makes categories
somewhat attractive.

Having the service run on some arbitrary other port isn't
particularly useful, IMO --  A statement disproved by reality.
Multi-port is the method most commonly found in the field today.
Logically so, because it is the easiest to deploy:

* The most likely setup TODAY is multi-daemon: bitcoind + your own software
* The most likely configuration for multi-daemon is self-evidently
multi-port (versus two services appearing on the same port)

It is quite useful, and indeed, the most likely setup to be found in operation.







On Fri, Aug 8, 2014 at 7:38 AM, Mike Hearn m...@plan99.net wrote:
 I'd like to see a mechanism whereby a Bitcoin node can delegate processing
 of unknown messages to an external process, so a P2P node can be composed
 out of separated programs, but such a service would be indistinguishable at
 the network layer from one provided by Bitcoin Core itself, so a service bit
 would be appropriate for those.

 For instance, Insight could then offer a command set that extends the p2p
 protocol for doing block explorer type queries. There's no need for the
 protocol to be Insight specific.  You'd just have NODE_INDEXED_CHAIN
 instead.

 Having the service run on some arbitrary other port isn't particularly
 useful, IMO - the biggest win from having some separated protocol would be
 the ability to use TLS, but if you're connecting to an IP address rather
 than a domain name (like if you discovered via service bits/getextsrv) this
 doesn't add much. It boils down to minor syntax differences in how numbers
 are laid out in a grid. And the performance issue remains.

 Additionally, nothing in this spec requires that a local bitcoind be
 running. What stops someone from advertising just NODE_EXTENDED_SERVICES and
 nothing else? I don't think a generic service advertisement mechanism is a
 bad thing to have, by the way, just pointing out that nothing makes this
 more focused than service bits already are.



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir laa...@gmail.com wrote:
 On Fri, Aug 8, 2014 at 1:38 PM, Mike Hearn m...@plan99.net wrote:
 I'd like to see a mechanism whereby a Bitcoin node can delegate processing
 of unknown messages to an external process, so a P2P node can be composed
 out of separated programs, but such a service would be indistinguishable at
 the network layer from one provided by Bitcoin Core itself, so a service bit
 would be appropriate for those.

 This diverges from the topic but seems like a good idea to me in
 general, not so much as replacement for jgarzik's proposal.

 Something like `getutxos` or this proposal could be implemented as an
 external application or script, instead of having to integrate
 everything into bitcoind.

Seconded.  Command plug-ins and such seem like an idea worth exploring.

We don't need to shove everything into bitcoind.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir laa...@gmail.com wrote:
 Bitcoind would need a local interprocess message bus for that, and
 would need to act as router for messages from/to the P2P network.
 ZeroMQ seems like a good choice for that. That's not completely crazy
 as there are already plans to add zeromq as an optional dependency for
 notifications [1].

Generally agreed, though for ZMQ it is a bit different than a P2P service.

IMO, ZMQ really wants to be a plug-in that registers some internal
signals.  It wants to capture the precise points where a block was
accepted internally.  PR #4599 tries to lead by example:
https://github.com/bitcoin/bitcoin/pull/4599

A P2P service would be a slightly different sort of plug-in.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
getutxos is a special case, since we already maintain that index as
part of normal operation.

While I dislike some aspects of getutxos (covered elsewhere), if
merged, it would be more appropriate as a special case to keep
getutxos fully internal to bitcoind for implementation reasons.

On Fri, Aug 8, 2014 at 8:11 AM, Mike Hearn m...@plan99.net wrote:
 Something like `getutxos` or this proposal could be implemented as an
 external application or script, instead of having to integrate
 everything into bitcoind.


 Right, although getutxos needs access to the UTXO set which bitcoind already
 has. An external plugin would have to recalculate it from scratch which
 seems redundant.

 However there are many other useful services that could be added in such a
 way, like -txindex or the nLockTime storage facility we talked about the
 other day.


 Bitcoind would need a local interprocess message bus for that


 Maybe, that feels like it could be overkill though. Probably just something
 like

 ./bitcoind -servicecookie=long random string -allowextservices=127.0.0.1/8

 and then any program can connect to bitcoind as normal, send registersrv
 with the cookie and a list of command ids it's interested in, maybe a
 service bit to set, and start receiving those messages wrapped in a new
 structure that gives some kind of client ID (like IP address). So any
 library that can do the basic P2P protocol could then be extended with not
 much code to get a multiplexed stream of messages from different clients.

 An additional standalone program can then bridge this mechanism to running a
 shell command for particular messages, though given the history of shell
 based exploits I'd feel safer with something that doesn't do that 



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-08-08 Thread Jeff Garzik
On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding t...@thinlink.com wrote:
 4. add a new IsStandard rule rejecting transactions with an nLockTime
 more than N blocks behind the current tip (for some fixed value N, to
 be determined)

It cannot be assumed that transaction creation time and transaction
publish-to-outside-world time are the same, even though they often
are.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Jeff Garzik
gmaxwell noted on IRC that enabling TLS could be functionally, if not
literally, a DoS on the pool servers.  Hence the thought towards a
more lightweight method that simply prevents client payout redirection
+ server impersonation.


On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn m...@plan99.net wrote:
 Certificate validation isn't needed unless the attacker can do a direct
 MITM
 at connection time, which is a lot harder to maintain than injecting a
 client.reconnect.


 Surely the TCP connection will be reset once the route reconfiguration is
 completed, either by the MITM server or by the client TCP stack when it
 discovers the server doesn't know about the connection anymore?

 TLS without cert validation defeats the point, you can still be connected to
 a MITM at any point by anyone who can simply interrupt or corrupt the
 stream, forcing a reconnect.

 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Miners MiTM

2014-08-07 Thread Jeff Garzik
You don't necessarily need the heavy weight of SSL.

You only need digitally signed envelopes between miner and pool[1].

[1] Unless the pool is royally stupid and will somehow credit miner B, if
miner B provides to the pool a copy of miner A's work.



On Thu, Aug 7, 2014 at 8:29 PM, slush sl...@centrum.cz wrote:

 AFAIK the only protection is SSL + certificate validation on client side.
 However certificate revocation and updates in miners are pain in the ass,
 that's why majority of pools (mine including) don't want to play with
 that...

 slush


 On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr l...@dashjr.org wrote:

 On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
  Hi there,
 
  I was wondering if you guys have come across this article:
 
  http://www.wired.com/2014/08/isp-bitcoin-theft/
 
  The TL;DR is that somebody is abusing the BGP protocol to be in a
 position
  where they can intercept the miner traffic. The concerning point is that
  they seem to be having some degree of success in their endeavour and
  earning profits from it.
 
  I do not understand the impact of this (I don't know much about BGP, the
  mining protocol nor anything else, really), but I thought it might be
 worth
  putting it up here.

 This is old news; both BFGMiner and Eloipool were hardened against it a
 long
 time ago (although no Bitcoin pools have deployed it so far). I'm not
 aware of
 any actual case of it being used against Bitcoin, though - the target has
 always been scamcoins.


 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

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




 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-07 Thread Jeff Garzik
Link: https://github.com/bitcoin/bitcoin/pull/4657

It is not necessary to build all functionality into bitcoind, to form
a decentralized network. BitPay's insight open source block explorer
API project requires, and runs on top of, bitcoind. Therefore, at the
same IP address as bitcoind, other services are made available to the
public (scriptPubkey queries, other added-value queries). This results
in a decentralized network of anyone running a full node and an
insight server, as a subset of the whole P2P net.  One then does not
need to trust BitPay's insight server, but may query any number of
insight servers from multiple operators, and survey the results.

Obviously, we want to build this in a generic, vendor-neutral way.  As
such, NODE_EXT_SERVICES is advertised via the addr P2P message.
Nodes that recognize the NODE_EXT_SERVICES bit may connect to that
node, query a services list via getextsrv P2P message, and then take
further action based on the results.  The results are quite
straightforward:

service name, service port (or -1 if undefined), list of string
key/value attribs

Services may only advertise added services if and only if the external
services are at the same IP address that is being advertised.

This is not a fully baked proposal by any means, but more of a trial
balloon to get discussion moving.

There is no need to implement all services inside bitcoind...

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Jeff Garzik
 ...because nLockTime is the exact opposite of expiration.  A locked TX
begins life invalid, and becomes valid (not-expired) after nLockTime passes.

A new field containing expiration time would work.



On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding t...@thinlink.com wrote:


 How is eventual expiration of a tx that started life with an nLockTime in
 the future breaking, any more than any other tx expiring?



 On 8/6/2014 6:54 AM, Mike Hearn wrote:

 We could however introduce a new field in a new tx version. We know we
 need to rev the format at some point anyway.


 On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik jgar...@bitpay.com wrote:

  ...and existing users and uses of nLockTime suddenly become worthless,
 breaking payment channel refunds and other active uses of nLockTime.

 You cannot assume the user is around to rewrite their nLockTime, if it
 fails to be confirmed before some arbitrary deadline being set.



 On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding t...@thinlink.com wrote:

 ...


  If nLockTime is used for expiration, transaction creator can't lie to
 help tx live longer without pushing initial confirmation eligibility
 into the future.  Very pretty.  It would also enable fill or kill
 transactions with a backdated nLockTime, which must be confirmed in a
 few blocks, or start vanishing from mempools.





-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Jeff Garzik
A fork is not necessarily required, if you are talking about information
that deals primarily with pre-consensus mempool behavior.  You can make a
network TX with some information that is digitally signed, yet discarded
before it reaches miners.


On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd p...@petertodd.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256



 On 6 August 2014 08:17:02 GMT-07:00, Christian Decker 
 decker.christ...@gmail.com wrote:
 +1 for the new field, overloading fields with new meaning is definitely
 not
 a good idea.

 To add a new field the best way to do it is create a new, parallel, tx
 format where fields are committed by merkle radix tree in an extensible and
 provable way. You'd then commit to that tree with a mandatory OP_RETURN
 output in the last txout, or with a new merkle root.

 Changing the tx format itself in a hard-fork is needlessly disruptive, and
 in this case, wastes opportunities for improvement.
 -BEGIN PGP SIGNATURE-
 Version: APG v1.1.1

 iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
 Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
 //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
 RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
 sJKN
 =oPSo
 -END PGP SIGNATURE-




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Jeff Garzik
That won't necessarily work through large reorgs.  You don't want to create
a situation where a miner cannot mine a previously mined transactions.



On Wed, Aug 6, 2014 at 1:02 PM, Tom Harding t...@thinlink.com wrote:


 Today we have first-eligible-height (nLockTime), and mempool expiration
 measured from this height would work for the goals being discussed, no fork
 or protocol rev.

 With first-eligible-height and last-eligible-height, creator could choose
 a lifetime shorter than the max,  and in addition, lock the whole thing
 until some point in the future.



 On 8/6/2014 9:15 AM, Jeff Garzik wrote:

 A fork is not necessarily required, if you are talking about information
 that deals primarily with pre-consensus mempool behavior.  You can make a
 network TX with some information that is digitally signed, yet discarded
 before it reaches miners.


 On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd p...@petertodd.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256



 On 6 August 2014 08:17:02 GMT-07:00, Christian Decker 
 decker.christ...@gmail.com wrote:
 +1 for the new field, overloading fields with new meaning is definitely
 not
 a good idea.

  To add a new field the best way to do it is create a new, parallel, tx
 format where fields are committed by merkle radix tree in an extensible and
 provable way. You'd then commit to that tree with a mandatory OP_RETURN
 output in the last txout, or with a new merkle root.

 Changing the tx format itself in a hard-fork is needlessly disruptive,
 and in this case, wastes opportunities for improvement.
 -BEGIN PGP SIGNATURE-
 Version: APG v1.1.1

 iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
 Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
 //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
 RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
 sJKN
 =oPSo
 -END PGP SIGNATURE-




 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/


 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the 
 future.http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk



 ___
 Bitcoin-development mailing 
 listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] How to create a pull tester JAR

2014-08-05 Thread Jeff Garzik
Thanks for posting that (and implicitly archiving the knowledge).  Anything
that makes test improvement easier is welcomed.



On Tue, Aug 5, 2014 at 11:00 AM, Mike Hearn m...@plan99.net wrote:

 I just checked in a change to bitcoinj git master that makes it much
 easier to create a pull tester jar. Here are instructions for how to do it.

 You will need:

- A Java Development Kit (JDK), version 6 or up should work. As Java 6
was released eight years ago, this should not be a challenging requirement.
If you have a Mac just running java from the command line should give you
a GUI prompt to install it automatically. Otherwise apt-get or fetch the
latest from the interwebs.

- Apache Maven. This is a rough equivalent of autotools, except it
does dependency resolution for you. Grab it from
http://maven.apache.org/download.cgi then unzip it and make sure the
bin directory is in your PATH. You may need to set the JAVA_HOME
environment variable if you installed Java to an odd place.

- git

 Make sure you can run javac from the command line, then make sure you
 can run mvn, it should complain it can't find a POM (this is a build
 config file) and not, say, that it can't find Java.

 Now grab bitcoinj from git master:

 git clone https://github.com/bitcoinj/bitcoinj.git

 ... and build 

 cd bitcoinj
 mvn -DskipTests package

 It will go off and download the libraries needed, compile, and create a
 bundled executable JAR called core/target/pull-tests.jar. This is sort of
 analogous to static linking in the Java world. It should be fast - expect a
 full build plus downloads to take less than a minute. You can use it either
 with the QA scripts in the bitcoin core qa/pull-tester directory or just
 run things directly:

 ./bitcoind -regtest -connect=0.0.0.0 -listen -whitelist=127.0.0.1
 -datadir=/tmp/pulltester
 java -jar core/target/pull-tests.jar

 It should go ahead and print lots of debug spew, then at the end say it's
 happy.

 Let me know if you encounter any problems with this.

 Java JARs (which are just zip files renamed) are easily reproduced if you
 use the same version of javac and the same bitcoinj version. The ZIP
 container has timestamps, but unzipping them and simply diffing the files
 between two builds should reveal no differences. I am happy to provide a
 pull-tests.jar from my local machine if anyone would like to do this.


 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

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




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-08-05 Thread Jeff Garzik
Glad this was brought up.

Transaction expiration is something that I have wanted to see happen in
bitcoin for a long, long time.  The user experience of unconfirming
transactions setting around in limbo is just horrible.  Bitcoin software by
necessity has gotten better about attaching fees so this sort of behavior
is uncommon, but that does not eliminate the problem.

Of course, we cannot presume that a transaction will truly disappear -- The
Internet Never Forgets -- but given a bit of mempool adjusting, we can
achieve the next best thing:  the majority of the network forgets the
transaction and becomes willing to relay a respend of some or all of the
inputs.  This uses existing client logic where the client must rebroadcast
a transaction until it is confirmed.

In general, if a transaction has not made it into a block within 144*X
blocks, there is _some_ reason it is getting rejected by the miners.

The mempool janitor is a garbage collector design.  This is inferior to the
superblock model described at
https://github.com/bitcoin/bitcoin/issues/3723   Other models can also
achieve similar results.

There are a lot of issues tied together here:  transaction expiration, the
desire to cap the mempool ram usage, scalability, DoS prevention, ...
mempool ties a lot together.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-08-05 Thread Jeff Garzik
I feel like a lot of this will be driven by implementation, and costs of
changing the implementation.  Additional look-backs are of course doable,
but they incur some disk I/O costs.  The fields available in memory for
each mempool TX are

uint256 tx_hash; // hash of next field
CTransaction tx;
int64_t nFee; // Cached to avoid expensive parent-transaction lookups
size_t nTxSize; // ... and avoid recomputing tx size
int64_t nTime; // Local time when entering the mempool
double dPriority; // Priority when entering the mempool
unsigned int nHeight; // Chain height when entering the mempool

As a first pass, we may prune the mempool without additional db lookups
quite easily based on time criteria.  Or, additional in-memory indexes may
be constructed to maintain hashes ordered by priority/fees.

Those techniques seem likely to be attempted before resorting to looking
back two or three TXs deep at coin age -- which I admit is an interesting
metric.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-08-05 Thread Jeff Garzik
On Tue, Aug 5, 2014 at 3:10 PM, Kaz Wesley kezi...@gmail.com wrote:

 Any approach based on beginning a transaction expiry countdown when a
 transaction is received (as in mempool janitor) seems unviable to me:

...

 That's why I think including information in the transaction itself, as
 with my nLockTime/IsStandard proposal, is necessary for transactions
 to reliably eventually die off from mempools.


reliably die off from mempools leads into the land of tightly
synchronizing memory pools across the network which is a problem of...
large scope and much debate.  :)

For the moment, simply capping the mempool's size at each local node is a
much more reachable goal.  Capping, then, implies some culling policy.  In
general, bitcoind Tx mempool size is rather open ended, and that needs
sorting out.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Abusive and broken bitcoin seeders

2014-07-30 Thread Jeff Garzik
Seeing this on one of my public nodes:
2014-07-30 13:13:26 receive version message:
/getaddr.bitnodes.io:0.1/: version 70001, blocks=313169,
us=162.219.2.72:8333, peer=11847
2014-07-30 13:13:33 receive version message:
/getaddr.bitnodes.io:0.1/: version 70001, blocks=29,
us=162.219.2.72:8333, peer=11848
2014-07-30 13:14:21 receive version message:
/getaddr.bitnodes.io:0.1/: version 70001, blocks=313169,
us=162.219.2.72:8333, peer=11849

That is abusive, taking up public slots.  There is no reason to
connect so rapidly to the same node.

Other seeders are also rapidly reconnect'ers, though the time window
is slightly more wide:
2014-07-30 13:09:35 receive version message: /bitcoinseeder:0.01/:
version 6, blocks=23, us=162.219.2.72:8333, peer=11843
2014-07-30 13:12:42 receive version message: /bitcoinseeder:0.01/:
version 6, blocks=23, us=162.219.2.72:8333, peer=11846

The version message helpfully tells me my own IP address but not theirs ;p

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Time

2014-07-24 Thread Jeff Garzik
Miners are free to set the block's timestamp to whatever they please,
within a certain +/- time window.  Time might even go backwards a tiny
bit from the last block to the next block.


On Thu, Jul 24, 2014 at 9:14 PM, Ron OHara ron.ohar...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I thought I should shortcut my research by asking a direct question here.

 As I understand it, the blockchain actually provides an extra piece of
 reliable data that is not being exploited by applications.

 Which data?  The time.   In this case 'the time' as agreed by 50% of
 the participants, where those participants have a strong financial
 incentive to keep that 'time' fairly accurate. (+/- about 10 minutes)

 Is this a reasonable understanding of 'time'? ... aka timestamps on the
 block

 Ok... 'time' on the blockchain could be 'gamed' ... but with great
 difficulty. An application presented with a fake blockchain can use
 quite a few heuristics to test the 'validity' of the block chain.
 It can review the usual cryptographic proofs, and check that difficulty
 is growing/declining only in a realistic manner up to the most recent
 block. Even use some arbitrary test like difficulty  10,000,000,000
 ... on the presumption that any less means that the Bitcoin system has
 failed massively from where it currently is and has become an unreliable
 time source.

 Reliable 'time' has been impossible up until now - because you need to
 trust the time source, and that can always be faked.  Using the
 blockchain as an approximate time source gives you a world wide
 consensus without direct trust of any player.

 So if this presumption is correct, then we can now build time capsule
 applications that can not be tricked into exposing their contents too
 early by running them in a virtual environment with the wrong system time.

 Is this right? or did miss I something fundamental?

 Ron

 - --
 public identify: https://www.onename.io/ron_ohara
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.20 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc
 JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl
 oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL
 q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4
 hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k
 X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc=
 =T5fw
 -END PGP SIGNATURE-


 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralizing ming

2014-07-18 Thread Jeff Garzik
Before they got traction, yes.  But he projected a bit, as anyone
could, to see the trend.

On Thu, Jul 17, 2014 at 1:22 PM, slush sl...@centrum.cz wrote:

 On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik jgar...@bitpay.com wrote:

 Historical note:  On one hand, Satoshi seemed to dislike the early
 emergence of GPU mining pools quite a bit.


 To my knowledge, Satoshi left the project before mining pools got a
 traction.

 slush



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralizing ming

2014-07-18 Thread Jeff Garzik
Yes.  That, and several other things.  If you can figure out how to
propagate a block without re-propagating all the transactions everyone
already has, you address the large-blocks-slower-to-relay problem, and
additionally create an incentive for miners to mine blocks consisting
of publicly broadcast transactions (versus a bunch of secret ones
mined with secret agreements).

Democratizing transaction selection takes a bit of power away from the
miners and gives it back to the network at large.  GBT is another
piece of that puzzle.


On Fri, Jul 18, 2014 at 6:43 AM, Mike Hearn m...@plan99.net wrote:
 Oops, sorry, I see the subject line changed. This is what I get for working
 down the thread list top to bottom :)

 I think the best path forward now is to finish off getblocktemplate support
 in the various tools so it's possible to pool for payout purposes without
 giving up control of block creation modulo the coinbase. Combined with the
 recent sipa performance enhancing goodness, it would hopefully persuade some
 non-trivial chunk of hashpower to go back to running their own node and
 start the process of turning pools merely into payout trackers rather than
 block selectors.


 On Fri, Jul 18, 2014 at 12:41 PM, Mike Hearn m...@plan99.net wrote:

 Jeff, I think the message you're replying to got clipped.

 Satoshi's only comment AFAIK on the topic of GPU mining was to wish for a
 gentlemen's agreement to postpone it as long as possible, to help make sure
 the distribution of coins was as even as possible. Indeed this predated
 pooled mining.





-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-18 Thread Jeff Garzik
On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen gavinandre...@gmail.com wrote:
 I'd encourage you to code up a prototype first (or at the same time), in
 whatever programming language / networking library you're most familiar
 with.

+1

 Maybe not even using the existing p2p protocol; there could be a mining-only
 very-fast-block-propagation network separate from the existing p2p network.

 Combining your optimizations with broadcast as many near-miss blocks as
 bandwidth will allow on a mining backbone network should allow insanely
 fast propagation of most newly solved blocks.


Yes, I would encourage thinking along these lines.  That was the
motivation of the UDP P2P protocol extension I wrote:
https://bitcointalk.org/index.php?topic=156769.0

The intention was to experiment with sending block header + tx list +
coinbase, via UDP best effort broadcast.

Incentives:

If your neighbors receiving this message already have the TXs in the
TX list, then the block is complete, and may be relayed further.

If your neighbors do not have all TXs in the block, they must fetch
them at additional time/latency cost.

Thus, you have an incentive to relay blocks containing TXs already
distributed out into network mempools and cached in the signature
cache.

We want to capture that incentive in whatever protocol is eventually
used.  Miners have a TX fee incentive to include many transactions.
In theory, they want to include as many TX as possible.  It will help
us scale quite a bit to solve this problem.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-18 Thread Jeff Garzik
On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen
gavinandre...@gmail.com wrote:
 But if there was some agreed-upon canonical ordering, then it should
 theoretically be possible to take shortcuts in the what order.

 You'd start with setof(transactions I think everybody knows about)
 Select some subset, based on miner's policy
 Sort that subset with the canonical ordering algorithm
 Very efficiently broadcast, taking all sorts of shortcuts assuming most of
 your peers already know the set you started with and expect the same
 canonical ordering (see gmaxwell's thoughts on block encoding).

Related implementation detail:  Having pursued this train of thought,
I noted that you don't want to include too-young transactions that you
received in the past few seconds, because those are likely still
propagating around the network.

 Second half-baked thought:
 I wonder if broadcasting your transaction selection policy (11KB of free
 transactions, sorted by priority, then 111K of fee-paying transactions,
 sorted by fee) might make it possible to save even more bandwidth by
 letting your peers create a very good approximation of your block with just
 that information

Absolutely.  One path I would like to see pursued is multiple
p2pool-esque chains.  Each with their own policy, perhaps with their
own administrative team.  ie. you could have a fully decentralized
p2pool-like chain, or multiple such chains, each with a stated
policy/reward pattern.  Or, GHash/BTCGuild/Eligius could run a
semi-centrally managed chain ultimately guaranteed not only by
protocol but by administrators' digital signatures.

In each case, advertising technical attributes about your pool [chain]
policy would give nodes the better ability to predict what is in an
upcoming block.

And the flip side of that, such predictions are never perfect.  Need
to make sure the fallback case, while undoubtedly more costly than the
Fast Path, is not overly painful.


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


  1   2   3   4   >