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

2015-06-18 Thread Melvin Carvalho
On 18 June 2015 at 12:00, Mike Hearn m...@plan99.net wrote:

 Dude, calm down. I don't have commit access to Bitcoin Core and Gavin
 already said long ago he wouldn't just commit something, even though he has
 the ability to do so.

 So why did I say it? Because it's consistent with what I've always said:
  you cannot run a codebase like Wikipedia. Maintainers have to take part in
 debates, and then make a decision, and anyone else who was delegated commit
 access for robustness or convenience must then respect that decision. It's
 the only way to keep a project making progress at a reasonable pace.

 This is not a radical position. That's how nearly all coding projects
 work. I have been involved with open source for 15 years and the 'single
 maintainer who makes decisions' model is normal, even if in some large
 codebases  subsystems have delegated submaintainers.

 This is also how all my own projects are run. Bitcoinj has multiple people
 with commit access. Regardless, if there were to be some design dispute or
 whatever, I wouldn't tolerate the others with commit access starting some
 kind of Wiki-style edit war in the code if they disagreed. Nor would I ever
 expect to get my own way in other people's projects by threatening to
 revert the maintainers changes.

 Core is in the weird position where there's no decision making ability at
 all, because anyone who shows up and shouts enough can generate
 'controversy', then Wladimir sees there is disagreement and won't touch the
 issue in question. So it just runs and runs and *anyone* with commit
 access can then block any change.

 I realise some people think this anti-process leads to better decision
 making. I disagree. It leads to no decision making, which is not the same
 thing at all.


Bicoin is not like other projects.  There are large financial stakes
involved.  I was at a standards convention once and the head of standards
at a large company joked to me:

We know there are 6 people in the standards world that we can never buy.
So we just buy everyone else.

You have to luck out in a huge way to get a person like that running your
project.  Linux has done.  Id say bitcoin has been lucky there too.  But
have a look at other projects, have a look at the alts, the *last* thing
you want is a dictator in may cases.

Ultimately bitcoin is a ledger based on consensus.  There are 3 branches,
the miners, the protocol and the market.  They all play a role in
regulating bitcoin and generally on the conservative side (which I think is
a good thing).  Whatever your view on the 20MB change, it's not a
*conservative* approach, which is the approach that has served bitcoin very
well so far.

So bitcoin is not like other open source projects, and that's probably
quite a good thing.




 --

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


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


Re: [Bitcoin-development] Long-term mining incentives

2015-05-13 Thread Melvin Carvalho
On 11 May 2015 at 18:28, Thomas Voegtlin thom...@electrum.org wrote:

 The discussion on block size increase has brought some attention to the
 other elephant in the room: Long-term mining incentives.

 Bitcoin derives its current market value from the assumption that a
 stable, steady-state regime will be reached in the future, where miners
 have an incentive to keep mining to protect the network. Such a steady
 state regime does not exist today, because miners get most of their
 reward from the block subsidy, which will progressively be removed.

 Thus, today's 3 billion USD question is the following: Will a steady
 state regime be reached in the future? Can such a regime exist? What are
 the necessary conditions for its existence?

 Satoshi's paper suggests that this may be achieved through miner fees.
 Quite a few people seem to take this for granted, and are working to
 make it happen (developing cpfp and replace-by-fee). This explains part
 of the opposition to raising the block size limit; some people would
 like to see some fee pressure building up first, in order to get closer
 to a regime where miners are incentivised by transaction fees instead of
 block subsidy. Indeed, the emergence of a working fee market would be
 extremely reassuring for the long-term viability of bitcoin. So, the
 thinking goes, by raising the block size limit, we would be postponing a
 crucial reality check. We would be buying time, at the expenses of
 Bitcoin's decentralization.

 OTOH, proponents of a block size increase have a very good point: if the
 block size is not raised soon, Bitcoin is going to enter a new, unknown
 and potentially harmful regime. In the current regime, almost all
 transaction get confirmed quickly, and fee pressure does not exist. Mike
 Hearn suggested that, when blocks reach full capacity and users start to
 experience confirmation delays and confirmation uncertainty, users will
 simply go away and stop using Bitcoin. To me, that outcome sounds very
 plausible indeed. Thus, proponents of the block size increase are
 conservative; they are trying to preserve the current regime, which is
 known to work, instead of letting the network enter uncharted territory.

 My problem is that this seems to lacks a vision. If the maximal block
 size is increased only to buy time, or because some people think that 7
 tps is not enough to compete with VISA, then I guess it would be
 healthier to try and develop off-chain infrastructure first, such as the
 Lightning network.

 OTOH, I also fail to see evidence that a limited block capacity will
 lead to a functional fee market, able to sustain a steady state. A
 functional market requires well-informed participants who make rational
 choices and accept the outcomes of their choices. That is not the case
 today, and to believe that it will magically happen because blocks start
 to reach full capacity sounds a lot like like wishful thinking.

 So here is my question, to both proponents and opponents of a block size
 increase: What steady-state regime do you envision for Bitcoin, and what
 is is your plan to get there? More specifically, how will the
 steady-state regime look like? Will users experience fee pressure and
 delays, or will it look more like a scaled up version of what we enjoy
 today? Should fee pressure be increased jointly with subsidy decrease,
 or as soon as possible, or never? What incentives will exist for miners
 once the subsidy is gone? Will miners have an incentive to permanently
 fork off the last block and capture its fees? Do you expect Bitcoin to
 work because miners are altruistic/selfish/honest/caring?

 A clear vision would be welcome.


I am guided here by Satoshi's paper:

Commerce on the Internet has come to rely almost exclusively on financial
institutions serving as trusted third parties to process electronic
payments. While the system works well enough for *most transactions*

This suggests to me that most tx will occur off-block with the block chain
used for settlement.  Indeed Satoshi was working on a trust based market
before he left.

If commerce works well enough off-block with zero trust settlement
supporting it, people might even forget that the block chain exists, like
with gold settlement.  But it can be used for transactions.  To this end I
welcome higher fees, so that the block chain becomes the reserve currency
of the internet and is used sparingly.

But as Gavin pointed out, bitcoin is still an experiment and we are all
still learning.  We are also learning from alt coin mechanisms.  I am
unsure there is huge urgency here, and would lean towards caution as
bitcoin infrastructure rapidly grows.




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

Re: [Bitcoin-development] [ANN] METAmarket - Trustless Federated Marketplaces

2015-05-01 Thread Melvin Carvalho
On 2 May 2015 at 00:57, Marc D. Wood metam...@metamarket.biz wrote:

 METAmarket: Trustless Federated Marketplaces
  http://metamarket.biz 

 * * *
 Introduction

 METAmarket is an open source protocol and proof-of-concept reference
 client specifying a trustless federated marketplace which uses Bitcoin as
 a universal currency and Bitmessage as a P2P communication network.
 Time-locked refund transactions ensure that incentives are aligned toward
 completing the trade without the need for trusted third parties. Systemic
 vulnerabilities such as transaction malleability are mitigated through the
 use of a federated reputation model. This document is a non-technical
 overview of how the METAmarket client and protocol work. For more
 technical details, see the protocol specification.

 Motivation

 Overly centralized marketplaces and payment services extract high fees,
 impose and abuse excessive control and remove any hope of privacy from
 users. As more commerce moves online, many consumers may find their
 lifetime history of purchases (including books, personal items and
 location details) for sale to advertisers, employers, curious neighbors,
 stalkers, political opponents and government agencies. An ideal system
 would be one of secure private transactions directly between buyer and
 seller without middle men collecting data or adding fees. Such systems are
 now feasible by combining recently developed technologies for anonymous
 decentralized payment and messaging systems.

 Client

 To use the marketplaces, a client application which implements the
 METAmarket protocol is required. The client is used to post, browse and
 execute trades. It also requires a Bitcoin Core wallet to handle payments
 and refunds. A working client is available at:

 http://github.com/metamarcdw/metamarket


Is there any relation between this and the work satoshi was putting into
the core before he left?

https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8





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

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


Re: [Bitcoin-development] Running a full node

2014-11-08 Thread Melvin Carvalho
On 8 November 2014 16:28, Daniel F nanot...@gmail.com wrote:

  But I'd like to know what storage, RAM  and bandwidth resources are
  needed. I guess that the problem is not the CPU.

 Hi Francis,

 Here are some rough guidelines for you, based on the statistics from my
 node:

 disk usage: about 30GB currently for the blockchain data. It'll only
 keep growing from here, but relatively slowly.


There's some statistics on this site:

https://blockchain.info/charts/blocks-size

It may be reasonable to assume 10GB growth a year.  When I was running a
full node I gave it a disk of 50GB.



 cpu usage: pretty much nothing, after you have synced the blockchain.

 ram usage: after it runs for a few months, my node gets up to using 1.5
 GB of ram or so.

 bandwidth usage: my node averages about 500GB of traffic per month, most
 of it outgoing.

 Hope that gives you a rough idea of what you can expect for running full
 node.

 Best,
 Daniel



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

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


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

2014-10-31 Thread Melvin Carvalho
On 22 October 2014 23:54, Adam Back a...@cypherspace.org wrote:

 For those following this thread, we have now written a paper
 describing the side-chains, 2-way pegs and compact SPV proofs.
 (With additional authors Andrew Poelstra  Andrew Miller).

 http://blockstream.com/sidechains.pdf


A very well written paper, thank you for putting it together and sharing.

Given it's the 6 year birthday of satoshi's white paper, I just read
through it again.

I find it interesting that bitcoin is never defined in Satoshi's paper,
indeed, it never appears after the first word.

The term Electronic Coin is defined.

The terminology of bitcoin / altcoin / altchain / blockchain in this paper
still leaves me slightly uneasy, and I try to use the terms electronic coin
and electronic cash, more often.

If satoshi were to come back and continue his work, would it be an altcoin,
would it be The blockchain, would it be bitcoin, or would what we know as
bitcoin become an alt.  I suspect these questions are nothing more than
academic curiosity.

But I think I'll get more used to it over time :)

In any case, happy birthday bitcoin :)



 Adam

 On 16 March 2014 15:58, Adam Back a...@cypherspace.org wrote:
  So an update on 1-way pegging (aka bitcoin staging, explained in quoted
 text
  at bottom): it turns out secure 2-way pegging is also possible (with some
  bitcoin change to help support it).  The interesting thing is this allows
  interoperability in terms of being able to move bitcoin into and out of a
  side chain.  The side chains may have some different parameters, or
  experimental things people might want to come up with (subject to some
  minimum compatibility at the level of being able to produce an SPV proof
 of
  a given form).
 
  At the time of the 1-way peg discussion I considered 2-way peg as
 desirable
  and it seemed plausible with bitcoin changes, but the motivation for
 1-way
  peg was to make it less risky to make changes on bitcoin, so that seemed
  like a catch-22 loop.  Also in the 2-way peg thought experiment I had not
  realized how simple it was to still impose a security firewall in the
 2-way
  peg also.
 
 
  So Greg Maxwell proposed in Dec last year a practically compact way to do
  2-way pegging using SPV proofs.  And also provided a simple argument of
 how
  this can provide a security firewall.  (Security firewall means the
 impact
  of security bugs on the side-chain is limited to the people with coins in
  it; bitcoin holders who did not use it are unaffected). [1]
 
  How it works:
 
  1. to maintain the 21m coins promise, you start a side-chain with no
  in-chain mining subsidy, all bitcoin creation happens on bitcoin chain
 (as
  with 1-way peg).  Reach a reasonable hash rate.  (Other semantics than
 1:1
  peg should be possible, but this is the base case).
 
  2. you move coins to the side-chain by spending them to a fancy script,
  which suspends them, and allows them to be reanimated by the production
 of
  an SPV proof of burn on the side-chain.
 
  3. the side-chain has no mining reward, but it allows you to mint coins
 at
  no mining cost by providing an SPV proof that the coin has been
 suspended as
  in 2 on bitcoin.  The SPV proof must be buried significantly before being
  used to reduce risk of reorganization.  The side-chain is an SPV client
 to
  the bitcoin network, and so maintains a view of the bitcoin hash chain
 (but
  not the block data).
 
  4. the bitcoin chain is firewalled from security bugs on the side chain,
  because bitcoin imposes the rule that no more coins can be reanimated
 than
  are currently suspend (with respect to a given chain).
 
  5. to simplify what they hypothetical bitcoin change would need to
 consider
  and understand, after a coin is reanimated there is a maturity period
  imposed (say same as fresh mined coins).  During the maturity period the
  reanimation script allows a fraud proof to spend the coins back.  A fraud
  bounty fee (equal to the reanimate fee) can be offered by the mover to
  incentivize side-chain full nodes to watch reanimations and search for
 fraud
  proofs.
 
  6. a fraud proof is an SPV proof with a longer chain showing that the
 proof
  of burn was orphaned.
 
  There are a few options to compress the SPV proof, via Fiat-Shamir
 transform
  to provide a compact proof of amount work contained in a merkle tree of
  proofs of work (as proposed by Fabien Coelho link on
  http://hashcash.org/papers/) with params like 90% of work is proven.
 But
  better is something Greg proposed based on skip-lists organized in a
 tree,
  where 'lucky' proofs of work are used to skip back further.  (Recalling
 that
  if you search for a 64-bit leading-0 proof-of-work, half the time you
 get a
  65-bit, quarter 66-bit etc.)  With this mechanism you can accurately
  prove the amount of proof of work in a compressed tree (rather than
 ~90%).
 
 
  Apart from pegging from bitcoin to a side-chain, if a private chain is
 made
  with same rules 

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

2014-10-27 Thread Melvin Carvalho
On 27 October 2014 08:49, Wladimir laa...@gmail.com wrote:

 On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho
 melvincarva...@gmail.com wrote:

  Firstly, apologies in coming in late to the conversation.  As I am also
  working on a REST API for electronic coins.  Some questions:
 
  1. Is there a BIP, or some other doc (e.g. gist), outlining the REST
 output
  e.g. the response format and MIME types.  Or just compile from source?

 See the opening post from @jgarzik, it has some documentation on how
 to use the API.

 It would be nice to have some write-up about the current functionality
 in the release notes, but there currently is none.

 It's a RPC-side change, not a P2P-side change so it doesn't require a BIP.


Thanks.  Yes, I worked this out after looking at the code.

I would be happy to help with documentation.



  2. How set in stone is v1 of the the going forward?  PS I support
 @maaku's
  comments re: /api/v1/ -- tho I guess it is too late for that now.
  3. Would there be any support to develop this interface into something
 that
  would be W3C standards compliant, or reviewed by the REST community.  So
 for
  example a context can be provided to self document the terms (something
 I've
  almost completed) and would allow standardization of block explorer and
  bitcoind outputs.  Right now every explorer seems to have a different
 JSON
  output.

 It's not too late, it's not been merged yet.

 Though a W3C standard takes a long time to pan out, and it may be more
 useful to have this available rather than wait for the API to be
 standardized (which means this will need to be postponed at least one
 version). As you say, a new interface be added later under another
 URI.


Agree.  I think these changes are great for 0.10.



 Note that we're only interested in exposing read-only, public data
 which is already available in Bitcoin Core's internals.
 We're not aiming to add a fully-fledged block explorer with (say)
 address indexes. Although that could be part of the standard if it
 allows implementations to support just a subset.


Got it thanks.



 Anyhow - please coordinate this with Jeff Garzik, it's better to work
 together here.


Will do.  Work in this area is ongoing, both in terms of
coding/patches/testing and documentation.

Do you think it would a reasonable idea to put down some thoughts and
proposals in a BIP?



 Wladimir

--
___
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 Melvin Carvalho
On 25 October 2014 21:53, Alex Mizrahi alex.mizr...@gmail.com wrote:


 We had a halving, and it was a non-event.
 Is there some reason to believe next time will be different?


 Yes.

 When the market is rapidly growing, margins can be relatively high because
 of limited amounts of capital being invested, or introduction of more
 efficient technologies.

 However, we should expect market to become more mature with time, and a
 mature market will result in lower margins.
 The halving can do much more damage when margins are relatively small.

 Besides that, there is a difference in ecosystem maturity:

 1. Back in 2012, miners weren't so focused on profits, as Bitcoin was
 highly experimental: some were mining for the hell of it (it was a novelty
 thing back then), others wanted to secure the network, others did it
 because it was hard to obtain bitcoins by other means. But now miners are
 mostly profit-motivated: they buy expensive dedicated mining equipment and
 want to maximize profits. As you might know, at one point ghash.io
 reached 50% hashrate, and miners didn't care about it enough to switch to a
 different pool.

 2. Back in 2012, we didn't have multipools. Multipools automatically
 switches between mining different alt-chains to maximize miners' profits.
 Miners who use multipools do not care how their hashrate is used as long as
 they profit off it.
 Particularly, check https://nicehash.com/ -- you can easily buy hashrate
 to attack a smaller alt-coin, for example.

 If the halving will result in a significant hashrate drop (and we did
 observe hashrate drop in 2012, although it wasn't that big), it might be
 possible to buy enough hashpower to attack Bitcoin.


This is a good point, imho.  Miner sophistication has increased drastically
in 2 years.  Sites like ( http://www.coinwarz.com/ ) can heavily influence
mining, 1-2 orders of magnitude on significant levels of hashing.

I think this is more prevalent with scrypt than sha256, litecoin is set to
half reward in 9 months, and it will be interesting to observe what happens
there.





 --

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


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


Re: [Bitcoin-development] death by halving

2014-10-25 Thread Melvin Carvalho
On 26 October 2014 00:10, Ross Nicoll j...@jrn.me.uk wrote:

  I'd suggest looking at how Dogecoin's mining schedule has worked out, for
 how halvings tend to actually affect the market. Part of Dogecoin's design
 was that it would halve very quickly (around every 75 days, in fact), so
 it's essentially illustrating worst case scenario.


Yes that is an interesting data point, but it's really hard to find
comparables to doge, and most of its hashing is now merge mined with
litecoin.  Comparing doge to btc may be a case of apples and oranges.



 Firstly, miners do not all move/shut down as a batch. Some will stay out
 of loyalty/apathy/optimism, so there's a jolt to hashrate when the rewards
 drop, and then a drift towards a steady-state. In most cases, the hardware
 costs vastly exceed the running costs, so while they may never see ROI due
 to the reward change, there's no benefit in stopping mining either.

 On the other side, mining hardware update cycles are extremely aggressive,
 and newer hardware runs much faster. Further, those with newer hardware are
 likely to have the best hashrate to power ratio, and be less likely to turn
 off or rent out their hardware.

 So, in theory there may be an uncomfortable period where the hashrate
 drops, but I would expect that drop to be much less than 50%, that most
 hardware that's turned off is not cost-effective to rent out, and that
 newer hardware being launched would push the hashrate back up again within
 a sensible timeframe.

 Ross



 On 25/10/2014 19:06, Alex Mizrahi wrote:

  # Death by halving

  ## Summary

  If miner's income margin are less than 50% (which is a healthy situation
 when mining hardware is readily available), we might experience
 catastrophic loss of hashpower (and, more importantly, catastrophic loss of
 security) after reward halving.

  ## A simple model

  Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
 total revenue miner receives over a period of time, and C_e is the cost of
 electricity spent on mining over the same period of time. (Note that for
 the sake of simplicity we do not take into account equipment costs,
 amortization and other costs mining might incur.)

  Also we will assume that transaction fees collected by miner are
 negligible as compared to the subsidy.

  Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
 halving and bitcoin and electricity prices stay the same, then mining is no
 longer profitable after the halving.

  Indeed, suppose the revenue after the halving is R' = R/2.
MIM = (R-C_e)/R  0.5
R/2  C_e.

 R' = R/2  C_e.

  If revenue after halving R' doesn't cover electricity cost, a rational
 miner should stop mining, as it's cheaper to acquire bitcoins from the
 market.

  ~~~

  Under these assumptions, if the majority of miners have MIM less than
 0.5, Bitcoin is going to experience a significant loss of hashing power.
 But are these assumptions reasonable? We need a study a more complex model
 which takes into account changes in bitcoin price and difficulty changes
 over time.
 But, first, let's analyze significance of 'loss of hashpower'.

  ## Catastrophic loss of hashpower

  Bitcoin security model relies on assumption that a malicious actor
 cannot acquire more than 50% of network's current hashpower.
 E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
 Spending_ paper which shows that as long as the malicious actor controls
 only a small fraction of total hashpower, attacks have well-define costs.
 But if the attacker-controlled hashrate is higher than 50%, attacks become
 virtually costless, as the attacker receives double-spending revenue on top
 of his mining revenue, and his risk is close to zero.

  Note that the simple model described in the aforementioned paper doesn't
 take into account attack's effect on the bitcoin price and the price of the
 Bitcoin mining equipment. I hope that one day we'll see more elaborate
 attack models, but in the meantime, we'll have to resort to hand-waving.

  Consider a situation where almost all available hashpower is available
 for a lease to the highest bidder on the open market. In this case someone
 who owns sufficient capital could easily pull off an attack.

  But why is hashpower not available on the market? Quite likely equipment
 owners are aware of the fact that such an attack would make Bitcoin
 useless, and thus worthless, which would also make their equipment
 worthless. Thus they prefer to do mining for a known mining pools with good
 track record.
 (Although hashpower marketplaces exist: https://nicehash.com/ they aren't
 particularly popular.)

  Now let's consider a situation where mining bitcoins is no longer
 profitable and the majority of hashpower became dormant, i.e. miners turned
 off their equipment or went to mine something else. In this case equipment
 is already nearly worthless, so people might as well lease it to the
 highest bidder, thus enabling 

Re: [Bitcoin-development] [ann] Bitcoin Core 0.9.3 has been released

2014-09-27 Thread Melvin Carvalho
On 27 September 2014 15:56, Wladimir laa...@gmail.com wrote:

 Bitcoin Core version 0.9.3 is now available from:

   https://bitcoin.org/bin/0.9.3/

 This is a new minor version release, bringing only bug fixes and updated
 translations. Upgrading to this release is recommended.

 Please report bugs using the issue tracker at github:

   https://github.com/bitcoin/bitcoin/issues

 Upgrading and downgrading
 ==

 How to Upgrade
 --

 If you are running an older version, shut it down. Wait until it has
 completely
 shut down (which might take a few minutes for older versions), then run the
 installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
 or
 bitcoind/bitcoin-qt (on Linux).

 If you are upgrading from version 0.7.2 or earlier, the first time you run
 0.9.3 your blockchain files will be re-indexed, which will take anywhere
 from
 30 minutes to several hours, depending on the speed of your machine.

 Downgrading warnings
 

 The 'chainstate' for this release is not always compatible with previous
 releases, so if you run 0.9.x and then decide to switch back to a
 0.8.x release you might get a blockchain validation error when starting the
 old release (due to 'pruned outputs' being omitted from the index of
 unspent transaction outputs).

 Running the old release with the -reindex option will rebuild the
 chainstate
 data structures and correct the problem.

 Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
 the blockchain for missing spent coins, which will take a long time (tens
 of minutes on a typical machine).

 0.9.3 Release notes
 ===

 RPC:
 - Avoid a segfault on getblock if it can't read a block from disk
 - Add paranoid return value checks in base58

 Protocol and network code:
 - Don't poll showmyip.com, it doesn't exist anymore
 - Add a way to limit deserialized string lengths and use it
 - Add a new checkpoint at block 295,000
 - Increase IsStandard() scriptSig length
 - Avoid querying DNS seeds, if we have open connections
 - Remove a useless millisleep in socket handler
 - Stricter memory limits on CNode
 - Better orphan transaction handling
 - Add `-maxorphantx=n` and `-maxorphanblocks=n` options for
 control over the maximum orphan transactions and blocks

 Wallet:
 - Check redeemScript size does not exceed 520 byte limit
 - Ignore (and warn about) too-long redeemScripts while loading wallet

 GUI:
 - fix 'opens in testnet mode when presented with a BIP-72 link with no
 fallback'
 - AvailableCoins: acquire cs_main mutex
 - Fix unicode character display on MacOSX

 Miscellaneous:
 - key.cpp: fail with a friendlier message on missing ssl EC support
 - Remove bignum dependency for scripts
 - Upgrade OpenSSL to 1.0.1i (see
 https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no
 critical issues for Bitcoin Core)
 - Upgrade miniupnpc to 1.9.20140701
 - Fix boost detection in build system on some platforms

 Credits
 

 Thanks to everyone who contributed to this release:

 - Andrew Poelstra
 - Cory Fields
 - Gavin Andresen
 - Jeff Garzik
 - Johnathan Corgan
 - Julian Haight
 - Michael Ford
 - Pavel Vasin
 - Peter Todd
 - phantomcircuit
 - Pieter Wuille
 - Rose Toomey
 - Ruben Dario Ponticelli
 - shshshsh
 - Trevin Hofmann
 - Warren Togami
 - Wladimir J. van der Laan
 - Zak Wilcox

 As well as everyone that helped translating on
 [Transifex](https://www.transifex.com/projects/p/bitcoin/).


Great work!

Apologies if this has been covered.  But I was curious about:

- Increase IsStandard() scriptSig length

Is there some place I read more to understand this change?




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

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


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

2014-09-15 Thread Melvin Carvalho
On 15 September 2014 09:23, Thomas Zander tho...@thomaszander.se wrote:

 On Sunday 14. September 2014 08.28.27 Peter Todd wrote:
  Do we have any evidence Satoshi ever even had access to that key? Did he
  ever use PGP at all for anything?

 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.

 I think that kind of disqualifies pgp for identity purposes wrt Satoshi :-)


But I presume that if the key is on bitcoin.org,  you can probably infer
that the owner of the key and the original owner of bitcoin.org are one and
the same ...



 --
 Thomas Zander


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

--
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] Mining Hashrate Caps

2014-07-17 Thread Melvin Carvalho
I noticed this article today.

GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit

http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/

Here's a quote from Satoshi when the mining arms race began:

We should have a gentleman’s agreement to postpone the GPU arms race as
long as we can for the good of the network. It’s much easer to get new
users up to speed if they don’t have to worry about GPU drivers and
compatibility. It’s nice how anyone with just a CPU can compete fairly
equally right now.

Maybe outdated now, but I thought it was interesting.
--
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] Proposal for extra nonce in block header

2014-04-27 Thread Melvin Carvalho
On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote:

 I'd like to put the following draft of a BIP up for discussion.

 Timo

 # Abstract
 There are incentives for miners to find cheap, non-standard ways to
 generate new work, which are not necessarily in the best interest of the
 protocol.
 In order to reduce these incentives this proposal re-assigns 2 bytes from
 the version field of the block header to a new extra nonce field.
 # Copyright
 # Specification
 The block version number field in the block header is reduced in size from
 4 to 2 bytes.
 The third and fourth byte in the block header are assigned to the new
 extra nonce field inside the block header.
 # Motivation
 The motivation of this proposal is to provide miners with a cheap
 constant-complexity method to create new work that does not require
 altering the transaction tree.

 Furthermore, the motivation is to protect the version and timestamp fields
 in the block header from abuse.
 # Rationale
 Traditionally, the extra nonce is part of the coinbase field of the
 generation transaction, which is always the very first transaction of a
 block.
 After incrementing the extra nonce the minimum amount of work a miner has
 to do to re-calculate the block header is a) to hash the coinbase
 transaction and b) to re-calculate the left-most branch of the merkle tree
 all the way to the merkle root.
 This is necessary overhead a miner has to do besides hashing the block
 header itself.
 We shall call the process that leads to a new block header from the same
 transaction set the _pre-hashing_.

 First it should be noted that the relative cost of pre-hashing in its
 traditional form depends
 on the block size, which may create an unwanted incentive for miners
 to keep the block size small. However, this is not the main motivation for
 the current proposal.

 While the block header is hashed by ASICs, pre-hashing typically happens
 on a CPU because of the greater flexibility required.
 Consequently, as ASIC cost per hash performance drops the relative cost of
 pre-hashing increases.

 This creates an incentive for miners to find cheaper ways to create new
 work than by means of pre-hashing.
 An example of this currently happening is the on-device rolling of the
 timestamp into the future.
 These ways of creating new work are unlikely to be in the best interest of
 the protocol.
 For example, rolling the timestamp faster than the real time is unwanted
 (more so on faster blockchains).

 The version number in the block header is a possible target for alteration
 with the goal of cheaply creating new work.
 Currently, blocks with arbitrarily large version numbers get relayed and
 accepted by the network.
 As this is unwanted behaviour, there should not exist any incentive for a
 miner to abuse the version number in this way.

 The solution is to reduce the range of version numbers from 2^32 to 2^16
 and to declare the third and forth bytes of the block header as legitimate
 space for an extra nonce.
 This will reduce the incentive for a miner to abuse the shortened version
 number by a factor in the order of 2^16.

 As a side effect, this proposal greatly reduces the bandwidth requirements
 of a blind pool protocol by only submitting the block header to the miner.
 # Backwards Compatibility
 Old versions of the client will accept blocks of this kind but will throw
 an alert at the user to upgrade.
 The only code change would be a cast of the version number to a short.
 Besides the upgrade alert, old and new versions of the client can co-exist
 and there is no need to introduce a new block version number or to
 phase-out old block versions.
 # Reference Implementation
 # Final implementation


If changing the structure of the block header, wouldnt you also need to
increment the version number to 3?



 --
 Timo Hanke
 PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8


 --
 Start Your Social Network Today - Download eXo Platform
 Build your Enterprise Intranet with eXo Platform Software
 Java Based Open Source Intranet - Social, Extensible, Cloud Ready
 Get Started Now And Turn Your Intranet Into A Collaboration Platform
 http://p.sf.net/sfu/ExoPlatform
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

2014-04-16 Thread Melvin Carvalho
On 16 April 2014 10:14, Wladimir laa...@gmail.com wrote:

 Hello,

 Today I noticed that even my bank is warning people to not do internet
 banking with Windows XP.

 If it is no longer secure enough for online banking it's CERTAINLY not
 secure enough to run a wallet (for a node only it would be ok-ish as they
 have no keys to protect).
 Any opinions on what to do here? Just warn and allow the user to continue?
 Redirect them to a 'Windows XP is dangerous' message on bitcoin.org?
 (Microsoft uses
 http://windows.microsoft.com/en-us/windows/end-support-help)

 The drawback of dropping XP support completely would be that a lot of
 computers (especially in China and Russia etc) are still running XP, so
 this could cause the network to lose nodes.


XP with a trezor would work fine tho?

My personal preference would be a warning, and to direct them to a free
software operating system that they could upgrade to.



 If you're maintainer of other wallet software: how are you handling this?
 Are you going to drop XP support completely? If so, starting from when?

 Regards,
 Wladimir



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin for W3C Payments Workshop, March 24-25

2014-03-19 Thread Melvin Carvalho
On 20 March 2014 02:41, Odinn Cyberguerrilla 
odinn.cyberguerri...@riseup.net wrote:

 I wish to state that I fundamentally disagree with this proposal of use
 cases for W3C payments workshop.  Please read my following explanation and
 then do what you will:

 At one time I was invited to join the Web Payments conference calls.  I
 considered it and then declined due to the very CLAs that Brent mentioned
 in the message that started this thread.

 I was trying to remember the language that I objected to relating to the
 W3C CLA.  Found it: https://web-payments.org/minutes/ As mentioned, I was
 offered to join these calls but I declined due to, in part, the following:
 Upon review of  the page at  web-payments.org, I noticed that it provides
 a means to connect with web payments group by teleconference.  However,
 there is an agreement that the site would require me to accept merely to
 join the teleconference and collaborate with others in the web payments
 group.  I would say unfortunately, but in my case I will say
 fortunately, I don't agree with the required agreement as shown here at
 http://www.w3.org/community/about/agreements/cla/ which is shown as
 follows at https://web-payments.org/minutes/ There are no costs
 associated with joining the group or limitations on who may join the
 teleconference as long as they agree to the Web Payments community 

 Some of the things I don't like about the proposed agreement /
 requirement are fundamental.  At the core, it should be understood that
 collaborative efforts, or teleconferences involving innovators who strive
 to develop concepts for eventual development of a social good, for
 example, should not be subject to a requirement that anyone agree to a
 license in relation to their participation or contribution.  Such
 requirements inhibit innovation and free thought.  For example, the web
 payments group provides that in order for me to participate, I must first
 agree to license my Essential Claims under the W3C CLA RF Licensing
 Requirements and numerous other requirements.

 Although I was interested in some sort of collaboration with the Web
 Payments Community Group, these CLAs - lengthy, burdensome, and in my
 personal view, highly dubious and potentially restricting with respect to
 innovation and free thought - caused me to reconsider, and thus I will not
 be entering into web or telephone conferences or related collaborations
 with the W3C / Web Payments folks until such time as they remove these
 burdensome requirements which are applied merely to join a call.


Fair point, but you need to understand that all specs created by the W3C
are committed to be royalty free.  That's why there's a CLA, but I can
totally see if you or your employer feels uncomfortable with that.  You
might have the best possible interests, but not everyone may be as honest.

Personally, have participated as an unaffiliated volunteer and hobbyist at
the W3C for a few years, I've never seen an issue with this.  In fact, I'm
really happy that they have a bullet proof intellectual property framework
that guarantees all my contributions will never be encumbered by patents or
be charged royalties for.



  Hello Bitcoiners,
 
  I have been working on some use cases for the W3C payments workshop. I'd
  like to include Bitcoin, but I might not have the time:
 
  Here is what I have:
 
  https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases
 
  Which is editable with a w3c username and password. Just be a member of
  the
  webpayments community group: http://www.w3.org/community/webpayments/
 
  More formally you can submit a pull request to:
 
  https://github.com/w3c-webmob/payments-use-cases
 
  -
 
  Due to discussions with others am attempting to apply the following
  template:
 
 
  Name: name of the solution
  Use Cases: Key use cases for the solution
  Regions and currencies: Any SDKs or APIs which are available to
 developers
 
  with the following things to consider (for use cases):
  (1) add real money to the service
  (2) buy a physical good in the real wold (e.g., a cup of coffee)
  (3) pay for physical service (e.g., gym membership)?
  (4) convert virtual money back into paper money
  (5) transfer money from one person to another (even if the second person
  is
  not signed up for the service)?
  (6) buy product online
  (7) resolve disputes?
  (8) view transactions?
  (9) secure the wallet
  (10) etc.
 
  Thanks for your time and have a great day!
 
  -Brent Shambaugh
 
 --
  Learn Graph Databases - Download FREE O'Reilly Book
  Graph Databases is the definitive new guide to graph databases and
 their
  applications. Written by three acclaimed leaders in the field,
  this first edition is now available. Download your free book today!
 
 http://p.sf.net/sfu/13534_NeoTech___
  Bitcoin-development mailing list
  

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Melvin Carvalho
On 13 March 2014 16:50, Mike Hearn m...@plan99.net wrote:

 On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik jgar...@bitpay.com wrote:

 Such hand-wavy, data-free logic is precisely why community
 coordination is preferred to random apps making random decisions in
 this manner.


 That ship sailed months ago. If you wanted a big push for uBTC, then would
 have been the time. Though given that it'd have made lots of normal
 balances incredibly huge, perhaps it's a good thing that didn't happen.
 Also milli is a unit people encounter in daily life whereas micro isn't.
 Is it milli / micro / nano or milli / nano / micro? I bet a lot of people
 would get that wrong.

 If you have to export to financial packages that can't handle fractional
 pennies, then by all means represent prices in whatever units you like for
 that purpose, but in software designed for ordinary people in everyday life
 mBTC is a pretty good fit.

 Besides, fractional pennies crop up in existing currencies too (the famous
 Verizon Math episode showed this), so if a financial package insists on
 rounding to 2dp then I guess it may sometimes do the wrong thing in some
 business cases already.

 Fundamentally, more than two decimal places tends to violate the
 Principle Of Least Astonishment with many humans, and as a result,
 popular software systems have been written with that assumption.


 Lots of people use currencies that don't have any fractional components at
 all ! So perhaps all prices should be denominated in satoshis to ensure
 that they're not surprised :)

 The (number) line has to be drawn somewhere. Wallets are free to suppress
 more than 2dp of precision and actually Andreas' app lets you choose your
 preferred precision. So I think in the end it won't matter a whole lot, if
 the defaults end up being wrong people can change them until wallet authors
 catch up.


+1 agree with Mike on everything

A couple of points:

1. bitcoinity already switched to mbtc aka millitbits (
https://en.bitcoin.it/wiki/MilliBit ) and it was positively recieved, they
got quite a few donations

2. If you watch Gavin's talk at the CFR he suggests the community comes to
a consensus through implementations rather than top down decision making
(If I understood correctly)

I think it's up to wallet maintainers whether to switch the default.





 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Testnet block explorer

2014-02-16 Thread Melvin Carvalho
On 27 December 2013 19:05, Mike Hearn m...@plan99.net wrote:

 For a long time the only block explorer for testnet has been the original
 blockexplorer.com, which is unfortunately often broken / behind / slow
 and not really maintained any more.

 There is now a new one, here:

 https://www.biteasy.com/testnet/blocks

 There's also a REST/JSON API for it.

 Please note one curiosity of this block explorer is that the coinbase tx
 doesn't necessarily come first in the listing (it's sorted by time
 received, see).

 Other interesting thing to note: this site is built using bitcoinj. The
 author can be contacted on IRC sometimes using the nick damethos.


Some more information on testnet3 explorers ...

Here is a free software testnet explorer based on javascript/node

http://test.bitcore.io/

I've been working on a testnet explorer, but I think I will fork this and
add semantic web style markup attributes to the HTML.

Also a message I got from blockr.io yes testnet will be added. I cannot
give you an estimate on when, but it'll probably happen in couple of weeks
(hopefully sooner).




 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP: register with IANA for bitcoin/cryptocoin port numbers

2014-01-02 Thread Melvin Carvalho
On 3 January 2014 06:22, Troy Benjegerdes ho...@hozed.org wrote:

 I believe this is self-explainatory:

 1) Bitcoin usually runs on port 8333. Why?

 2) Bitcoin does not show in up
 http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml..
  why?

 3) What needs to happen to have someone from the Bitcoin foundation
   to fill out the form asking for an assigned port (see
   http://www.iana.org/form/ports-services )

 4) what should the process be for new cryptocoins to get both default
 port numbers, as well as P2P network identifier 'magic numbers'


IANA normally register ports with the principle of conservation in mind.
See section 7.2 of RFC6335 for more details.

http://tools.ietf.org/html/rfc6335#section-7.2

8333 and 18333 are currently unassigned, which is good news.

Ideally it would be good to have two ports, one for the main net, and one
for the test net.  However, in light of conservation only one may be
granted.  The question as to whether traffic could be multiplexed over a
single port may be raised.

tnp8321udpThin(ium) Network Protocol
[Aly_Orady][Aly_Orady]
  2007-08-07
 8322-8350Unassigned
server-find8351tcpServer Find
[Chris_Brown]  [Chris_Brown]

gv-pf  18262   udpGV NetConfig Service
[Scott_Libert] [Scott_Libert]
  2008-01-29
18263-18462   Unassigned
ac-cluster 18463   tcpAC Cluster
[Lisa_Zhong]

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

If a whole slew of alt coins also tried to reserve ports, I suspect that
may raise eyebrows.




 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Testnet block explorer

2013-12-27 Thread Melvin Carvalho
On 27 December 2013 19:08, Mike Belshe m...@belshe.com wrote:

 Great!

 There is another one at http://testnet.btclook.com/ which provides a
 different view as well.


And another at:

http://test.webbtc.com/http://test.webbtc.com/address/myTPjxggahXyAzuMcYp5JTkbybANyLsYBW

Testnet does not currently fully function with for creating transactions:

http://test.webbtc.com/http://test.webbtc.com/address/myTPjxggahXyAzuMcYp5JTkbybANyLsYBW

Because there's no unspent API for getting the unspent values for an
address.  If there existed a testnet explorer which would send out those
values (as blockchain.info does with the main net), that would be awesome.

I'm also working on a testnet explorer with semantic web markup so that
it's both human and machine readable.



 Mike



 On Fri, Dec 27, 2013 at 10:05 AM, Mike Hearn m...@plan99.net wrote:

 For a long time the only block explorer for testnet has been the original
 blockexplorer.com, which is unfortunately often broken / behind / slow
 and not really maintained any more.

 There is now a new one, here:

 https://www.biteasy.com/testnet/blocks

 There's also a REST/JSON API for it.

 Please note one curiosity of this block explorer is that the coinbase tx
 doesn't necessarily come first in the listing (it's sorted by time
 received, see).

 Other interesting thing to note: this site is built using bitcoinj. The
 author can be contacted on IRC sometimes using the nick damethos.


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!

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




 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Web Crypto -- Named Curve Dictionary (adding secp256k1)

2013-12-15 Thread Melvin Carvalho
Harry and David suggested I send a message to this group.  I was wondering
if the crypto group may consider adding support for *secp256k1* in the
browser Named Curve dictionary.

http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary

enum NamedCurve {
  // NIST recommended curve P-256, also known as secp256r1.
  P-256,
  // NIST recommended curve P-384, also known as secp384r1.
  P-384,
  // NIST recommended curve P-521, also known as secp521r1.
  P-521
};

Over the last year, there has been a significant increase in deployment for
this curve.  It's used in bitcoin and many other crypto currencies.
Bitcoin deployment now numbers in the millions of users and hundreds of
companies.  There are also free software implementations in most
languages.

For more background on Koblitz curve used by bitcoin see:

https://bitcointalk.org/?topic=2699.0

I'm aware that the API tends to expose what's existing in NSS, but, imho,
if it were possible to add support for this curve would be a great step to
help to many people that already work with crypto currencies in the browser.
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Message Signing based authentication

2013-12-06 Thread Melvin Carvalho
On 6 November 2013 07:41, slush sl...@centrum.cz wrote:

  But where are the private keys stored? Crypto in the browser with help,
 but although they will expose ECC via the NSS, I dont think bitcoin's
 particular curve will be supported, because it's not NIST approved. If the
 use case was presented though, they may add it.

 Trezor, my friend.


Looking forward to the trezor release, best of luck.

This may be an interesting read too:

https://www.grc.com/sqrl/sqrl.htm


 Slush

 Sent from mobile phone.

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] is there a way to do bitcoin-staging?

2013-11-21 Thread Melvin Carvalho
On 14 October 2013 20:08, Adam Back a...@cypherspace.org wrote:

 Coming back to the staging idea, maybe this is a realistic model that could
 work.  The objective being to provide a way for bitcoin to move to a live
 beta and stable being worked on in parallel like fedora vs RHEL or odd/even
 linux kernel versions.

 Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x
 stable and leap-frogs as beta becomes stable after testing.

 Its a live beta, meaning real value, real contracts.  But we dont want it
 to
 be an alt-coin with a floating value exactly, we want it to be bitcoin, but
 the bleeding edge bitcoin so we want to respect the 21 million coin limit,
 and allow coins to move between bitcoin and betacoin with some necessary
 security related restrictions.

 There is no mining reward on the betacoin network (can be merge mined for
 security), and the way you opt to move a bitcoin into the betacoin network
 is to mark it as transferred in some UTXO recognized way.  It cant be
 reanimated, its dead.  (eg spend to a specific recognized invalid address
 on
 the bitcoin network).  In this way its not really a destruction, but a
 move,
 moving the coin from bitcoin to betacoin network.

 This respects the 21 million coin cap, and avoids betacoin bugs flowing
 back
 and affecting bitcoin security or value-store properties.  Users may buy or
 swap betacoin for bitcoin to facilitate moving money back from betacoin to
 bitcoin.  However that is market priced so the bitcoin network is security
 insulated from beta.  A significant security bug in beta would cause a
 market freeze, until it is rectified.

 The cost of a betacoin is capped at one BTC because no one will pay more
 than one bitcoin for a betacoin because they could alternatively move their
 own coin.  The reverse is market priced.

 Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
 decision is reached to promote 1.0 beta to 2.0 stable, the remaining
 bitcoins can be moved, and the old network switched off, with mining past a
 flag day moving to the betacoin.

 During the beta period betacoin is NOT an alpha, people can rely on it and
 use it in anger for real value transactions.  eg if it enables more script
 features, or coin coloring, scalabity tweaks etc people can use it.
 Probably for large value store they are always going to prefer
 bitcoin-stable, but applications that need the coloring features, or
 advanced scripting etc can go ahead and beta.

 Bitcoin-stable may pull validated changes and merge them, as a way to pull
 in any features needed in the shorter term and benefit from the betacoin
 validation.  (Testing isnt as much validation as real-money at stake
 survivability).

 The arguments are I think that:

 - it allows faster development allowing bitcoin to progress features
 faster,

 - it avoids mindshare dilution if alternatively an alt-coin with a hit
missing feature takes off;

 - it concentrates such useful-feature alt activities into one OPEN source
and OPEN control foundation mediated area (rather than suspected land
grabs on colored fees or such like bitcoin respun as a business model
things),

 - maybe gets the developers that would've been working on their pet
alt-coin, or their startup alt-coin to work together putting more
developers, testers and resources onto something with open control (open
source does not necessarily mean that much) and bitcoin mindshare
branding, its STILL bitcoin, its just the beta network.

 - it respects the 21 million limit, starting new mining races probably
dillutes the artificial scarcity semantic

 - while insulating bitcoin from betacoin security defects (I dont mean
betacoin as a testnet, it should have prudent rigorous testing like
bitcoin, just the very act of adding a feature creates risk that bitcoin
stable can be hesitant to take).

 Probably the main issue as always is more (trustable) very high caliber
 testers and developers.  Maybe if the alt-coin minded startups and
 developers donate their time to bitcoin-beta (or bitcoin-stable) for the
 bits they are missing, we'll get more hands to work on something of
 reusable
 value to humanity, in parallel with their startup's objectives and as a way
 for them to get their needed features, while giving back to the bitcoin
 community, and helping bitcoin progress faster.

 Maybe bitcoin foundation could ask for BTC donations to hire more
 developers
 and testers full time.  $1.5b of stored value should be interested to safe
 guard their value store, and develop the transaction features.


I think there may be a simpler way to do this.

Create a new genesis block for a staging network, but in all other aspects,
as far as possible, keep the properties the same as bitcoin.

Do not actively be opposed to it being traded, but people need to know
that, although there is no intention to reset the chain, new and
potentially not fully tested, changes can 

Re: [Bitcoin-development] moving the default display to mbtc

2013-11-14 Thread Melvin Carvalho
On 15 November 2013 01:37, Daniel F nanot...@gmail.com wrote:

  This is a decentralized currency, and we should avoid centralizing
  decisions.  This is something that impacts the community at large, and
  deserves input and discussion at every level.
 
  I would suggest posting on all possible forums proposal: switch to
  uBTC, labelled as ISO prefers (XBT?) and see what sort of discussion
  is generated.  If the support is broad, it will be plain from the
  responses if there is a consensus.  Perhaps everyone will agree it is
  the best course, and we can make an easy change.
 
  But we need less core dev fiat not more :)
 
 this seems like such a paint-the-bikeshed problem that it's sure to
 generate vast volumes of discussion, waste a lot of people's time, and
 all for only a dubious (imo) gain. (case in point - here i am
 contributing to it :) ).

 i agree that we should avoid centralizing this. i'll go a step further
 and note that the client already has a dropdown allowing individuals to
 choose units. merchants are free to choose to price in different units.
 exchanges are free to denominate trade in different units.

 i suggest we just let the market do its thing and not get into trying to
 'make a decision' of any sort.


I do agree with you here

e.g. I think the question of the ISO code (XBT vs BTC) is probably out of
scope for this thread, and there was no clear consensus, when it came up on
the forums.

As a data point, the price of bitcoin has gone up roughly 1000x since
satoshi made his suggestion that the decimal point could move 3 places.

I dont think it's a question of centralization, I was just seeking opinion
on what people felt about the reference implementation.  How about just
changing the default value in the dropdown from BTC - to mBTC

The the other clients and exchange choose whether they want to follow suit
or not




 --
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Message Signing based authentication

2013-11-05 Thread Melvin Carvalho
On 2 November 2013 22:57, slush sl...@centrum.cz wrote:

 Glad to see that there are more and more people wanting to replace
 passwords with digital signatures.

 Although such method has been already used on other websites like Eligius
 or bitcoin-otc, I dont think theres any standard way to doing so yet.

 Two comments to your proposal:

 A) message-to-be-signed need to be carefully composed to be both
 structured and human readable. It should contain at least:
 Desired username/identity handler
 Server identifier (url)
 Timestamp to prevent replay attack
 Server challenge

 Then the user can see what he's signing, instead of signing some binary
 blob which can contain some evil data.

 B)
 Same structured data should be a part of html page in some header tag,
 ideally signed by server certificate to confirm that the request is valid.
 Then the login request can be processed by machine automatically, without a
 need of copypaste by a user.

But where are the private keys stored?  Crypto in the browser with help,
but although they will expose ECC via the NSS, I dont think bitcoin's
particular curve will be supported, because it's not NIST approved.  If the
use case was presented though, they may add it.

This can actually be done today using client side certificates.  Two
methods.

Method 1:

In your client side certificate, put in your bitcoin address in the
subjectAlternativeName field.  This is a field that lets you tell the
server I have another identity

From the bitcoin address look up via a .well-known key server some items
previously uploaded.  This would normally be a signed value of the key
used, or a signed value of the the certificate.  The server checks this and
logs you in.

Method 2:

In your client side certificate, put in an HTTP address.  That HTTP address
contains your bitcoin address and a signed copy of your cert public key or
the cert itself.

The advantage here is that you dont need a key server.


Both methods work, I've been doing this kind of thing for 5 years+, and I'd
never go back to passwords on anything I build.

I'm all for recreating this UI in javascript too, but I just wonder how to
protect the private keys ...


 Slush


 On Sat, Nov 2, 2013 at 6:01 AM, bitcoingr...@gmx.com wrote:

 Passwords are inefficient by design: frequently we hear news from Sony,
 Square Enix, Adobe, and various others about passwords being compromised,
 databases being copied and stolen. This story remains true in the Bitcoin
 space. In light of the recent Bitcointalk forum breach echoes an increasing
 need for passwords to become a thing of the past.



 In celebration of the 5 year anniversary of the Bitcoin whitepaper, we
 are delighted to introduce the Message Signing based authentication method.



 In brief, the authentication work as follows:



 Server provides a token for the client to sign.

 client passes the signed message and the bitcoin address back to the
 server.

 server validates the message and honors the alias (optional) and bitcoin
 address as identification.



 http://forums.bitcoingrant.org/



 Above is a proof of concept forum that utilize this authentication
 method. Following Kerckhoffs's principle, this forum only stores the signed
 message and bitcoin address the users provide the first time they use the
 site, both are public information. In addition, there is no database,
 everything is simply an RSS feed. For the sake of usability we have
 included a redis for the sessions, at the cost of additional exposure to
 potential risks: users no longer need to sign a token every time they wish
 to post.



 All source code will be available on github in the next few days.



 We welcome any feedback or suggestions.





 --
 Android is increasing in popularity, but the open development platform
 that
 developers love is also attractive to malware creators. Download this
 white
 paper to learn more about secure code signing practices that can help keep
 Android apps secure.

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




 --
 Android is increasing in popularity, but the open development platform that
 developers love is also attractive to malware creators. Download this white
 paper to learn more about secure code signing practices that can help keep
 Android apps secure.
 http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



Re: [Bitcoin-development] Message Signing based authentication

2013-11-05 Thread Melvin Carvalho
On 2 November 2013 22:14, Johnathan Corgan johnat...@corganlabs.com wrote:

 On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote:

  Server provides a token for the client to sign.

 Anyone else concerned about signing an arbitrary string?  Could be a
 hash of $EVIL_DOCUMENT, no?  I'd want to XOR the string with my own
 randomly generated nonce, sign that, then pass the nonce and the
 signature back to the server for verification.


Good point.

There are actually times you may want to sign a transaction.

There's a little know HTTP code, 402, Payment Required.  We should really
start using this at some point ...

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Reserved for future use.[2] The original intention was that this code might
be used as part of some form of digital cash or micropayment scheme, but
that has not happened, and this code is not usually used. As an example of
its use, however, Apple's defunct MobileMe service generated a 402 error if
the MobileMe account was delinquent.[citation needed] In addition, YouTube
uses this status if a particular IP address has made excessive requests,
and requires the person to enter a CAPTCHA.



 --
 Johnathan Corgan, Corgan Labs
 SDR Training and Development Services
 http://corganlabs.com


 --
 Android is increasing in popularity, but the open development platform that
 developers love is also attractive to malware creators. Download this white
 paper to learn more about secure code signing practices that can help keep
 Android apps secure.
 http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Message Signing based authentication

2013-11-02 Thread Melvin Carvalho
On 2 November 2013 17:26, Mike Hearn m...@plan99.net wrote:

 Guys, identity systems for the web are off-topic for this list. Other than
 the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any
 relevance to it.

 On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo hannu.kotip...@iki.fiwrote:

 Maybe this is a bit off-topic, but the *real* answer to the question
 why-is-nobody-using-ssl-client-certificates is that it would force
 www pages to be encrypted and would make it a lot more difficult for
 NSA to log www-trafic.


 No, it wouldn't. You can log a user in using SSL and then redirect the
 user back to an encrypted page, using cookies for the rest of the session.
 Please don't clutter up this list with conspiracy theories. The brutal
 reality is that identity is a hard problem.


Identity need not be a hard problem.  In my view it is a solved problem.

You have a real world entity translated to a digital format.  Yes that can
be slightly ambiguous at time, naming is hard, and people do get this wrong
frequently.

The most common problem is to name something in a way that does not scale.
The solution to this problem is rather easy, and that is to use a URI to
name something, which makes it global and scalable.

In the case of bitcoin you could have use the bitcion URI scheme

bitcion:1fhdjkfhjksf...




 --
 Android is increasing in popularity, but the open development platform that
 developers love is also attractive to malware creators. Download this white
 paper to learn more about secure code signing practices that can help keep
 Android apps secure.
 http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Core Development Update #5

2013-10-24 Thread Melvin Carvalho
https://bitcoinfoundation.org/blog/?p=290

Very excited about this, particularly the 80 bytes embeddable message.  I
do believe satoshi mentioned he wanted to add short messages, at some point.

Great work Gavin  all!
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?

2013-09-29 Thread Melvin Carvalho
On 29 September 2013 10:32, Gavin Andresen gavinandre...@gmail.com wrote:

 On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham n...@asdf.co.nz wrote:

 I subscribe to this list so I can keep up-to date with bitcoin
 development, can we keep philosophy and tax evasion out of it?


 Yes, that's off-topic for this mailing list. Lets stick to technical
 issues that we can solve by writing code.


Hi Gavin, apologies if my post came across as off-topic.  My aim was to
present a use case, and ask whether or not it was technically feasible
using smart contracts.



 --
 --
 Gavin Andresen


 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?

2013-09-29 Thread Melvin Carvalho
On 29 September 2013 04:28, Neil Fincham n...@asdf.co.nz wrote:

 I subscribe to this list so I can keep up-to date with bitcoin
 development, can we keep philosophy and tax evasion out of it?


Hi Neil, perhaps I didnt present the use case clearly.  It was not about
evasion, it was about voluntary donations going to the correct place, being
verified by an oracle.  I dont wish to stray off topic, so I'll leave it at
that.



 Neil


 On 29 September 2013 09:15, rob.gold...@astutium.com wrote:

  But the regulatory environment in many geographical regions in
  uncertain.   Do we need to pay capital gains?   Do we need to pay a
  sales taxs etc. etc.

 In most regions it's not only 'simple' but trivial - BTC is just
 'another currency' and accounted for exactly the same way - it doens't
 matter if you sell your hose for GBP, USD, EUR, BTC or sacks of Pig
 Dung, you still have a GBP tax issue ...

  So my idea is to voluntarily pre empt legislation by giving donations
  to govt (aka taxation) for bitcoin service providers.

 You want to volunteer to pay tax ? I'd suggest stronger medication ...

  However, there is something of a problem with voluntary donations.
  Most people are not satisfied with the way they are spent.

 80% of 'donations' end up spent on 'adminsitration' and not what they
 were donated for, this is a 'greed' issue not a 'currency' issue.

  In the UK
  a recent survey said that only 18% of people thought that tax money
  was wisely spent.

 Tax isn't voluntary or a donation. The 18% who think UK tax is well
 spent are the 18% of the population who get the tax money, not the 82%
 that pay it ;)

  Can we fix it?

 First we kill all the politicians ...

  So let's say I run a business and I make 1 million euros.  I wish to
  donate 10% of my profits to society.  But let's say I dont want that
  money to go to wars of aggression, but rather, to the fire
  de[department.

 So give it to the FD - what you do with your post-tax profits are up to
 you ;)

  At this point everyone wins.  The business person is happy to make a
  contribution.  The govt. is happy that it gets more revenue.  The
  fire dept. is happy that it has revenue to do its work.  And
  everything has gone to the right place in a kind of democratic way.

 Where does gov't come into this ? I think you're confusing 'tax' which
 you have zero control over and 'donations' which you already have 100%
 control over.

 Rob


 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 

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




 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] smart contracts -- possible use case? yes or no?

2013-09-27 Thread Melvin Carvalho
We all love bitcoin's ability to transfer value in real time across borders.

But the regulatory environment in many geographical regions in uncertain.
Do we need to pay capital gains?   Do we need to pay a sales taxs etc. etc.

At this point bitcoin is small enough for this to not be a huge issue, but
one day that may change (maybe we hope!).

So my idea is to voluntarily pre empt legislation by giving donations to
govt (aka taxation) for bitcoin service providers.

However, there is something of a problem with voluntary donations.  Most
people are not satisfied with the way they are spent.  In the UK a recent
survey said that only 18% of people thought that tax money was wisely
spent.  This is bad for govt., bad for people, and bad for the trusted
relationship.

Can we fix it?  Maybe we smart contract and voluntary donations it's
possible!

So let's say I run a business and I make 1 million euros.  I wish to donate
10% of my profits to society.  But let's say I dont want that money to go
to wars of aggression, but rather, to the fire de[department.

So we set up a smart contract that is only cashable if the money goes to
the right place (verified by an oracle).

At this point everyone wins.  The business person is happy to make a
contribution.  The govt. is happy that it gets more revenue.  The fire
dept. is happy that it has revenue to do its work.  And everything has gone
to the right place in a kind of democratic way.

Over time if it takes off, this could provide revenue for many essential
services that are needed by people, in a way that allows more democratic
freedom of choice.

So my question is whether it may be possible to use smart contracts to
achieve a better democracy that is good for people, good for govt, and good
for innovation?  My hope is that the answer is ...

Yes We Can

:)
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-15 Thread Melvin Carvalho
On 16 August 2013 03:00, Gavin Andresen gavinandre...@gmail.com wrote:

 Mike asked what non-0.9 code I'm working on; the three things on the top
 of my list are:

 1) Smarter fee handling on the client side, instead of hard-coded fees. I
 was busy today generating scatter-plots and histograms of transaction fees
 versus priorities to get some insight into what miner policies look like
 right now.


+1



 2) First double-spend relaying and alerting, to better support low-value
 in-person transactions.  Related:
 *Have *a *Snack*, Pay with 
 *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf



+1



 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
 block size limit, how we can do it safely, and go through all of the
 arguments that have been made against it and explain why they're wrong.


What block size do you think is ideal?



 --
 --
 Gavin Andresen



 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Melvin Carvalho
On 9 August 2013 14:08, Mike Hearn m...@plan99.net wrote:

 Bitcoin sought to reduce dependence on trusted third parties, where as,
 persona is increasing the reach of trusted third parties.  The keys and
 passwords are stored on mozilla's servers, sometimes on your email
 providers.  Persona, is however, a progression and will hopefully improve
 its security and decentralization as it goes along.


 When Persona is supported by all the key players in a transaction Mozilla
 doesn't get anything, do they? You can easily run your own IDP on a
 personal server if you're the kind of person who likes to do that, then run
 Firefox so you have a native implementation and the Mozilla servers aren't
 involved. The keys never leave your computers.


You'd need to run your own email server and/or change email address, which
is not in the reach of the average user, and maybe not even of some
businesses.



 Whilst X.509 certs can indeed be issued for any arbitrary string, you
 still need a CA that will do it for you, and that's typically not so
 trivial. CAs aren't meant for widespread end user adoption, really, whereas
 Persona is.


You can self sign X.509 certificates quite easily (e.g. one click via
KEYGEN), then rely on a decentralized web of trust to remove browser
warnings.  A few people are working on this.



 I don't think Persona is any more or less centralised than other PKIs,
 really, just easier to use. Ultimately the string you're verifying is a
 user@host pair, so the host is centralised via DNS and to verify the
 assertions it vends, you must use SSL to connect to it, so under the hood
 the regular SSL PKI is still there.



It is easier to use, that's a great plus.  But convenience is often a trade
off with security.

I dont user user@host, I use my home page because it's easy to dereference
and get a public key.  Email is hard to dereference.

Yes, there is a reliance on DNS, which Tim calls the 'Achilles heel' of the
web, but it's held up quite well so far (fortunately for us).

Mozilla also have a master key to most email accounts, so if anyone got
access to that they could impersonate the vast majority of users that have
not opted in.  I would not use persona for financial stuff, but if I made a
casual app with non sensitive information it would be one of the top
choices, imho
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Idea for new payment protocol PKI

2013-08-09 Thread Melvin Carvalho
On 9 August 2013 13:59, Wendell w...@grabhive.com wrote:

 We have been discussing something like this over here too, as well as
 exploring more esoteric blockchain+signature-based SSO implementations as
 discussed by John Light and others.


I've been using SSO for years using an X.509 private key in my browser, and
my public key referenced in my home page.

The unfortunate thing is that X.509 tends to use RSA, and bitcoin tends to
use ECC for space reasons.  Since, in its simplest form, bitcoin is a
distributed ledger of public key / balance values you could imagine an
enormous eco system where every key pair become a wallet with 10s of
millions of users.

I was thinking about an alt coin along these lines.  The problem is that
there's no OP_CODE for RSA and the block chain would become massive.



 One of our long-term ambitions with Hive is to provide a (mostly)
 user-transparent, decentralized authentication service. It sounds like our
 infrastructure could already handle a Persona implementation, and we very
 much want to get behind some forward-thinking standard. So as long as the
 plan _IS_ to remove said 'centralized struts' at the appropriate time, I'd
 say we're interested in exploring this further.


Sounds great, would love to hear more about what you come up with!



 -wendell

 grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

 On Aug 9, 2013, at 1:43 PM, Mike Hearn wrote:

  This is just me making notes for myself, I'm not seriously suggesting
 this be implemented any time soon.
 
  Mozilla Persona is an infrastructure for web based single sign on. It
 works by having email providers sign temporary certificates for their
 users, whose browsers then sign server-provided challenges to prove their
 email address.
 
  Because an SSO system is a classic chicken/egg setup, they run various
 fallback services that allow anyone with an email address to take part.
 They also integrate with the Google/Yahoo SSO systems as well. The
 intention being that they do this until Persona becomes big enough to
 matter, and then they can remove the centralised struts and the system
 becomes transparently decentralised.
 
  In other words, they seem to do a lot of things right.
 
  Of course you can already sign payments using an X.509 cert issued to an
 email address with v1 of the payment protocol, so technically no new PKI is
 needed. But the benefit of leveraging Persona would be convenience - you
 can get yourself a Persona cert and use it to sign in to websites with a
 single click, and the user experience is smart and professional. CAs in
 contrast are designed for web site admins really so the experience of
 getting a cert for an email address is rather variable and more heavyweight.
 
  Unfortunately Persona does not use X.509. It uses a custom thing based
 on JSON. However, under the hood it's just assertions signed by RSA keys,
 so an implementation is likely to be quite easy. From the users
 perspective, their wallet app would embed a browser and drive it as if it
 were signing into a website, but stop after the user is signed into Persona
 and a user cert has been provisioned. It can then sign payment requests
 automatically. For many users, it'd be just one click, which is pretty neat.


 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Preparing for the Cryptopocalypse

2013-08-04 Thread Melvin Carvalho
A great presentation on advances in crypto

http://www.slideshare.net/astamos/bh-slides
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-07-31 Thread Melvin Carvalho
On 31 July 2013 13:33, Gavin Andresen gavinandre...@gmail.com wrote:

 On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami r...@gnomon.org.uk wrote:
 
  Is it envisaged to be possible/sensible to have a URI that is *only* a
  payment request?  i.e. something like the following (although I'm not
  sure this is a valid URI):
 
  bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe

 I think we'll want a bitcoin address in there for a long time for
 backwards compatibility.

 If web browser support for arbitrary MIME types is strong enough (I
 haven't tested), then a payment request can be initiated with just an
 anchor tag:
   a href=https://merchant.com/pay.php?3D2a8628fc2fbe;
 type=application/bitcoin-paymentrequest


Unless I'm mistaken you cant generally set the Accept header on a browser
via a standard href ... one of those annoying quirks



 Doing it that way saves a http round-trip.

 --
 --
 Gavin Andresen


 --
 Get your SQL database under version control now!
 Version control is standard for application code, but databases havent
 caught up. So what steps can you take to put your SQL databases under
 version control? Why should you start doing it? Read more to find out.
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin addresses -- opaque or not

2013-06-22 Thread Melvin Carvalho
On 11 June 2013 17:29, Luke-Jr l...@dashjr.org wrote:

 On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
  For the sake of argument let's say that opaque means that you can tell
  nothing about the address by examining the characters.

 This is true or false based on CONTEXT.

 Obviously, an implementation of transaction handling (eg, wallets) needs
 to be
 able to translate addresses to and from what they represent.

 On the other hand, things like URI handlers do not (and should not) try to
 interpret the address as anything other than an arbitrary word (\w+).


Luke, if you think that the sole purpose of a URI scheme is to be used as a
URI handler, I think you've not fully understood the concept.  URIs are the
global variable of the internet, and as such the need to play nicely with
all other URI schemes on the net.  They need to be able to be linked to, to
be defined and documented.  This is important for bitcoin to get right
because bitcoin: needs to treated in a special way on the internet, I just
saw today that it was treated by some software as a relative URL, which is
going to break a ton of stuff.



  My understanding was that they are NOT opaque, and that if that has
  changed, it will invalidate much at least some wiki page, for examples at
  least some of the following would now be false:

 The wiki goes into much detail on how addresses work, which is not the
 concern
 of most software in the Bitcoin ecosystem, but may be of interest to humans
 and developers working on the one component that operates the black box
 that
 addresses are.

  
  snip
  

 These aren't FALSE, they are true at the moment, but subject to revision
 by
 newer standards.

  I also here that there is a LIKELY change from the base58 encoding ...
 when
  was this established?

 I stated (on IRC) that it was likely Bitcoin would change from the base58
 encoding for addresses ... at some unspecified time in the future, to some
 unspecified new encoding that addressed known limitations of base58. What
 those changes will be, or when, are not all established at this time. The
 only
 currently-planned change to addresses (very loosely defined) is inclusion
 of
 the Payment Protocol URIs. But the point is that software developers
 shouldn't
 assume that addresses will remain base58 forever.


I am opposed to address changes in general, until he wider implications are
fully understood.



 Luke

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-22 Thread Melvin Carvalho
On 10 June 2013 06:09, John Dillon john.dillon...@googlemail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 It has been suggested that we leave the decision of what the blocksize to
 be
 entirely up to miners. However this leaves a parameter that affects every
 Bitcoin participant in the control of a small minority. Of course we can
 not
 force miners to increase the blocksize if they choose to decrease it,
 because
 the contents of the blocks they make are their decision and their decision
 only. However proposals to leave the maximum size unlimited to allow
 miners to
 force us to accept arbitrarily large blocks even if the will of the
 majority of
 Bitcoin participants is that they wish to remain able to validate the
 blockchain.

 What we need is a way to balance this asymetrical power relationship.

 Proof-of-stake voting gives us a way of achieving that balance.
 Essentially for
 a miner to prove that the majority will of the poeple is to accept a larger
 blocksize they must prove that the majority has in fact voted for that
 increase. The upper limit on the blocksize is then determined by the
 median of
 all votes, where each txout in the UTXO set is one vote, weighted by txout
 value. A txout without a corresponding vote is considered to be a vote for
 the
 status quo. To allow the voting process to continue even if coins are
 lost
 votes, including default votes, are weighted inversely according to their
 age
 in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old
 will be
 recorded the same as a 1 year old vote weighted as 0.67BTC, and a 1 day
 old
 and 6 months old UTXO are treated equivalently. The 1 year minimum is
 simply to
 make voting required no more than once per year. (of course, a real
 implementation should do all of these figures by block height, IE after
 52,560
 blocks instead of after 1 year)

 A vote will consist of a txout with a scriptPubKey of the following form:

 OP_RETURN magic vote_id txid vout vote scriptSig

 Where scriptSig is a valid signature for a transaction with nLockTime
 500,000,000-1 spending txid:vout to scriptPubKey:

 OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL

 vote_id is the ID of the specific vote being made, and magic is included to
 allow UTXO proof implementations a as yet unspecified way of identifying
 votes
 and including the weighted median as part of the UTXO tree sums. (it also
 allows SPV clients to verify the vote if the UTXO set is a Patricia tree of
 scriptPubKeys) vote is just the numerical vote itself. The vote must
 compute
 the median, rather than the mean, so as to not allow someone to skew the
 vote
 by simply setting their value extremely high. Someone who still remembers
 their
 statistics classes should chime in on the right way to compute a median in
 a
 merkle-sum-tree.

 The slightly unusual construction of votes makes implementation by wallet
 software as simple as possible within existing code-paths. Votes could
 still be
 constructed even in wallets lacking specific voting capability provided the
 wallet software does have the ability to set nLockTime.

 Of course in the future the voting mechanism can be used for additional
 votes
 with an additional vote_id. For instance the Bitcoin community could vote
 to
 increase the inflation subsidy, another example of a situation where the
 wishes
 of miners may conflict with the wishes of the broader community.

 Users may of course actually create these specially encoded txouts
 themselves
 and get them into the blockchain.  However doing so is not needed as a
 given
 vote is only required to actually be in the chain by a miner wishing to
 increase the blocksize. Thus we should extend the P2P protocol with a
 mechanism
 by which votes can be broadcast independently of transactions. To prevent
 DoS
 attacks only votes with known vote_id's will be accepted, and only for
 txid:vout's already in the blockchain, and a record of txouts for whom
 votes
 have already broadcast will be kept. (this record need not be
 authoritative as
 its purpose is only to prevent DoS attacks) Miners wishing to increase the
 blocksize can record these votes and include them in the blocks they mine
 as
 required. To reduce the cost of including votes in blocks 5% of every block
 should be assigned to voting only. (this can be implemented by a soft-fork)

 For any given block actual limit in effect is then the rolling median of
 the
 blocks in the last year. At the beginning of every year the value
 considered to
 be the status quo resets to the mean of the limit at the beginning and end
 of
 the interval.  (again, by year we really mean 52,560 blocks) The rolling
 median and periodic reset process ensures that the limit changes gradually
 and
 is not influenced by temporary events such as hacks to large exchanges or
 malicious wallet software.  The rolling median also ensures that for a
 miner
 the act of including a vote is never wasted due to the 

Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol

2013-06-19 Thread Melvin Carvalho
On 18 June 2013 05:48, Alan Reiner etothe...@gmail.com wrote:

  *Goal*:  An alternative address format made possible by BIP 32, which
 allows one to specify a Wallet ID and One-time payment code, instead of
 the standard one-use Base58-Hash160 addresses.   This allows parties with a
 persistent relationship to be able to prove that payment addresses they
 provide each other are linked to a particular wallet, reducing exposure to
 MitM attacks without the need for SSL or a web of trust, and without
 compromising the privacy of either party.For instance, this could be
 used between businesses that frequently do business, by exchanging and
 verifying public keys beforehand, or could be used by an exchange to
 identify if a customer withdrawal address is related to their last deposit
 address, and if not enforce extra authentication measures.

 *Background**:*
 I haven't been following the payment protocol discussions/development
 much, so I apologize if this has already been addressed.   I'm calling it
 wallet-linkable addresses, which would be an optional second form for
 sending someone your address.   With BIP 32, the address is computed by the
 payee (the person sending the address to receive money):

Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i])
 || checksum)

 What I'd like to do is have the option, when specifying an address through
 the payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]}
 and let the receiver of that address compute the address on their own.
 This is no significant burden on the receiver, but it does provide the
 useful property that they can recognize when addresses specified in this
 way come from the same wallet -- because the PubKeyParent will be the
 same.  Remember, this is *optional* for the person providing the address.

 One nice, accidental feature of BIP 32 is that the Multiplier[i] used
 above does not actually reveal the chaincode (I think Pieter started
 calling it the tweak).   It is derived from the chaincode but doesn't
 reveal it.  Therefore, the payer sees the parent public key, but that's not
 useful to derive any of the other addresses unless they also have the
 chaincode.  But they can verify that the PublicKeyParent is identical
 between transactions, and thus is accessible only to that wallet.  It
 allows them validate a specific address provided by the payee, but not
 generate or identify any other addresses.

 *Use Cases:*
 (1)  So, just like with PGP/GPG, when two parties decide they will start a
 relationship, they can start by exchanging the public keys of their wallet
 and verify them in a reliable manner.  After that, when one party requests
 a payment address from the other, they can optionally send {PubKey,
 Multiplier}, and the payer's software will identify the owner of that
 address, or let you select who you think the address belongs to and it will
 verify it.  If the payee's system is compromised and address is replaced,
 the address received by the payer won't validate.  This doesn't help if the
 side sending the money is compromised.

 (2)  When a customer first provides a deposit to an exchange, it will send
 money from an address in their wallet and the software will provide the
 exchange the {PubKey,Mult}.  When the customer later provides a withdrawal
 address, the site can automatically trust the address as long it is
 provided in the alternate form and the public keys match.  If they don't,
 it might be the same customer just requesting a withdrawal to a different
 wallet, which is fine, but they'll have to go through an extra verification
 step to do so.


 *Downsides:*
 Multi-sig/P2SH  - The only way this works with P2SH, violates one of the
 goals of P2SH slightly, but may not matter much if it's all done under the
 hood by the software.  Instead of providing a 20-byte hash of a script, you
 provide all the public keys and multipliers for the individual addresses.
 The payer's software automatically verifies all addresses and creates the
 P2SH script itself (after a divine decree that public keys will always be
 sorted lexicographically in the multi-sig script).  The blockchain still
 benefits from the compression of moving the bulky scripts to the TxIn,
 but it does require revealing more information than is necessary for the
 payer to pay the payee.  But it may not *really* be a problem, given the
 benefits.  It might just be slightly longer strings to exchange during
 initialization and for each transaction.

 I have various reasons I'd like to use this, and it'd be nice to have some
 community backing, so I don't have to twist anyone's arm to trust me that
 it's legit.


Generally in favour of hierarchical deterministic wallets.

Will this new style of address make it into the block chain?  I'd be less
keen on that.

I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar with the material than some.  However, there's
little things like it 

Re: [Bitcoin-development] Bitcoin addresses -- opaque or not

2013-06-15 Thread Melvin Carvalho
On 11 June 2013 17:29, Luke-Jr l...@dashjr.org wrote:

 On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
  For the sake of argument let's say that opaque means that you can tell
  nothing about the address by examining the characters.

 This is true or false based on CONTEXT.

 Obviously, an implementation of transaction handling (eg, wallets) needs
 to be
 able to translate addresses to and from what they represent.

 On the other hand, things like URI handlers do not (and should not) try to
 interpret the address as anything other than an arbitrary word (\w+).


I think this statement may need to be justified.



  My understanding was that they are NOT opaque, and that if that has
  changed, it will invalidate much at least some wiki page, for examples at
  least some of the following would now be false:

 The wiki goes into much detail on how addresses work, which is not the
 concern
 of most software in the Bitcoin ecosystem, but may be of interest to humans
 and developers working on the one component that operates the black box
 that
 addresses are.

  
  snip
  

 These aren't FALSE, they are true at the moment, but subject to revision
 by
 newer standards.


Got it.



  I also here that there is a LIKELY change from the base58 encoding ...
 when
  was this established?

 I stated (on IRC) that it was likely Bitcoin would change from the base58
 encoding for addresses ... at some unspecified time in the future, to some
 unspecified new encoding that addressed known limitations of base58. What
 those changes will be, or when, are not all established at this time. The
 only
 currently-planned change to addresses (very loosely defined) is inclusion
 of
 the Payment Protocol URIs. But the point is that software developers
 shouldn't
 assume that addresses will remain base58 forever.


Does this mean that people should not be investing in vanity addresses?



 Luke

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] is there a way to do bitcoin-staging?

2013-06-15 Thread Melvin Carvalho
On 19 May 2013 15:23, Adam Back a...@cypherspace.org wrote:

 Is there a way to experiment with new features - eg committed coins - that
 doesnt involve an altcoin in the conventional sense, and also doesnt impose
 a big testing burden on bitcoin main which is a security and testing risk?

 eg lets say some form of merged mine where an alt-coin lets call it
 bitcoin-staging?  where the coins are the same coins as on bitcoin, the
 mining power goes to bitcoin main, so some aspect of merged mining, but no
 native mining.  and ability to use bitcoins by locking them on bitcoin to
 move them to bitcoin-staging and vice versa (ie exchange them 1:1
 cryptographically, no exchange).

 Did anyone figure anything like that out?  Seems vaguely doable and
 maybe productive.  The only people with coins at risk of defects in a new
 feature, or insufficiently well tested novel feature are people with coins
 on bitcoin-staging.

 Yes I know about bitcoin-test this is not it.  I mean a real live system,
 with live value, but that is intentionally wanting to avoid forking
 bitcoins
 parameters, nor value, nor mindshare dillution.  In this way something
 potentially interesting could move forward faster, and be les risky to the
 main bitcoin network.  eg particularly defenses against

 It might also be a more real world test test (after bitcoin-test) because
 some parameters are different on test, and some issues may not manifest
 without more real activity.

 Then also bitcoin could cherry pick interesting patches and merge them
 after
 extensive real-world validation with real-money at stake (by early
 adopters).


Interesting idea.  I wonder if ripple could be used to set up a transfer
system between the 'main' and 'staging' systems ...



 Adam


 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Fwd: The pay it forward approach to crypto currencies

2013-06-12 Thread Melvin Carvalho
FYI: some musings on how crypto currencies might be combined with social
good ...

-- Forwarded message --
From: Melvin Carvalho melvincarva...@gmail.com
Date: 12 June 2013 19:39
Subject: The pay it forward approach to crypto currencies
To: building-a-distributed-decentralized-inter...@googlegroups.com


Crypto currencies are doing quite well, but they have yet to make a
meaningful impact on any economy, nor have they achieved much in the way of
social good, however there is a tangible excitement about ways that it can
modernize the way we live our lives

We live in a world where 10,000 children under the age of five die every
day, which can be prevented by simple, affordable interventions ... why do
we let this happen?

Turning he question on its head, what interventions do crypto currencies
enable us to perform, that could help solve this problem

Well certainly crypto currencies have opened pandora's box in terms of
technology being able to create money, let it float, and let it appreciate
in value ... something that the alchemists of old (whose number include
Aristotle, Newton and Keynes) would have been proud.  Well done Satoshi,
now what shall we do with this gift?

The optimal principle should be that we beam new money to the people that
need it most, on a relatively uniform basis.  Something of a harder
problem, and one with no perfect solution.  But we could make some
approximations ... perhaps.

**
Suppose you were to credit 10,000 new coins to every person on the planet.
Then let it float on the free market (a la bitcoin).  Initially worth zero,
the coins would potentially rise in value to become a consensus driven
global dividend.  Certainly if it went higher it could do a lot to
alleviate many problems for poorer people.

Unfortunately we dont have a huge database of every person on the planet in
the public domain, so this strategy is problematic.  However we roughly do
have good statistics that most people have a mobile phone, so we could beam
coins to every mobile phone.  (technically you can do this using the tel:
URI scheme such that you get one phone, one share).

Phones are now banks, and also have the ability to send money via SMS.

The problem with this approach is that it favours people with multiple
phones, who are probably correlated to relatively wealthy people.  Not
great, but it's a start.

How about we then do it country by country and beam coins to the poorest
countries, say in proportion to GNP per capita.  Perhaps better.

Again, it's possible to systematically game the system, to an extent.  So
one way to reduce the risk would be to allocate coins on a lottery basis,
where a random number generator selects 'lucky' winners.  The net effect
will be generally positive, while preventing major systemic risk.

Little by little, we can bring people out of poverty using crypto coins and
make a better world.

Now, I know what you're thinking.  Money for nothing, that makes no sense.
Why would these coins ever be worth anything.

There is where the pay it forward concept comes in.  All coin recipients
are encouraged to pay it forward ... do good for the sake of good, and
allow that karma to flow back to you.  Eventually this can take the form of
rebuying the coins that saved your life when you were young, and enabled
you to become a successful businessman.

As the value, liquidity, trust, and importantly, social good of the system
build.  So it becomes easier for people to maintain societies, for
economies to thrive, and for governments to balance their budgets.

It becomes an ever increasing virtuous circle, that can transform the
planet.

I've left out a few gaps and technical details, but I'm sure it's possible
to join the dots and incrementally move towards an optimal solution.  I
think bitcoin and the internet have paved the way for pay it forward
crypto currencies.

And hopefully it can one day become an idea worth spending.  :)
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin addresses -- opaque or not

2013-06-11 Thread Melvin Carvalho
There was some confusion on IRC as to whether bitcoin addresses are opaque
or not.

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

For the sake of argument let's say that opaque means that you can tell
nothing about the address by examining the characters.

My understanding was that they are NOT opaque, and that if that has
changed, it will invalidate much at least some wiki page, for examples at
least some of the following would now be false:


A Bitcoin address, or simply address, is an identifier of 27-34
alphanumeric characters -- FALSE

with the number 1 or 3 -- FALSE

you can send bitcoins to a person by sending bitcoins to one of their
addresses -- FALSE

Addresses are created simply by generating random numbers and then
performing mathematical operations to derive matching pairs of public and
private keys -- FALSE

The probability that a mistyped address is accepted as being valid is 1 in
232, that is, approximately 1 in 4.29 billion -- FALSE

If you would like to validate a Bitcoin address in an application, it is
advisable to use a method from this thread rather than to just check for
string length, allowed characters, or that the address starts with a 1 or
3. -- FALSE

For most properly-generated Bitcoin addresses, there is at least one
secret number known as a private key -- FALSE

They consist of random digits and uppercase and lowercase letters, with
the exception that the uppercase letter O, uppercase letter I,
lowercase letter l, and the number 0 are never used to prevent visual
ambiguity -- FALSE

Some Bitcoin addresses can be shorter than 34 characters (as few as 27)
-- FALSE

Several of the characters inside a Bitcoin address are used as a checksum
so that typographical errors can be automatically found and rejected --
FALSE

The checksum also allows Bitcoin software to confirm that a 33-character
(or shorter) address is in fact valid and isn't simply an address with a
missing character -- FALSE


I also here that there is a LIKELY change from the base58 encoding ... when
was this established?

There's either been some bit changes to the fundamentals of bitcoin here or
there's been some misunderstandings.  It would be good to clear things up
as to what exactly an address is now beleived to be, and reflect that in
the wiki.
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-10 Thread Melvin Carvalho
On 10 June 2013 06:09, John Dillon john.dillon...@googlemail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 It has been suggested that we leave the decision of what the blocksize to
 be
 entirely up to miners. However this leaves a parameter that affects every
 Bitcoin participant in the control of a small minority. Of course we can
 not
 force miners to increase the blocksize if they choose to decrease it,
 because
 the contents of the blocks they make are their decision and their decision
 only. However proposals to leave the maximum size unlimited to allow
 miners to
 force us to accept arbitrarily large blocks even if the will of the
 majority of
 Bitcoin participants is that they wish to remain able to validate the
 blockchain.

 What we need is a way to balance this asymetrical power relationship.

 Proof-of-stake voting gives us a way of achieving that balance.
 Essentially for
 a miner to prove that the majority will of the poeple is to accept a larger
 blocksize they must prove that the majority has in fact voted for that
 increase. The upper limit on the blocksize is then determined by the
 median of
 all votes, where each txout in the UTXO set is one vote, weighted by txout
 value. A txout without a corresponding vote is considered to be a vote for
 the
 status quo. To allow the voting process to continue even if coins are
 lost
 votes, including default votes, are weighted inversely according to their
 age
 in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old
 will be
 recorded the same as a 1 year old vote weighted as 0.67BTC, and a 1 day
 old
 and 6 months old UTXO are treated equivalently. The 1 year minimum is
 simply to
 make voting required no more than once per year. (of course, a real
 implementation should do all of these figures by block height, IE after
 52,560
 blocks instead of after 1 year)

 A vote will consist of a txout with a scriptPubKey of the following form:

 OP_RETURN magic vote_id txid vout vote scriptSig

 Where scriptSig is a valid signature for a transaction with nLockTime
 500,000,000-1 spending txid:vout to scriptPubKey:

 OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL

 vote_id is the ID of the specific vote being made, and magic is included to
 allow UTXO proof implementations a as yet unspecified way of identifying
 votes
 and including the weighted median as part of the UTXO tree sums. (it also
 allows SPV clients to verify the vote if the UTXO set is a Patricia tree of
 scriptPubKeys) vote is just the numerical vote itself. The vote must
 compute
 the median, rather than the mean, so as to not allow someone to skew the
 vote
 by simply setting their value extremely high. Someone who still remembers
 their
 statistics classes should chime in on the right way to compute a median in
 a
 merkle-sum-tree.

 The slightly unusual construction of votes makes implementation by wallet
 software as simple as possible within existing code-paths. Votes could
 still be
 constructed even in wallets lacking specific voting capability provided the
 wallet software does have the ability to set nLockTime.

 Of course in the future the voting mechanism can be used for additional
 votes
 with an additional vote_id. For instance the Bitcoin community could vote
 to
 increase the inflation subsidy, another example of a situation where the
 wishes
 of miners may conflict with the wishes of the broader community.

 Users may of course actually create these specially encoded txouts
 themselves
 and get them into the blockchain.  However doing so is not needed as a
 given
 vote is only required to actually be in the chain by a miner wishing to
 increase the blocksize. Thus we should extend the P2P protocol with a
 mechanism
 by which votes can be broadcast independently of transactions. To prevent
 DoS
 attacks only votes with known vote_id's will be accepted, and only for
 txid:vout's already in the blockchain, and a record of txouts for whom
 votes
 have already broadcast will be kept. (this record need not be
 authoritative as
 its purpose is only to prevent DoS attacks) Miners wishing to increase the
 blocksize can record these votes and include them in the blocks they mine
 as
 required. To reduce the cost of including votes in blocks 5% of every block
 should be assigned to voting only. (this can be implemented by a soft-fork)

 For any given block actual limit in effect is then the rolling median of
 the
 blocks in the last year. At the beginning of every year the value
 considered to
 be the status quo resets to the mean of the limit at the beginning and end
 of
 the interval.  (again, by year we really mean 52,560 blocks) The rolling
 median and periodic reset process ensures that the limit changes gradually
 and
 is not influenced by temporary events such as hacks to large exchanges or
 malicious wallet software.  The rolling median also ensures that for a
 miner
 the act of including a vote is never wasted due to the 

Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Melvin Carvalho
On 10 June 2013 23:09, Peter Todd p...@petertodd.org wrote:

 So here's the parts that need to be done for step #1:


 # Protocol Work

 Basic idea is the miner makes two connections, their pool, and a local
 bitcoind.

 They always (usually?) work on the subset of transactions common to both
 the pool's getblocktemplate and their local one. When they find a share
 if it doesn't meet difficulty they just hand it to the pool. Currently
 that is done by handing the whole block over, correct? I know the BIP
 says otherwise, but we should optimize this to just hand over tx hashes
 where possible.

 If the share does meet difficulty, hand it to both the pool and the
 local bitcoind. Should hand it to the pool first though, because the
 pool likely has the fastest block propagation, then hand it to local
 bitcoind. An optimized version may want to have some record of measured
 bandwidth - this applies Bitcoin in general too, although also has other
 issues.


 ## Reducing bandwidth

 How about for normal shares we just pass the block header, and have the
 pool randomly pick a subset of transactions to audit? Any fraud cancels
 the users shares. This will work best in conjunction with a UTXO proof
 tree to prove fees, or by just picking whole shares randomly to audit.

 We'll need persistent share storage so if your connection disconnects
 you can provide the pool with the full share later though.

 Incedentally, note how the miner can do the reverse: pick random block
 headers and challenge the pool to prove that they correspond to a valid
 block. With some modifications Stratum can support this approach.


 ## Delibrate orphaning of slow to propagate blocks

 Block headers can be flooded-filled much faster than blocks themselves.
 They are also small enough to fit into a UDP packet. Nodes should pass
 headers around separately via UDP, optinally with some tiny number of
 transactions. When we see a valid block header whose contents we do not
 know about a miner should switch to mining empty or near empty blocks in
 solo mode that would orphan the still propagating block. Doing this is
 safe, we'll never build on an invalid block, economically rational while
 the inflation subsidy is still high, and helps reduce (although not
 eliminate!) the advantage a large miner with high-bandwidth connections
 has over those who don't.

 Of course, the other option is to build a block extending the one you
 don't know about, which is even more rational, but doing poses major
 risks to Bitcoin...

 This functionality can be implemented later - it's not strictly part of
 pooled-solo mode.


 # Pool work

 So does eliopool already accept arbitrary shares like this and do the
 correct accounting already? (IE adjust share amount based on fees?) What
 happens when the pool doesn't get the share directly, but does see the
 new block?

 + possible protocol extensions


 # Miner work

 Basically we need code to merge the two block templates together to find
 commonality. I guess you probably want to implement this in bfgminer
 first, so add the code to libblkmaker first, then maybe python-blkmaker.

 We also want an automatic fallback to local solo mining if the pool
 can't be contacted.

 + possible protocol extensions


Sounds very promising.  Suspect it will need a fair amount of testing ...




 --
 'peter'[:-1]@petertodd.org
 005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-06 Thread Melvin Carvalho
On 6 June 2013 21:59, Andreas M. Antonopoulos andr...@rooteleven.comwrote:

 Is there any consideration given to the fact that bitcoin can operate as a
 platform for many other services, if it is able to be neutral to payload,
 as long as the fee is paid for the transaction size?

 Unless I have misunderstood this discussion, it seems to me that this is a
 bit like saying in 1990 IP Is only for email, the majority of users want
 email, we shouldn't allow video, voice or images. Ooops, there goes the
 web.

 Is it possible to solve this by solving the issue of provably un-spendable
 outputs without foreclosing on the possibility of other types of
 transaction payloads (ie, not money), that would open the possibility for a
 myriad of layered apps above? For example, hashes of content that is
 external to bitcoin, that people want to pay to have timestamped in the
 blockchain, as provably unspendable outputs.

 The social compact is to accept transaction for fee. I think it is a major
 mistake to make decisions that discriminate on the content of the
 transaction, saying that some uses are not appropriate. If the fee is paid
 and it covers the size of the transaction, why would it matter if it is not
 a payment?

 I could be totally misreading this thread, too, so please allow me some
 slack if I have!


+1 we're still early into the bitcoin story ... unexpected reuse should not
be ruled out ...






 On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr l...@dashjr.org wrote:

 On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
  scriptPubKey: data OP_TRUE
 
  ...
  Along with that change anyone-can-spend outputs should be make
 IsStandard()
  so they will be relayed.

 Data does not belong in the blockchain. People running nodes have all
 implicitly agreed to store the blocks for financial purposes, and storing
 data
 is a violation of that social contract. Proof-of-stake may be arguably
 financial, but I'm sure there must be a way to do it without spamming
 people
 against their consent.

  The alternative is sacrifices to unspendable outputs, which is very
  undesirable compared to sending the money to miners to further
  strengthen the security of the network.

 The alternative is to make other standard outputs unable to store data as
 well.

 Luke


 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-06 Thread Melvin Carvalho
On 6 June 2013 23:48, Luke-Jr l...@dashjr.org wrote:

 On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
   This doesn't work like you might think: first of all, the fees today
 are
   greatly subsidized - the actual cost to store data in the blockchain is
   much higher than most storage solutions. Secondly, only the miner
 receives
   the fees, not the majority of nodes which have to bear the burden of
 the
   data. That is, the fee system is setup as an antispam/deterrant, not as
   payment for
   storage.
 
  There's a difference between storing the content itself, and storing
 just a
  hash to content (which however is not spendable payment). I undertand why
  content itself doesn't belong. But it goes too far to say that only
  payments should be allowed.

 Because payments are the only thing everyone using Bitcoin has agreed to
 use
 the blockchain for. Furthermore, there is no *reason* to store
 non-payments in
 the blockchain. If there was in fact such a use case, things might be
 arguable
 - but there isn't any I'm aware of.


Two quotes satoshi:

Piling every proof-of-work quorum system in the world into one dataset
doesn't scale.

and

I like Hal Finney's idea for user-friendly timestamping.  Convert the hash
of a file to a bitcoin address and send 0.01 to it

This leads me to believe, that while bitcoin should not be over used as a
time stamp server, there could be a balance reached for casual time stamp
recording as part of satoshi's concept.

What we call spam is to a degree subjective, and I think not always
obvious, tho in some cases it clearly is.


  If the fees are not enough, fix the fee structure, don't stop incredibly
  innovative and promising uses of the distributed timestamping database.
  That is definitely throwing the baby out with the bathwater. If the issue
  is size, then address that, rather than the content itself.

 The issue is using other peoples' resources for something they did not
 agree
 to use it for. The fees aren't merely not enough, they were never
 *intended*
 to be cost of storage. They are cost of security and prevent
 spamming.

  Discriminating based on transaction content violates neutrality of the
  protocol and in my mind removes a very very large possibility of future
  innovation. If bitcoin is a *platform* and not just a payment system,
 then
  it needs to be neutral to content, like TCP/IP so that other protocols
 can
  be layered. Solve the size problem itself, without picking and chosing
  which uses of bitcoin are good and which are bad or spam. I think it
  risks killing a tremendous amount of innovation just as it is starting.

 The concepts behind Bitcoin are applicable to future innovation, but this
 can
 all be accomplished without spamming Bitcoin itself.

   Not the same thing at all; nobody is forced to store/relay
   video/voice/images without reimbursement. On the other hand, any full
   Bitcoin node is required to at least download the entire blockchain
 once.
   And the network as a whole suffers if nodes decide to start not-storing
   parts of the blockchain they don't want to deal with.
  
   So don't store content, but allow hashes of content.
 
  Again, I think it is extreme and extremely restrictive to say that ONLY
  payments are allowed.

 Non-payments are quite possible without the Bitcoin blockchain itself. If
 you're worried that not enough people will store the
 alternative-non-payment
 data, then you are essentially saying that voluntary participation is not
 enough and that forced storage is your solution. I don't think this is what
 you intend...

   This is how merged mining solves the problem. A single extra hash in
 the
   coinbase can link the bitcoin blockchain up with unlimited other data.
 
  Can you explain this part or refer me to some docs? What do you mean by
  coinbase, I assume not the company.

 The Bitcoin blockchain protocol has 95 bytes per block reserved for miners
 to
 put extra data. Currently, this is used for extranonces, political or other
 short messages (such as in the Genesis block), miner signatures, and
 also,
 as I mentioned, merged mining. Merged mining works by tying a non-
 transactional merkle tree to the blockchain. The block coinbase stores the
 hash of the top of this merkle tree, so any data within the merkle tree can
 prove it is associated to the block. The merged mining merkle tree then
 stores
 hashes of multiple other data sets: for example, a Namecoin block can be
 referenced in a merged mining merkle tree, to use the Bitcoin block's
 proof-
 of-work for itself (so, miners can mine both Bitcoin and Namecoin using the
 same hashing effort). You could also add other non-transactional blocks to
 the
 merged mining merkle tree, for generic timestamping or really anything at
 all.

 Luke


 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT 

Re: [Bitcoin-development] Revocability with known trusted escrow services?

2013-06-06 Thread Melvin Carvalho
On 6 June 2013 02:19, Peter Vessenes pe...@coinlab.com wrote:

 So, this
 http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
  article got posted today, noting that FinCEN thinks irrevocable payments
 are money laundering tools.

 I will hold my thoughts about the net social good of rent-seeking large
 corporations taking money from consumers over fraudulent reversals.
 Actually, I won't, I just said it.

 At any rate, it got me thinking, can we layer on revocability somehow
 without any protocol change, as an opt-in?

 My initial scheme is a trusted (hah) escrow service that issues time
 promises for signing. If it doesn't receive a cancel message, it will sign
 at the end of the time.

 The addresses would be listed by the escrow service, or in an open
 registry, so you could see if you were going to have a delay period when
 you saw a transaction go out.

 This seems sort of poor to me, it imagines that mythical thing, a trusted
 escrow service, and is vulnerable to griefing, but I thought I'd see if
 some of the brighter minds than me can come up with a layer-on approach
 here.

 When I think about it, I can imagine that I would put a good number of my
 coins in a one day reversible system, because I would have warning if
 someone wanted to try and spend them, and could do something about it. I'm
 not sure if it gets me anything over a standard escrow arrangement, though.


Also see satoshi's comments on this, though it may be restating what others
have said:

https://bitcointalk.org/index.php?topic=750.0

Here's an outline of the kind of escrow transaction that's possible in
software.  This is not implemented and I probably won't have time to
implement it soon, but just to let you know what's possible.

The basic escrow: The buyer commits a payment to escrow. The seller
receives a transaction with the money in escrow, but he can't spend it
until the buyer unlocks it. The buyer can release the payment at any time
after that, which could be never. This does not allow the buyer to take the
money back, but it does give him the option to burn the money out of spite
by never releasing it. The seller has the option to release the money back
to the buyer.

While this system does not guarantee the parties against loss, it takes the
profit out of cheating.

If the seller doesn't send the goods, he doesn't get paid. The buyer would
still be out the money, but at least the seller has no monetary motivation
to stiff him.

The buyer can't benefit by failing to pay. He can't get the escrow money
back. He can't fail to pay due to lack of funds. The seller can see that
the funds are committed to his key and can't be sent to anyone else.

Now, an economist would say that a fraudulent seller could start
negotiating, such as release the money and I'll give you half of it back,
but at that point, there would be so little trust and so much spite that
negotiation is unlikely. Why on earth would the fraudster keep his word and
send you half if he's already breaking his word to steal it? I think for
modest amounts, almost everyone would refuse on principle alone.



 Peter

 --

 --

 [image: CoinLab Logo]PETER VESSENES
 CEO

 *pe...@coinlab.com * /  206.486.6856  / SKYPE: vessenes
 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104


 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Fwd: Creating a Currency for the (Read / Write) Web

2013-06-05 Thread Melvin Carvalho
FYI: I think this may be a possible blue print for a web version of
bitcoin+ripple combined.

-- Forwarded message --
From: Melvin Carvalho melvincarva...@gmail.com
Date: 5 June 2013 18:50
Subject: Creating a Currency for the (Read / Write) Web
To: public-rww public-...@w3.org, Nathan Rixham nrix...@gmail.com, Web
Payments public-webpayme...@w3.org


I've been thinking for a while about how to create a currency for the read
write web.  And I thought I'd share some preliminary ideas.  Essentially
this is bitcoin+ripple translated to the Web.

*Introduction

*
For those not familiar with the bitcoin concept it's essentially a
distributed ledger where each subject is a primary key in the ledger and
can hold 0 or more coins.  Coins are transferred using a signed and
timestamped PKI transaction log from one address to another, in a
distributed data base.

*Addresses

*
I think using a portable URI for addresses is the thing that makes most
sense.  So possibilities for this may be a URN, or schemes such as di:
(digest) or ni: (named information).  Anyone should be able to generate an
address, and they should be wide ranging to improve liquidity.

*Balances

*
Balances can be calculated by summing all inputs to that address.  You can
additionally keep a state of balances using the payswarm vocab, or perhaps,
goodRelations

*Transactions

*
I think a distributed data base could be maintained using read / write web
technologies, such as HTTP POST / PATCH or SPARQL Update.  The signatures
could be added using the WebKeys spec.

*Distributed Database

*
There are challenges associated with maintaining a distributed database.  I
suggest we start small and whoever opts in can become part of the
verification process.  There are two recent methods for mitigating race
conditions an important one of which is called double spend.  One is
proof of work, the other is consensus based on a unique node list.  I would
suggest using both techniques.  I'd like it to be possible to use both HTTP
(with self signed certificates), HTTP, and (secure) websockets too as the
transport layer.

*Coin Creation

*
This tends to be the most contentious point, with people tending not to
like the premine concept where you allocate coins to yourself.  However
companies like opencoin have successfully rolled out multi million or even
billion dollar premine schemes.  I would suggest coin creation in line with
bitcoin, where they are created proportionally to those maintaining the
integrity of rhe shared database.

*Spam Protection

*
Given the nature of the system, it may be easy to spam the network with
micro transactions.  As such there should be a transaction fee where those
that pay the highest fee are prioritized.

*Trust and Reputation

*
I think it would also help to have a trust and reputation system added to
the process, such that honest nodes benefit from acting honestly, and nodes
which are dishonest or not up to date are considered less dubious.  The
nature of the function should be that it's exponentially harder to gain
trust after you have a certain score.  Similar to chess ELO ratings.

*Linked Data and Exensibility

*
I think there should be a deep integration with web principles and linked
data to promote an app eco system and allow unexpected reuse.  Also it
should allow extensions such as the ripple protocol's trust lines, IOUs and
distributed markets, which are not initially scoped out.  Reusing existing
concepts such as the bitcon blockchain (e.g. so-called coloured coins),
ripple ledger, opentransactions, payswarm and web credits should all be
doable.


Just some food for thought.  Criticisms welcome.  Please let me know if
you're interested in running a node, and maybe we an get a reference
implementation going, as proof of concept.
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Revocability with known trusted escrow services?

2013-06-05 Thread Melvin Carvalho
On 6 June 2013 02:19, Peter Vessenes pe...@coinlab.com wrote:

 So, this
 http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
  article got posted today, noting that FinCEN thinks irrevocable payments
 are money laundering tools.


It's great that this article quotes the first page of Sasoshi's white
paper.  There are some other text that they missed, though, which I think
may be relevant.

[[
Completely non-reversible transactions are not really possible, since
financial institutions cannot
avoid mediating disputes. The cost of mediation increases transaction
costs, limiting the
minimum practical transaction size and cutting off the possibility for
small casual transactions,
and there is a broader cost in the loss of ability to make non-reversible
payments for non-
reversible services. With the possibility of reversal, the need for trust
spreads. Merchants must
be wary of their customers, hassling them for more information than they
would otherwise need.
A certain percentage of fraud is accepted as unavoidable. These costs and
payment uncertainties
can be avoided in person by using physical currency, but no mechanism
exists to make payments
over a communications channel without a trusted party.

What is needed is an electronic payment system based on cryptographic proof
instead of trust,
allowing any two willing parties to transact directly with each other
without the need for a trusted
third party. Transactions that are computationally impractical to reverse
would protect sellers
from fraud, and routine escrow mechanisms could easily be implemented to
protect buyers.
]]



 I will hold my thoughts about the net social good of rent-seeking large
 corporations taking money from consumers over fraudulent reversals.
 Actually, I won't, I just said it.

 At any rate, it got me thinking, can we layer on revocability somehow
 without any protocol change, as an opt-in?

 My initial scheme is a trusted (hah) escrow service that issues time
 promises for signing. If it doesn't receive a cancel message, it will sign
 at the end of the time.

 The addresses would be listed by the escrow service, or in an open
 registry, so you could see if you were going to have a delay period when
 you saw a transaction go out.

 This seems sort of poor to me, it imagines that mythical thing, a trusted
 escrow service, and is vulnerable to griefing, but I thought I'd see if
 some of the brighter minds than me can come up with a layer-on approach
 here.

 When I think about it, I can imagine that I would put a good number of my
 coins in a one day reversible system, because I would have warning if
 someone wanted to try and spend them, and could do something about it. I'm
 not sure if it gets me anything over a standard escrow arrangement, though.

 Peter

 --

 --

 [image: CoinLab Logo]PETER VESSENES
 CEO

 *pe...@coinlab.com * /  206.486.6856  / SKYPE: vessenes
 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104


 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] WebCryto standard to support secp256r1 but not secp256k1

2013-05-29 Thread Melvin Carvalho
On 7 May 2013 12:18, Melvin Carvalho melvincarva...@gmail.com wrote:

 Looking at the proposed native crypto browser support (should arrive in
 the next year)

 http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary

 We see:

 enum NamedCurve {
   // NIST recommended curve P-256, also known as secp256r1.
   P-256,
   // NIST recommended curve P-384, also known as secp384r1.
   P-384,
   // NIST recommended curve P-521, also known as secp521r1.
   P-521
 };

 I wonder if we might be able to get bitcoin's curve in there

 For more background on Koblitz curve used by bitcoin see:

 https://bitcointalk.org/?topic=2699.0


Hi All

I enuired about this and got the following reply, from the chair of the
crypto group:

[[
Just email public-webcrypto-comme...@w3.org. It's a public list. Do
definitely mention your use-cases!

I think there's issues of whether NSS etc. already support it. I think the
answer here is no but David can clarify. The goal is not to get browser
vendors to write new crypto code, but to expose the crypto code that
already exists.

We still have an open issue about whether experimental registry for
identifiers for say, new curves that aren't in the core spec, will be
maintained. So, maybe if browsers don't support it today, it's always
possible they might want to support it tomorrow given Bitcoin's growth.
]]

Please let me know if anyone has a use case for ecdsa in the browser let me
know.

Or if anyone would like to write to the public list that's fine

Otherwise I'll just fire off a mail and see what they come back with ...
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Melvin Carvalho
On 21 May 2013 01:59, Mark Friedenbach m...@monetize.io wrote:

 At the developer round-table it was asked if the payment protocol would
 alt-chains, and Gavin noted that it has a UTF-8 encoded string
 identifying the network (main or test). As someone with two
 proposals in the works which also require chain/coin identification (one
 for merged mining, one for colored coins), I am opinionated on this. I
 believe that we need a standard mechanism for identifying chains, and
 one which avoids the trap of maintaining a standard registry of
 string-to-chain mappings.

 Any chain can be uniquely identified by its genesis block, 122 random
 bits is more than sufficient for uniquely tagging chains/colored assets,
 and the low-order 16-bytes of the block's hash are effectively random.
 With these facts in mind, I propose that we identify chains by UUID.

 So as to remain reasonably compliant with RFC 4122, I recommend that we
 use Version 4 (random) UUIDs, with the random bits extracted from the
 double-SHA256 hash of the genesis block of the chain. (For colored
 coins, the colored coin definition transaction would be used instead,
 but I will address that in a separate proposal and will say just one
 thing about it: adopting this method for identifying chains/coins will
 greatly assist in adopting the payment protocol to colored coins.)

 The following Python code illustrates how to construct the chain
 identifier from the serialized genesis block:

  from hashlib import sha256
  from uuid import UUID
  def chain_uuid(serialized_genesis_block):
  h = sha256(serialized_genesis_block).digest()
  h = sha256(h).digest()
  h = h[:16]
  h = ''.join([
  h[:6],
  chr(0x40 | ord(h[6])  0x0f),
  h[7],
  chr(0x80 | ord(h[8])  0x3f),
  h[9:]
  ])
  return UUID(bytes=h)

 And some example chain identifiers:

  mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
  testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
  namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')

 As for encoding the chain identifier, the simplest method is to give
 network the bytes type, but defining a UUID message type is also
 possible. In either case bitcoin mainnet would be the default, so the
 extra 12 bytes (vs: main or test) would only be an issue for
 alt-chains or colored coins.


This is essentially name spacing.  As registries grow namespaces become
more important.  In bitcoin's quest for decentrality there's also the
question of who maintains the registry.

Some out of band algo/hash could work so long as there was a one to one
relationship between the described object and the UUID.  In this case the
gensis block may not uniquely identify a coin.

The normal way to namespace a registry on the internet is to allow it to be
a URI.  In this case an http style uri has the added bonus side effect that
it can be dereferencable and both human and machine readable.  So yes
something like org.bitcoin.* is good, just simply growing things to http
style uris is cleaner, imho



 Kind regards,
 Mark Friedenbach


 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Melvin Carvalho
On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote:

 On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
 melvincarva...@gmail.com wrote:
  Some out of band algo/hash could work so long as there was a one to one
  relationship between the described object and the UUID.  In this case the
  gensis block may not uniquely identify a coin.

 What does this mean?  It seems extremely unlikely that two different
 genesis blocks will have the same hash.


Two coin ecosystems could have the same genesis block



 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy

2013-05-15 Thread Melvin Carvalho
On 15 May 2013 13:38, Peter Todd p...@petertodd.org wrote:

 Now that I have the replace-by-fee reward, I might as well spread the
 wealth a bit.


 So for all this discussion about replace-by-fee and the supposed
 security of zero-conf transactions, no-one seems to think much about how
 in practice very few vendors have a setup to detect if conflicting
 transactions were broadcast on the network simultaneously - after all if
 that is the case which transaction gets mined is up to chance, so much
 of the time you'll get away with a double spend. We don't yet have a
 mechanism to propagate double-spend warnings, and funny enough, in the
 case of a single txin transaction the double-spend warning is also
 enough information to allow miners to implement replace-by-fee.


 So I'm offering 2BTC for anyone who comes up with a nice and easy to use
 command line tool that lets you automagically create one version of the
 transaction sending the coins to the desired recipient, and another
 version sending all the coins back to you, both with the same
 transaction inputs. In addition to creating the two versions, you need
 to find a way to broadcast them both simultaneously to different nodes
 on the network. One clever approach might be to use blockchain.info's
 raw transaction POST API, and your local Bitcoin node.

 If you happen to be at the conference, a cool demo would be to
 demonstrate the attack against my Android wallet. I'll buy Bitcoins off
 of you at Mt. Gox rates + %10, and you can see if you can rip me off.
 Yes, you can keep the loot. :) This should be videotaped so we can put
 an educational video on youtube after.


Isnt it potentially inviting trouble by encouraging people to insert double
spends into the block chain?

Sure, zero conf isnt 100% safe, we all know that.

But neither is the postal service.  Doesnt mean we should be going around
promoting the creation of tools to go into people's maiilboxes and open
their letters!



 --
 'peter'[:-1]@petertodd.org
 00bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5


 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Melvin Carvalho
On 14 May 2013 20:41, Peter Todd p...@petertodd.org wrote:

 report: https://bitcointalk.org/index.php?topic=205349.0

 Every talk will be widely witnessed and videotaped so we can get some
 reasonably good security by simply putting out PGP fingerprints in our
 slides. Yeah, some fancy attacker could change the videos after the
 fact, but the talks themselves will have wide audiences and a lot of
 opportunities for fraud to be discovered. That means it'd also be
 reasonable for people to sign those keys too if you are present and are
 convinced you aren't looking at some impostor. (of course, presenters,
 check that your PGP fingerprints are correct...)


 Remember that PGP depends on the web-of-trust. No single measure in a
 web-of-trust is needs to be absolutely perfect; it's the sum of the
 verifications that matter. I don't think it matters much if you have,
 say, seen Jeff Garzik's drivers license as much as it matters that you
 have seen him in a public place with dozens of witnesses that would
 recognize him and call out any attempt at fraud.

 Secondly remember that many of us are working on software where an
 attacker can steal from huge numbers of users at once if they manage to
 sneak some wallet stealing code in. We need better code signing
 practices, but they don't help without some way of being sure the keys
 signing the code are valid. SSL and certificate authorities have
 advantages, and so does the PGP WoT, so use both.


 FWIW I take this stuff pretty seriously myself. I generated my key
 securely in the first place, I use a hardware smartcard to store my PGP
 key, and I keep the master signing key - the key with the ability to
 sign other keys - separate from my day-to-day signing subkeys. I also
 PGP sign emails regularly, which means anyone can get a decent idea of
 if they have the right key by looking at bitcoin-development mailing
 list archives and checking the signatures. A truly dedicated attacker
 could probably sign something without my knowledge, but I've certainly
 raised the bar.


Just out of curiosity, could PGP keyservers suffer from a similar 51%
attack as the bitcoin network?



 --
 'peter'[:-1]@petertodd.org
 016be577c0f0ce4c04a05fdbfc8e0b6f69053659f32aeea3a518


 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] WebCryto standard to support secp256r1 but not secp256k1

2013-05-07 Thread Melvin Carvalho
Looking at the proposed native crypto browser support (should arrive in the
next year)

http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary

We see:

enum NamedCurve {
  // NIST recommended curve P-256, also known as secp256r1.
  P-256,
  // NIST recommended curve P-384, also known as secp384r1.
  P-384,
  // NIST recommended curve P-521, also known as secp521r1.
  P-521
};

I wonder if we might be able to get bitcoin's curve in there

For more background on Koblitz curve used by bitcoin see:

https://bitcointalk.org/?topic=2699.0
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Sending Bitcoins using RSA keys

2013-04-27 Thread Melvin Carvalho
On 24 April 2013 16:46, Craig B Agricola cr...@theagricolas.org wrote:

 Maybe I'm missing something crucial, but what benefit does this dance give
 over
 the slightly more obvious mechanism of simply:
 1) Alice generates a new address with her bitcoin client and sends the BTC
 to
this new address
 2) Alice exports the private key for that address (there is a well
 supported
format for that)
 3) Alice writes a nice email to Bob, including that exported private key
 4) Alice encrypts the email with Bob's public key using GPG and sends it
 to him
by email
 5) Bob decrypts the email
 6) Bob imports the private key into his wallet


Yes this works too.

However is it dependent on the bitcoin client address generation algorithm?

I think what I'm trying to describe is something more akin to the way a
shared secret is generated by TLS.

Agree, that the wallet is also shared, ive not yet worked out a way to
'blind' one side of the wallet, but nor have a proved it's impossible, so
still working onthat :)



 There's no need for sending a whole wallet; just the one key is needed.
  Every
 bit of infrastructure needed above already exists.  And of course, the
 above
 has the same issue as your proposal; this is a way for two trusting
 parties to
 send BTC without using the Bitcoin network, but it's not a payment
 mechanism.
 They now share control of an address; whoever spends that BTC first wins,
 so
 until Bob uses the Bitcoin network to spend that BTC to another address
 that
 only he controls, it's still in joint custody.  And if ensuring that he has
 control of the BTC is the last (implicit) step in the procedure above, as
 well
 as yours, then they might as well have simply used the Bitcoin network to
 do
 the transfer in the first place.

 Did I miss the point entirely?


Perhaps I've not described the problem statement as clearly as I could,
I'll work on it.  Essentially it's an automated way to bootstrap the RSA
key community together with bitcoin.  e.g. 99% of GPG users probably dont
have a bitcion wallet or address or client.  I think maybe a user story
will help.



  -Craig

 PS. Re-reading, I realize that the above might come off sounding snarky or
 dismissive; it's not intended that way.  I'm wondering if I'm missing
 the
 big picture.


Not snarky at all!  Appreciate the feedback...



 On Wed, Apr 24, 2013 at 04:18:38PM +0200, Melvin Carvalho wrote:
  So there's a slight world divide in digital payments with bitcoin using
  ECDSA and GPG, payswarm / webid etc using largely RSA
 
  Here's how to bring the two worlds together and enable bitcoins be sent
  over webid or payswarm
 
 
  Problem: Alice and Bob have RSA key pairs, but no public bitcoin
  addresses.  Alice wants to send 1 BTC to Bob.
 
  1. Alice takes Bob's WebID and encrpyts it with her private key (to
 create
  entropy) ...
 
  2. Alice uses that message as the seed to produce btc address (as per
  http://brainwallet.org ) with ECDSA key pair
 
  3. Alice sends coins to this address
 
  4. Alice and then encrypts the seed again with Bob's public key
 
  5. Bob decrypts the seed using his private key
 
  6. Bob can now use the seed to recreate the wallet and spend the coins
 
  Unless I've made an error, I believe this unites the web paradigm and
  crypto currency paradigm into one potentially giant eco system ...

 
 --
  Try New Relic Now  We'll Send You this Cool Shirt
  New Relic is the only SaaS-based application performance monitoring
 service
  that delivers powerful full stack analytics. Optimize and monitor your
  browser, app,  servers with just a few lines of code. Try New Relic
  and get this awesome Nerd Life shirt!
 http://p.sf.net/sfu/newrelic_d2d_apr

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


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Sending Bitcoins using RSA keys

2013-04-24 Thread Melvin Carvalho
So there's a slight world divide in digital payments with bitcoin using
ECDSA and GPG, payswarm / webid etc using largely RSA

Here's how to bring the two worlds together and enable bitcoins be sent
over webid or payswarm


Problem: Alice and Bob have RSA key pairs, but no public bitcoin
addresses.  Alice wants to send 1 BTC to Bob.

1. Alice takes Bob's WebID and encrpyts it with her private key (to create
entropy) ...

2. Alice uses that message as the seed to produce btc address (as per
http://brainwallet.org ) with ECDSA key pair

3. Alice sends coins to this address

4. Alice and then encrypts the seed again with Bob's public key

5. Bob decrypts the seed using his private key

6. Bob can now use the seed to recreate the wallet and spend the coins

Unless I've made an error, I believe this unites the web paradigm and
crypto currency paradigm into one potentially giant eco system ...
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Web Payments with PaySwarm: Identity (part 1 of 3)

2013-04-16 Thread Melvin Carvalho
FYI: this is worth a read for anyone interested in the payment ecosystem on
the WWW ... it's about 5 years of work, and there's a even hope to
integrate bitccoin too ...

https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/

I've cc'd Manu in case anyone here has any questions!
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] A mining pool at 46%

2013-04-05 Thread Melvin Carvalho
There was some chat on IRC about a mining pool reaching 46%

http://blockchain.info/pools

What's the risk of a 51% attack.

I suggested that the pool itself is decentralized so you could not launch
one

On IRC people were saying that the pool owner gets to choose what goes in
the block

Surely with random non colliding nonces, it would be almost impossible to
coordinate a 51% even by the owner

Someone came back and said that creating random numbers on a GPU is hard.
But what about just creating ONE random number and incrementing from there
...

It would be great to know if this is a threat or a non issue
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin meets the Semantic Web....

2013-04-01 Thread Melvin Carvalho
I'm working on porting crypto currencies to the semantic web.

The advantages of this is that pages can then become machine readable on
the web allowing new types of innovation and spreading bitcoin information
to a wider audience.

The first step that needs to be done is to create a vocabulary for
bitcoin.

What this means is like a dictionary of terms that can be put down in a
machine readable standard (called RDF).

I was wondering if anyone has worked on this before or if there is a human
readable glossary for bitcoin that I could take text from?

seeAlso: https://bitcointalk.org/index.php?topic=163705.0
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] bitcoin pull requests

2013-04-01 Thread Melvin Carvalho
I was just looking at:

https://bitcointalk.org/index.php?topic=4571.0

I'm just curious if there is a possible attack vector here based on the
fact that git uses the relatively week SHA1

Could a seemingly innocuous pull request generate another file with a
backdoor/nonce combination that slips under the radar?

Apologies if this has come up before ...
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoin pull requests

2013-04-01 Thread Melvin Carvalho
On 1 April 2013 20:28, Petr Praus p...@praus.net wrote:

 An attacker would have to find a collision between two specific pieces of
 code - his malicious code and a useful innoculous code that would be
 accepted as pull request. This is the second, much harder case in the
 birthday problem. When people talk about SHA-1 being broken they actually
 mean the first case in the birthday problem - find any two arbitrary values
 that hash to the same value. So, no I don't think it's a feasible attack
 vector any time soon.

 Besides, with that kind of hashing power, it might be more feasible to
 cause problems in the chain by e.g. constantly splitting it.


OK, maybe im being *way* too paranoid here ... but what if someone had
access to github, could they replace one file with one they had prepared at
some point?




 On 1 April 2013 03:26, Melvin Carvalho melvincarva...@gmail.com wrote:

 I was just looking at:

 https://bitcointalk.org/index.php?topic=4571.0

 I'm just curious if there is a possible attack vector here based on the
 fact that git uses the relatively week SHA1

 Could a seemingly innocuous pull request generate another file with a
 backdoor/nonce combination that slips under the radar?

 Apologies if this has come up before ...


 --
 Own the Future-Intelreg; Level Up Game Demo Contest 2013
 Rise to greatness in Intel's independent game demo contest.
 Compete for recognition, cash, and the chance to get your game
 on Steam. $5K grand prize plus 10 genre and skill prizes.
 Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoin pull requests

2013-04-01 Thread Melvin Carvalho
On 2 April 2013 00:10, Will w...@phase.net wrote:

 The threat of a SHA1 collision attack to insert a malicious pull request
 are tiny compared with the other threats - e.g. github being compromised,
 one of the core developers' passwords being compromised, one of the core
 developers going rogue, sourceforge (distribution site) being compromised
 etc etc... believe me there's a lot more to worry about than a SHA1
 attack...

 Not meaning to scare, just to put things in perspective - this is why we
 all need to peer review each others commits and keep an eye out for
 suspicious commits, leverage the benefits of this project being open source
 and easily peer reviewed.


Very good points, and I think you're absolutely right.

But just running the numbers, to get the picture, based of scheiner's
statistics:

http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

We're talking about a million terrahashes = 2^60 right?

With the block chain, you only have a 10 minute window, but with source
code you have a longer time to prepare.

Couldnt this be done with an ASIC in about a week?




 Will


 On 1 April 2013 23:52, Melvin Carvalho melvincarva...@gmail.com wrote:




 On 1 April 2013 20:28, Petr Praus p...@praus.net wrote:

 An attacker would have to find a collision between two specific pieces
 of code - his malicious code and a useful innoculous code that would be
 accepted as pull request. This is the second, much harder case in the
 birthday problem. When people talk about SHA-1 being broken they actually
 mean the first case in the birthday problem - find any two arbitrary values
 that hash to the same value. So, no I don't think it's a feasible attack
 vector any time soon.

 Besides, with that kind of hashing power, it might be more feasible to
 cause problems in the chain by e.g. constantly splitting it.


 OK, maybe im being *way* too paranoid here ... but what if someone had
 access to github, could they replace one file with one they had prepared at
 some point?




 On 1 April 2013 03:26, Melvin Carvalho melvincarva...@gmail.com wrote:

  I was just looking at:

 https://bitcointalk.org/index.php?topic=4571.0

 I'm just curious if there is a possible attack vector here based on the
 fact that git uses the relatively week SHA1

 Could a seemingly innocuous pull request generate another file with a
 backdoor/nonce combination that slips under the radar?

 Apologies if this has come up before ...


 --
 Own the Future-Intelreg; Level Up Game Demo Contest 2013
 Rise to greatness in Intel's independent game demo contest.
 Compete for recognition, cash, and the chance to get your game
 on Steam. $5K grand prize plus 10 genre and skill prizes.
 Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development





 --
 Own the Future-Intelreg; Level Up Game Demo Contest 2013
 Rise to greatness in Intel's independent game demo contest.
 Compete for recognition, cash, and the chance to get your game
 on Steam. $5K grand prize plus 10 genre and skill prizes.
 Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-17 Thread Melvin Carvalho
On 17 December 2012 03:18, Jeff Garzik jgar...@exmulti.com wrote:

 On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
 melvincarva...@gmail.com wrote:
  On 3 December 2012 20:35, Mike Koss m...@coinlab.com wrote:
  It would also be really nice to migrate to textual representations of
 data
  structures as opposed to binary ones.  The most successful internet
  standards are based on text, making them that much more accessible for
  developers to deal with them.   JSON would be my preferred candidate.
 
  Why don't we sign the text representation of a (utf8) JSON, rather than
  some complex encoding standard of JSON?  That way the signatures are
 simple
  - and you need only retain the original textual representation of a
 message
  to validate the signature (as well as the decoded version, if you don't
 want
  to alway re-parse the message when writing programs that use it).

  Binary formats can be challenging to deal with and convert to other
 formats.
  The experiences in the PKI world of ASN.1 have not been great, in terms
 of
  interop.  It tends to create islands and silos.  This is probably one of
 the
  reasons why X.509 and GPG are fragmented and why we dont really have a
  widely deployed web of trust on the net.  Another reason is simply lack
 of
  developer resources to make tools.  In that respect I think JSON offers
  significant advantages, though I am interested in the security issues
  raised.

 I thought this had already been covered up-thread?

 When creating something that must be hashed and/or compared, the data
 structure must be created and reproduced precisely, byte-for-byte.
 JSON offers significant -disadvantages- in this regard.  With JSON,
 you would therefore require an additional middle layer, between JSON
 and application, ensuring that all fields are output in the same
 order, all whitespace is not only perfectly preserved -- but reliably
 generates identical whitespace output for identical inputs, given two
 separate JSON implementations.


Apologies if I am a bit late to the thread.  I bumped into someone that
suggested I take a look at it.  Will try and catch up!

You raise a good point.

Is there no good canonicalization algorithm / library for JSON?

I think that provided that each JSON object has an identifier,
canonicalization of JSON is not that hard.

Then when you hash or sign the canonical form they can be compared reliably.



 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-17 Thread Melvin Carvalho
On 17 December 2012 10:19, Mike Hearn m...@plan99.net wrote:

 Can we please drop the binary vs text issue? We have been around it
 millions of times already. There are no compelling arguments to use
 text here and several obvious problems with it. If you think you've
 found a good argument to use JSON, please research protocol buffers
 more thoroughly and see if it changes your mind.


Hi Mike, thanks you for the pointer.  I have read up on Protocol Buffers.

If the decision has already been made, then let's go with that, but if not
perhaps I can offer some comments.

Looking at:

http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

And -- Canonically, Protocol Buffers are serialized into a binary wire
format which is compact, forwards-compatible, backwards-compatible, but not
self-describing

I can see there are advantages in this approach in that you can send
messages quickly and with low bandwidth.  However the non self describing
data means that it's significantly harder to convert from one format to
another.  Also references are important, and can be achieved in JSON.

Yet in my opinion there is great advantage to growing the bitcoin ecosystem
to interoperate with the whole net, kind of creating a complete web
economy.  The way to do this is to foster interoperability.  Having looked
at and worked with standards for the past 5-10 years that is the great
challenge.  Every system works in an island, and few talk to any others.
However, a market based economy grows exponentially more valuable with
extra liquidity.

Inventing yet another format may lead to balkanization.  If history is a
judge, the chances are high.  A self describing JSON format, however is
much more likely to interop.

I can understand the hesitation with JOSE.  However, if you get a moment,
please look at :

http://payswarm.com/specs/source/web-keys/

This should provide some of the tools that you need.

As I said above, if the matter is closed, that's fine and thanks for taking
the time to read.

Can I at least propose to make it mandatory for the binary format to have a
translation script to a self describing JSON format and back again.  I
would love to see the bitcoin ecosystem become a major part of the
infrastructure of the web itself (leading to even nice things like a proper
web of trust), as well as an awesome P2P system in its own right.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-16 Thread Melvin Carvalho
On 3 December 2012 20:35, Mike Koss m...@coinlab.com wrote:

 The thing that bugged me most about the original spec was the sole
 reliance on X.509 - glad to see you've made that optional.  I think many
 people will balk at deferring our identity trust to the existing CA's.  I
 think it's a fine bootstrap method, but I'd really like to see another
 option that allows for out-of-band trust (based on ECDSA, probably).

 It would also be really nice to migrate to textual representations of data
 structures as opposed to binary ones.  The most successful internet
 standards are based on text, making them that much more accessible for
 developers to deal with them.   JSON would be my preferred candidate.

 Why don't we sign the text representation of a (utf8) JSON, rather than
 some complex encoding standard of JSON?  That way the signatures are simple
 - and you need only retain the original textual representation of a message
 to validate the signature (as well as the decoded version, if you don't
 want to alway re-parse the message when writing programs that use it).


Binary formats can be challenging to deal with and convert to other
formats.  The experiences in the PKI world of ASN.1 have not been great, in
terms of interop.  It tends to create islands and silos.  This is probably
one of the reasons why X.509 and GPG are fragmented and why we dont really
have a widely deployed web of trust on the net.  Another reason is simply
lack of developer resources to make tools.  In that respect I think JSON
offers significant advantages, though I am interested in the security
issues raised.



 On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen 
 gavinandre...@gmail.comwrote:

 Spec updated: https://gist.github.com/4120476

 Changes are:

 Version numbers:  a couple of people asked privately about adding
 version numbers to the messages. In general, Protocol Buffers don't
 need version numbers if later versions add only optional fields.

 And best-practice is to know what version of something you're
 expecting BEFORE you start parsing that something.

 So, if a bitcoin client is getting Invoice messages via email or from
 a web server, the version will be specified as part of the MIME type;
 for example:
Content-Type: application/x-bitcoin-invoice; version=1
 The version= syntax is part of the MIME standard.

 Following that best-practice of knowing what you're parsing before you
 parse it, I added an invoice_version field to the SignedInvoice
 message. It is now:

 message SignedInvoice {
 required bytes pki_data = 1;
 required string pki_type = 2 [default = x509];
 required bytes serialized_invoice = 3;
 required uint32 invoice_version = 4 [default = 1];
 required bytes signature = 5;
 }


 Handling of receiptURI errors:

 Following discussion here, I changed the spec to say:

 Clients may handle errors communicating with the receiptURI server
 however they like, but should assume that if they cannot communicate
 at all with the server then the Payment should either be retried later
 or immediately rejected.

 and under Receipt added:

 The Bitcoin client must be prepared to handle the case of an evil
 merchant that returns accepted=false but broadcasts the transactions
 anyway.


 I also added a TODO Test Vectors section with base64-encoded
 examples of everything.

 --
 --
 Gavin Andresen


 --
 Keep yourself connected to Go Parallel:
 INSIGHTS What's next for parallel hardware, programming and related areas?
 Interviews and blogs by thought leaders keep you ahead of the curve.
 http://goparallel.sourceforge.net
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 Mike Koss
 CTO, CoinLab
 (425) 246-7701 (m)

 A Bitcoin Primer http://coinlab.com/a-bitcoin-primer.pdf - What you
 need to know about Bitcoins.



 --
 Keep yourself connected to Go Parallel:
 BUILD Helping you discover the best ways to construct your parallel
 projects.
 http://goparallel.sourceforge.net
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net