[Bitcoin-development] Mining Hashrate Caps

[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] Does anyone have anything at all signed by Satoshi's PGP key?

[Melvin Carvalho]

On 15 September 2014 09:23, Thomas Zander  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=157508191&iu=/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=157508191&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Melvin Carvalho]

On 27 September 2014 15:56, Wladimir  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=` and `-maxorphanblocks=` 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=154622311&iu=/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=154622311&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.so

[Bitcoin-development] Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)

[Melvin Carvalho]

FYI:

This is an issue I filed related to adding secp256k1 into Web Crypto API
which will be implemented natively in (some) web browsers.

If there is any feedback from crypto implementers, please feel free to add
comments to this thread:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=2

-- Forwarded message --
From: 
Date: 13 October 2014 09:18
Subject: [Bug 2] Named Curve Registry (adding secp256k1)
To: melvincarva...@gmail.com


https://www.w3.org/Bugs/Public/show_bug.cgi?id=2

Myron Davis  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||myr...@gmail.com
 Resolution|NEEDSINFO   |---

--- Comment #2 from Myron Davis  ---
Could this be looked at again?

Last response was waiting for feedback from crypto implementors.

Currently secp256k1 is supported in the following SSL/TLS libraries now
Botan
NSS
openssl
LibreSSL
PolarSSL
JSSE

The three other curves are all all have parameters which do not define how
they
were generated.  secp256k1 curve has some great advantages in faster
signature
verification and how the values were determined for the curve.  (i.e. not
random).

http://www.ietf.org/rfc/rfc4492

The curve has had a lot of eyes on it with lots of hardware and software
supporting this curve.

With discovery of backdoor's in NIST's random number generator
(https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I
would
like to see a determined parameter curve instead of a "random" curve option.

Thanks

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

Re: [Bitcoin-development] Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)

[Melvin Carvalho]

FYI:

"In order to progress towards exit to Last Call for the Web Crypto API, the
chair suggests the following resolution for that bug.

resolution : Bug CLOSED. This problem will be addressed by the extension bug
25618 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618.

If none objects before the 20th of Oct @20:00 UTC, this resolution will be
endorsed."

On 13 October 2014 19:18, Matt Corallo  wrote:

> See-also: this related bug on Curve25519 and some MS Research curves
> that generated far more discussion.
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
>
> Matt
>
> On 10/13/14 10:01, Melvin Carvalho wrote:
> > FYI:
> >
> > This is an issue I filed related to adding secp256k1 into Web Crypto API
> > which will be implemented natively in (some) web browsers.
> >
> > If there is any feedback from crypto implementers, please feel free to
> > add comments to this thread:
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=2
> >
> > -- Forwarded message --
> > From: ** mailto:bugzi...@jessica.w3.org>>
> > Date: 13 October 2014 09:18
> > Subject: [Bug 2] Named Curve Registry (adding secp256k1)
> > To: melvincarva...@gmail.com <mailto:melvincarva...@gmail.com>
> >
> >
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=2
> >
> > Myron Davis mailto:myr...@gmail.com>> changed:
> >
> >What|Removed |Added
> >
> 
> >  Status|RESOLVED|REOPENED
> >  CC||myr...@gmail.com
> > <mailto:myr...@gmail.com>
> >  Resolution|NEEDSINFO   |---
> >
> > --- Comment #2 from Myron Davis  > <mailto:myr...@gmail.com>> ---
> > Could this be looked at again?
> >
> > Last response was waiting for feedback from crypto implementors.
> >
> > Currently secp256k1 is supported in the following SSL/TLS libraries now
> > Botan
> > NSS
> > openssl
> > LibreSSL
> > PolarSSL
> > JSSE
> >
> > The three other curves are all all have parameters which do not define
> > how they
> > were generated.  secp256k1 curve has some great advantages in faster
> > signature
> > verification and how the values were determined for the curve.  (i.e. not
> > random).
> >
> > http://www.ietf.org/rfc/rfc4492
> >
> > The curve has had a lot of eyes on it with lots of hardware and software
> > supporting this curve.
> >
> > With discovery of backdoor's in NIST's random number generator
> > (https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I
> > would
> > like to see a determined parameter curve instead of a "random" curve
> option.
> >
> > Thanks
> >
> > --
> > You are receiving this mail because:
> > You reported the bug.
> >
> >
> >
> >
> --
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> > http://p.sf.net/sfu/Zoho
> >
> >
> >
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] death by halving

[Melvin Carvalho]

On 25 October 2014 21:53, Alex Mizrahi  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

[Melvin Carvalho]

On 26 October 2014 00:10, Ross Nicoll  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 alrea

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

[Melvin Carvalho]

On 26 October 2014 08:57, Wladimir  wrote:

> Now that headers-first is merged it would be good to do a 0.10 release
> soon. Not *too* soon as a major code change like that takes some time
> to pan out, but I'd like to propose the following:
>
> - November 18: split off 0.10 branch, translation message and feature
> freeze
> - December 1: release 10.0rc1, start Release Candidate cycle
>
> That leaves three weeks until the freeze. After the release and branch
> split-off, the RC cycle will run until no critical problems are found.
> For major releases this is usually more painful than for stable
> releases, but if we can keep to these dates I'd expect the final
> release no later than January 2015.
>
> Let's aim to have any pending development for 0.10 merged before
> November 18. Major work that I'm aware of is:
>
> - BIP62 (#5134, #5065)
> - Verification library (#5086, #5118, #5119)
> - Gitian descriptors overhaul, so that Gitian depends = Travis depends
> (#4727)
> - Autoprune (#4701)
> - Add "warmup mode" for RPC server (#5007)
> - Add unauthenticated HTTP REST interface (#2844)
>

Thanks for the update.

I was even unaware of of #2844 : 'The beginnings of a block explorer-style
API for bitcoind.'

https://github.com/bitcoin/bitcoin/pull/2844

Seems to me like an important piece of work, Im glad it's finally made the
cut.

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?

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.

Great work!  Looking forward to seeing this go live and how it devlops!


>
> Let me know if there is anything else you think is ready (and not too
> risky) to be in 0.10. You can help along the development process by
> participating in testing and reviewing of the mentioned pull requests,
> or just by testing master and reporting bugs and regressions.
>
> Note: I intended the 0.10 release to be much sooner. The reason that
> this didn't pan out is that I insisted on including headers-first, and
> this took longer than expected. There seems to be a preference to
> switch to a fixed (instead of feature-based) 6-month major release
> schedule, ie
>
> - July 2015: 0.11.0 (or whatever N+1 release is called)
> - January 2016: 0.12.0 (or whatever N+2 release is called)
> - July 2016: 0.13.0 (or whatever N+3 release is called)
>
> Wladimir
>
>
> --
> ___
> 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] Bitcoin Core 0.10 release schedule

[Melvin Carvalho]

On 27 October 2014 08:49, Wladimir  wrote:

> On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho
>  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] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Melvin Carvalho]

On 22 October 2014 23:54, Adam Back  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  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 

Re: [Bitcoin-development] Running a full node

[Melvin Carvalho]

On 8 November 2014 16:28, Daniel F  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] [ANN] METAmarket - Trustless Federated Marketplaces

[Melvin Carvalho]

On 2 May 2015 at 00:57, Marc D. Wood  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] Long-term mining incentives

[Melvin Carvalho]

On 11 May 2015 at 18:28, Thomas Voegtlin  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 A

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

[Melvin Carvalho]

On 18 June 2015 at 12:00, Mike Hearn  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] Payment Protocol Proposal: Invoices/Payments/Receipts

[Melvin Carvalho]

On 3 December 2012 20:35, Mike Koss  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 
> wrote:
>
>> 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  - 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__

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

[Melvin Carvalho]

On 17 December 2012 03:18, Jeff Garzik  wrote:

> On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
>  wrote:
> > On 3 December 2012 20:35, Mike Koss  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

[Melvin Carvalho]

On 17 December 2012 10:19, Mike Hearn  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

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

[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-Intel® 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

[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-Intel® 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 meets the Semantic Web....

[Melvin Carvalho]

On 1 April 2013 11:35, Harald Schilly  wrote:

> On Mon, Apr 1, 2013 at 9:59 AM, Melvin Carvalho
>  wrote:
> > The first step that needs to be done is to create a "vocabulary" for
> > bitcoin.
>
> Hi, have you checked out databases like OKFN and searched for existing
> vocabularies for payments? I don't think it's a great idea to
> re-invent it, if there is already some existing protocol.
>
> random search gave me that:
>
> http://schema.org/PaymentMethod
>
> http://www.heppnetz.de/ontologies/goodrelations/v1#PayPal << adding
> something right here for bitcoin!? (diners club and similar also exist
> there)
>
> payment relationships:
> http://iig2.com/b2bo/ns.html#
>
> more search results:
> http://lov.okfn.org/dataset/lov/search/#s=payment
>


Thanks for the pointers.  I am aware of most of this work, indeed I speak
regularly to many of the authors.

I will reuse as much as possible, but some terms will be bitcoin specific.

I came across:

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

Which is really nice.

Question is where to host it.  I have 3 ideas so far

1. bitcoin.org -- logical, but no https and github doesnt let you set mime
types

2. w3id.org -- new site could be a good permanent location

3. bitcoin.it wiki -- has https but im unsure i can set a mime type, anyone
know who maintains this?


>
> Harald
>
--
Own the Future-Intel® 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

[Melvin Carvalho]

On 1 April 2013 20:28, Petr Praus  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  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-Intel® 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-Intel® 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

[Melvin Carvalho]

On 2 April 2013 00:10, Will  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  wrote:
>
>>
>>
>>
>> On 1 April 2013 20:28, Petr Praus  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  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-Intel® 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-Intel® 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-Intel® 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] A mining pool at 46%

[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

Re: [Bitcoin-development] A mining pool at 46%

[Melvin Carvalho]

On 5 April 2013 11:48, Mike Hearn  wrote:

> 51% isn't a magic number - it's possible to do double spends against
> confirmed transactions before that. If Michael wanted to do so, with the
> current setup he could, and that's obviously rather different to how
> Satoshi envisioned mining working.
>

Thanks for pointing this out.  I guess 51% is mainly of psychological
significance.


>
> However, you're somewhat right in the sense that it's a self-defeating
> attack. If the pool owner went bad, he could pull it off once, but the act
> of doing so would leave a permanent record and many of the people mining on
> his pool would leave. As he doesn't own the actual mining hardware, he then
> wouldn't be able to do it again.
>

Totally see the logic of this, and it makes sense.  But I dont think the
only risk is in terms of double spend, but rather

1) vandalize the block chain which may be difficult to unwind?
2) use an attack to manipulate the price downwards, then rebuy lower

As bitcoin's market cap grows, incentives to move the market will grow


>
> There are also other mining protocols that allow people to pool together,
> without p2pool and without the pool operator being able to centrally pick
> which transactions go into the block. However I'm not sure they're widely
> deployed at the moment. It'd be better if people didn't cluster around big
> mining pools, but I think p2pool still has a lot of problems dealing with
> FPGA/ASIC hardware and it hasn't been growing for a long time.
>

I guess the market will decide which algorithm is used, but as a community
we can perhaps review the different mining protocols and order them in
terms of risk ...


>
>
> On Fri, Apr 5, 2013 at 11:30 AM, Melvin Carvalho  > wrote:
>
>> 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
>>
>>
>
--
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] Web Payments with PaySwarm: Identity (part 1 of 3)

[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] Sending Bitcoins using RSA keys

[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

Re: [Bitcoin-development] BIP21 bitcoin URIs and HTML5

[Melvin Carvalho]

On 24 April 2013 09:42, Mike Hearn  wrote:

> HTML5 allows web apps to register themselves for handling URI schemes,
> such as the bitcoin: URI that is already in use and being extended as part
> of the payment protocol.
>
> The bad news is that for security reasons there is a whitelist of
> acceptable schemes in the spec:
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler
>
> The good news is that yesterday I talked to Hixie about it and he added
> bitcoin to the whitelist:
>
> http://html5.org/tools/web-apps-tracker?from=7849&to=7850
>
> I'm currently finding out what the process is for browser makers to notice
> the change (perhaps they watch the spec commit history and nothing needs to
> be done), but within a few months most users should have browsers that can
> accept bitcoin as a web-app handleable protocol scheme. I suppose IE10
> users may be the laggards, but I guess we can live with that for now.
>

This is great news for bitcon, and the IANA application will be improved if
there is evidence of it being used


>
> Ian pointed out some errors in the BIP21 spec. What's the process for
> amending the BIP? Do we need to create a new one and mark the old one as
> replaced, or can we just fix it in place given the relatively exotic nature
> of most of the issues? Here's his feedback:
>
>
> - BNF doesn't say what it's character set is (presumably it's Unicode)
>
>  - "bitcoinparams" production doesn't define the separator, so in theory
> the syntax is ...?label=foomessage=fooother=foo (rather than
> ...?label=foo&message=foo etc)
>
> - the syntax allows ?amount=FOO&amount=1.1 as far as I can tell, since
> "otherparam" matches any name followed by any value, including "amount"
> followed by a bogus value.
>
> - "pchar" is referenced without definition.
>
> - the "simpler" syntax is just wrong (it would result in
> bitcoin:address?amount=1?label=FOO rather
> than bitcoin:address?amount=1&label=FOO)
>
> BTW the IETF URL specs are being obsoleted by http://url.spec.whatwg.org/,
> at least for Web purposes. In that case matters.
>

Not 100% sure how accurate this is, tho it may be the world view of some
folks in WHATWG.  WHATWG is not a major standards body tho.  Work on
improving the URL spec is always welcome, as it is the value proposition of
the Web.


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

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

[Melvin Carvalho]

On 24 April 2013 16:46, Craig B Agricola  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] WebCryto standard to support secp256r1 but not secp256k1

[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] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

[Melvin Carvalho]

On 14 May 2013 20:41, Peter Todd  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

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

[Melvin Carvalho]

On 15 May 2013 13:38, Peter Todd  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] UUID to identify chains (payment protocol and elsewhere)

[Melvin Carvalho]

On 21 May 2013 01:59, Mark Friedenbach  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)

[Melvin Carvalho]

On 22 May 2013 16:07, Jeff Garzik  wrote:

> On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
>  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] (no subject)

[Melvin Carvalho]

On 25 May 2013 07:46, Zooko Wilcox-OHearn  wrote:

> jgarzik wrote:
>  > 1) Rule changes.  We don't want these.
>
> In general? What constitutes a rule change?
>
> For example, if I understand correctly (from what Gavin said at
> Bitcoin 2013), there is a move afoot to lift the block size limit.
> Although, when I went to confirm my understanding by reading the
> bitcoin-development list archives, I don't see mention of this. Is
> there another forum I should be reading if I want to follow Bitcoin
> development?
>
> Anyway, I hope that there are some rule changes that you would
> consider for Bitcoin, although I recognize there are vast classes of
> such changes that you wouldn't.
>
> I'm trying to figure out what's the most productive way to show you,
> and everyone, candidates for such changes. Things that are definitely
> not suitable for merging to trunk tomorrow, but might be suitable in a
> year or two, or "Next Time We Have A Hardfork".
>
> I don't think alternative bitcoin-clones are the best venue for those.
> Although they are certainly good venues for changes which can never
> make it into Bitcoin.
>
> Perhaps the best venue for such a thing is just to fork bitcoin.git on
> github.
>

It might be an idea to have 'rule change' fixes and 'bug fix' releases go
out separately


>
> Regards,
>
> Zooko Wilcox-O'Hearn
>
> Founder, CEO, and Customer Support Rep
>
> https://LeastAuthority.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
>
--
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] (no subject)

[Melvin Carvalho]

On 25 May 2013 10:53, Luke-Jr  wrote:

> On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
> > It might be an idea to have 'rule change' fixes and 'bug fix' releases go
> > out separately
>
> Bitcoin is a consensus system. You can't run clients with different rules
> on
> the same blockchain/network - it just won't work! Maybe we're now talking
> about mere client default policies? In which case, you should be able to
> configure previous behaviour...
>

[[ Not wishing to stray too far off topic ]]

I think you are perhaps underestimating the effect of 'mere' default
policies.

It would be nice to think that every node was a free thinking individual
that is motivated to vote with their feet, but in practice most people dont
have time.

There is research showing that 80% of users tend to accept defaults.

Rule changes and changing defaults would seem to be things worth weighing.
Bug fixes hopefully should be fairly unanimous.  Of course a grey area
exists in between.


>
> If you want just bug fixes and rule changes, without policy default
> changes,
> new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised
> these are short-term solutions and won't be maintained forever - so you
> really
> should try to get the behaviour you want from the current release. If you
> can't for some reason, please do report a bug explaining what it is the
> older
> version was capable of that the new one isn't!
>
> Luke
>
--
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] WebCryto standard to support secp256r1 but not secp256k1

[Melvin Carvalho]

On 7 May 2013 12:18, Melvin Carvalho  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] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

[Melvin Carvalho]

On 1 June 2013 21:30, Peter Todd  wrote:

> Currently the most compact way (proof-size) to sacrifice Bitcoins that
> does not involve making them unspendable is to create a anyone-can-spend
> output as the last txout in the coinbase of a block:
>
> scriptPubKey:  OP_TRUE
>
> The proof is then the SHA256 midstate, the txout, and the merkle path to
> the block header. However this mechanism needs miner support, and it is
> not possible to pay for such a sacrifice securely, or create an
> assurance contract to create one.
>

Sorry if this is a stupid question, but why would someone want to sacrifice
their bitcoins?


>
> A anyone-can-spend in a regular txout is another option, but there is no
> way to prevent a miner from including a transaction spending that txout
> in the same block. Once that happens, there is no way to prove the miner
> didn't create both, thus invalidating the sacrifice. The announce-commit
> protocol solves that problem, but at the cost of a much larger proof,
> especially if multiple parties want to get together to pay the cost of
> the sacrifice. (the proof must include the entire tx used to make the
> sacrifice)
>
> However if we add a rule where txouts ending in OP_TRUE are unspendable
> for 100 blocks, similar to coinbases, we fix these problems. The rule
> can be done as a soft-fork with 95% support in the same way the
> blockheight rule was implemented. Along with that change
> anyone-can-spend outputs should be make IsStandard() so they will be
> relayed.
>
> 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.
>
> We should always make it easy for people to write code that does what is
> best for Bitcoin.
>
> --
> 'peter'[:-1]@petertodd.org
> 00ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293
>
>
> --
> 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://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> 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

[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 
Date: 5 June 2013 18:50
Subject: Creating a Currency for the (Read / Write) Web
To: public-rww , Nathan Rixham , Web
Payments 


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?

[Melvin Carvalho]

On 6 June 2013 02:19, Peter Vessenes  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

[Bitcoin-development] address collision and undependability

[Melvin Carvalho]

There was a discussion on #bitcon-dev yesterday

I stated that it would be impractical to generate two bitcoin addresses,
such that they differed in exactly one character (modulo different
checksums).

The corollary to this is that if you find an address with a verifiable
signature.  Changing one character of that address would have no known
private key, and hence be normally undependable.

Does that sound correct?
--
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

[Melvin Carvalho]

On 6 June 2013 21:59, Andreas M. Antonopoulos wrote:

> 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  wrote:
>
>> On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
>> > scriptPubKey:  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

[Melvin Carvalho]

On 6 June 2013 23:48, Luke-Jr  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
>
>
> 

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

[Melvin Carvalho]

On 6 June 2013 02:19, Peter Vessenes  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

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

[Melvin Carvalho]

On 10 June 2013 06:09, John Dillon  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

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

[Melvin Carvalho]

On 10 June 2013 10:26, John Dillon  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho
>  wrote:
> > -1
> >
> > Firstly I appreciate the ingenious thought that went into this post.
> >
> > However, Bitcoin's fundamental philosophy was one CPU one vote.
>
> Indeed it was. Which is why as GPU's came onto the scene Satoshi was
> strongly
> against them. I have to wonder what he thinks of ASICs where just a
> handful of
> companies control the supply of Bitcoin hashing power.
>

Thanks for your reply.  Do you have a pointer to Satoshi being strongly
against GPU?  I'd be interested to see that.  FWIW, I've read all his forum
posts a few times, I just dont recall this one, tho I'm sure it's there...


>
> Satoshi also never forsaw pools, which are why just 2 or 3 people control
> the
> majority of Bitcoin hashing power.
>
> > The asymmetry lies in psychological terms, in that new defaults tend to
> be
> > adopted 80% of the time, so core devs have disproportionate amount of
> power
> > as things stand.
>
> That's why I'm very clear that doing nothing is a vote for the status quo.
> Of
> course wallet authors can do what they want to try to get users to vote
> according to their wishes, or for that matter simply steal your vote, but
> we
> already must put a lot of faith into wallets to not steal our funds.
>
> > Unless there's a very good reason not to, e.g. miners are clearly abusing
> > the system, we should stick with 1 CPU one vote.
>
> People are proposing we put control of the blocksize entirely into the
> hands of
> miners, yet we all have an interest in auditing the blocks miners produce.
> There must be balance.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3
> JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC
> oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7
> RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i
> p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+
> N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA=
> =c8iU
> -END PGP SIGNATURE-
>
--
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: Vote on the blocksize limit with proof-of-stake voting

[Melvin Carvalho]

On 10 June 2013 10:35, Pieter Wuille  wrote:

> On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho
>  wrote:
> > However, Bitcoin's fundamental philosophy was one CPU one vote.
>
> This is perhaps the largest misconception that keeps being repeated.
> Bitcoin is not a democracy; it is a zero-trust system. The rules are
> set in stone, and every full node verifies all rules and must
> independently come to the same result as everyone else. Obviously, if
> everyone changes their software, anything can change, but from within
> the system there is no way to change which blocks are considered
> valid, and there is certainly no voting mechanism about that.
>
> What is voted about, is the one single thing that cannot be decided by
> each node individually: namely the order of otherwise valid and
> non-conflicting transactions, and that's just because it's a
> necessity. Because deciding the order includes delaying transaction
> potentially indefinitely, a majority of miners can indeed choose the
> enforce an additional rule about which transactions are considered
> valid, but the rules implemented in full nodes do not change without
> changing the software. For example, miners cannot decide to raise the
> block subsidy, even if every single miner out there would want that.
> They'd just end up being ignored by everyone else.
>
> > Voting is easily gamed.  While this may work in one particular case, it
> is
> > perhaps a bad precedent to set.  Establishing methods of voting can lead
> to
> > single points of failure.
>
> The problem is that at some point, you have to look at the system from
> a higher level than just the technical part. And because ultimately
> the possibility exists where everyone changes their software, and
> there is an exceedingly high incentive for consensus (a deliberate
> hard-fork where two groups of users decide to use different and
> incompatible rules, aware of eachother, is suicide for the system, in
> my opinion). This results in the fact that proposed changes can indeed
> become new adopted hard rules in the system, and I don't think there's
> anything that can be done about it. Bitcoin is a consensus system - at
> the technical level - but also a consensus of the people using it, and
> ultimately they decide the rules.
>

OK I accept that the timestamping is one CPU one vote.  However rule
changes seem rather arbitrary.

Towit if you use a voting/consensus system and want to destroy bitcion it
seems quite easy.

Iterate on picking a rule chance that will divide the consensus in such a
way as to create ensuing chaos.

I think voting is too easy gamed for it it to be meaningful other than a
straw poll.

If there's a bug, and everyone is unanimous that it's a bug, it can be
fixed.

If there's a controversial rule change, we should be extremely cautious and
not do it unless there's a very good reason.  Keeping to satoshi's model as
much as possible without introducing human factors, unnecessarily.


>
>
> > Unless there's a very good reason not to, e.g. miners are clearly abusing
> > the system, we should stick with 1 CPU one vote.
>
> So you're saying that instead of a zero-trust system, we should move
> to a system where miners can decide _everything_ - as opposed to just
> being in charge of ordering transactions? I don't think you understand
> the system at all, if that is what you're proposing.
>
> --
> Pieter
>
--
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] Decentralizing mining

[Melvin Carvalho]

On 10 June 2013 23:09, Peter Todd  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

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

[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

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

[Melvin Carvalho]

FYI: some musings on how crypto currencies might be combined with social
good ...

-- Forwarded message --
From: Melvin Carvalho 
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

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

[Melvin Carvalho]

On 11 June 2013 17:29, Luke-Jr  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.
>
> > 
> > 
> > 
>
> 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?

[Melvin Carvalho]

On 19 May 2013 15:23, Adam Back  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

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

[Melvin Carvalho]

On 18 June 2013 05:48, Alan Reiner  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

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

[Melvin Carvalho]

On 11 June 2013 17:29, Luke-Jr  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.
>
> > 
> > 
> > 
>
> 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

[Melvin Carvalho]

On 10 June 2013 06:09, John Dillon  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

Re: [Bitcoin-development] [RFC] Standard for private keys with birth timestamp

[Melvin Carvalho]

On 22 July 2013 16:44, Pieter Wuille  wrote:

> Hello,
>
> I should have brought up this suggestion before, as there seems to be
> relevant other work.
>
> I'd like to propose encoding keys data (whatever type) with a birth
> timestamp as:
>  * @
>
> The reason for not incorporating this inside the key serialization (for
> example BIP32), is because
> birth timestamps are more generally a property of an address, rather than
> the key it is derived from.
> For one, it is useful for non-extended standard serialized private keys,
> but for P2SH addresses,
> the "private key" is really the actual scriptPubKey, but birth data is
> equally useful for this.
>
> Reason for choosing the '@' character: it's not present in the base58,
> hex, or base64 encodings that
> are typically used for key/script data.
>
> One downside is that this means no checksum-protection for the timestamp,
> but the advantage is
> increased genericity. It's also longer than using a binary encoding, but
> this is an optional
> part anyway, and I think "human typing" is already fairly hard anyway.
>

Is there a BIP for this?

@ is normally used in conjunction with things other than a time stamp ...

You may want to look at RFC 4151

http://www.ietf.org/rfc/rfc4151.txt

They had an idea on adding time stamps to identifiers.

First impression is that the sacrifice in opacity does not seem to justify
the utility.


>
> --
> Pieter
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Melvin Carvalho]

On 31 July 2013 13:33, Gavin Andresen  wrote:

> On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami  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:
>   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=49501711&iu=/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=49501711&iu=/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

[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=49501711&iu=/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

[Melvin Carvalho]

On 9 August 2013 13:43, 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.
>

Persona, in it's current state, is the exact opposite of the principle
behind of bitcoin.

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.

A (client or server side) X.509 cert can be issued to any address, be it
email, telephone, webpage, *or* to a bitcoin address, it allows any URI in
he subjectAlternativeName field.  This is much more of bitcoin like model
where the private key sits on your client and the public key is in
discoverable by the other end.

Most enterprises (including Mozilla) take the stance that key management on
the client is beyond the average user.  The notable exception is twitter
who are rolling out 2 factor auth based on PKI.

If you're interested in signing stuff with RSA (or other) keys, the web
payments and payswarm guys have done a ton of work on this, including
implementations, which you may be able to reuse ...


>
>
>
>
> --
> 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=48897031&iu=/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=48897031&iu=/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

[Melvin Carvalho]

On 9 August 2013 14:08, Mike Hearn  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
), 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=48897031&iu=/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

[Melvin Carvalho]

On 9 August 2013 13:59, Wendell  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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.9 goals

[Melvin Carvalho]

On 15 August 2013 02:29, Gavin Andresen  wrote:

> It feels to me like we're close to a 0.9 "feature freeze" / start of
> release cycle; I'd like to talk a little bit about what we'd like to see in
> the final 0.9 release.
>
> My list:
>
> Bug:  I'd really like to see the leveldb corruption issue (mostly on OSX,
> it seems) fixed. This is hard because it can't be reliably reproduced, and,
> at least on my machine, takes weeks to occur. Help needed to reproduce/fix,
> see https://github.com/bitcoin/bitcoin/issues/2770 for what we know about
> the problem.
>
> Payment Protocol support is ready to be pulled (
> https://github.com/bitcoin/bitcoin/pull/2539) . Unless there are major
> objections, I will pull it tomorrow (it has already gone through two rounds
> of bounty-driven QA testing, so I'm convinced it is ready).
>
> I'd love for 0.9 to contain sipa's "headers first" initial block download
> optimization; I think it is a big enough improvement to justify making the
> 0.9 test/release cycle longer.
>
> Coin control (https://github.com/bitcoin/bitcoin/pull/2343).
>
> The autotools work (https://github.com/bitcoin/bitcoin/pull/2805).
>
> Gitian-build with the latest openssl and Qt5. Perhaps update the version
> of Debian VMs that we gitian-build with.
>
> I plan on spending about half my time on code review and helping get pull
> requests tested, and the other half of my time working on code that
> probably won't make it into the 0.9 release.
>

+1

Sounds great!


>
> --
> --
> 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=48897031&iu=/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=48897031&iu=/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...

[Melvin Carvalho]

On 16 August 2013 03:00, Gavin Andresen  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*
>
>

+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=48897031&iu=/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=48897031&iu=/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

[Melvin Carvalho]

On 25 September 2013 13:15, Mike Hearn  wrote:

> It won't fit. But I don't see the logic. A URI contains instructions for
> making a payment. If that instruction is "pay to this address" or "download
> this file and do what you find there", it's no different unless there's
> potential for a MITM attack. If the request URL is HTTPS or a secured
> Bluetooth connection then there's no such possibility.
>

It depends on the attacker.  I think a large entity such as a govt or big
to medium size corporation *may* be able to MITM https, of course the
incentive to do so is probably not there ...


>
>
>
>
> On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach <
> andr...@schildbach.de> wrote:
>
>> While it's good to save space, I'm at the moment not convinced that
>> taking a de-route via an URL is a good idea to begin with.
>>
>> The main problem is trust. If you scan a QR code from a foreign phone,
>> you trust that that phone is owned by the one you want to send money to.
>> By adding the HTTP request that trust is voided.
>>
>> As soon as there is a BIP70 implementation, I will begin playing with
>> putting the payment request directly into the QR code.
>>
>>
>> On 09/25/2013 11:27 AM, Mike Hearn wrote:
>> > We could also say that if protocol part (https://) is missing, it's
>> > implied automatically. So just:
>> >
>> > bitcoin:1abc?r=bob.com/r/aZgR 
>> >
>> > I think that's about as small as possible without re-using the pubkey as
>> > a token in the url.
>> >
>> >
>> > On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <
>> gavinandre...@gmail.com
>> > > wrote:
>> >
>> > On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn > > > wrote:
>> >
>> > BTW, on the "make qrcodes more scannable" front -- is it too
>> > late to change BIP 72 so the new param is just "r" instead of
>> > "request"? Every byte helps when it comes to qrcodes ...
>> >
>> >
>> > Not too late, assuming there are no objections. Smaller QR codes is
>> > a very good reason to change it.
>> >
>> > --
>> > --
>> > 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=60133471&iu=/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=60133471&iu=/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=60133471&iu=/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=60133471&iu=/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?

[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=60133471&iu=/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?

[Melvin Carvalho]

On 29 September 2013 10:32, Gavin Andresen  wrote:

> On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham  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=60133471&iu=/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=60133471&iu=/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?

[Melvin Carvalho]

On 29 September 2013 04:28, Neil Fincham  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,  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=60133471&iu=/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=60133471&iu=/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=60133471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Melvin Carvalho]

On 1 April 2013 09:59, Melvin Carvalho  wrote:

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

Hi All

Sorry for the delay on this.  I've made a very simple start, and am hosting
the vocabulary at.

https://w3id.org/cc

Having chatted on IRC, I'm not only going to model bitcion, but all crypto
currencies in time, starting first with bitcoin.  There's only one use case
currently support, which is a way to tell the semantic web that a link is a
bitcoin address (I know you can already introspect on the bitcoin: link but
introspection requires out of band knowledge).  More explanation below:

*Use Case
*

As a publisher Alice would like to link her web page content (or app) to a
bitcoin address, so that donations can be received by those that have
enjoyed her work.

*Model
*
It's only a slight overhead to model all crypto currencies so perhaps the
model will be something like

URI -> crypto-currency-address -> bitcoin-address

*Implementation
*
The folks at w3id.org have kindly offered to user their permanent
identifier switchboard, then we redirect to a locked down vocabulary.

As an implementer you simply need to add a single rel= tag to your markup.

*Example Usage*

In a web page:

<*meta* rel="https://w3id.org/cc#bitcoin<https://w3id.org/cc#bitcoin-address>"
href="bitcoin:1234" />

In an html5 app:

https://w3id.org/cc#bitcoin <https://w3id.org/cc#bitcoin-address>"
href="bitcoin:1234">

*Note: you an provide context for an individual concept in HTML5 (as
opposed to the webpage itself), such as an app, a project, a person, but
using the @about tag.
*

For litecoins (coming soon)

https://w3id.org/cc#litecoin <https://w3id.org/cc#litecoin-address>"
href="">


*Next Steps

*
It's just a small step to start with, can allow all sorts of entities to
start accepting bitcoin in a way that complies with the W3C best
practices.  I'll be improving and extending this over time, feedback or
help is welcome!
--
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=60134071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A critique of bitcoin open source community

[Melvin Carvalho]

On 19 October 2013 18:38, Mitar  wrote:

> Hi!
>
> Interesting read:
>
>
> http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html
>

Im sympathetic to some of the points, but it seems slightly harsh.  I do
agree that we're lucky to have the excellent leadership of Gavin, who I
think is a great role model.

Perhaps the bitcoin community is at a size where it may benefit from a
loose code of conduct.  The ubuntu code of conduct has been excellent in
this respect, in helping to grow that community:

http://www.ubuntu.com/about/about-ubuntu/conduct

[[

Ubuntu Code of Conduct v2.0
Community

Ubuntu is about showing humanity to one another: the word itself captures
the spirit of being human.

We want a productive, happy and agile community that can welcome new ideas
in a complex field, improve every process every year, and foster
collaboration between groups with very different needs, interests and
skills.

We gain strength from diversity, and actively seek participation from those
who enhance it. This code of conduct exists to ensure that diverse groups
collaborate to mutual advantage and enjoyment. We will challenge prejudice
that could jeopardise the participation of any person in the project.

The Code of Conduct governs how we behave in public or in private whenever
the project will be judged by our actions. We expect it to be honored by
everyone who represents the project officially or informally, claims
affiliation with the project, or participates directly.
We strive to:

Be considerate

Our work will be used by other people, and we in turn will depend on the
work of others. Any decision we take will affect users and colleagues, and
we should consider them when making decisions.

Be respectful

Disagreement is no excuse for poor manners. We work together to resolve
conflict, assume good intentions and do our best to act in an empathic
fashion. We don't allow frustration to turn into a personal attack. A
community where people feel uncomfortable or threatened is not a productive
one.

Take responsibility for our words and our actions

We can all make mistakes; when we do, we take responsibility for them. If
someone has been harmed or offended, we listen carefully and respectfully,
and work to right the wrong.

Be collaborative

What we produce is a complex whole made of many parts, it is the sum of
many dreams. Collaboration between teams that each have their own goal and
vision is essential; for the whole to be more than the sum of its parts,
each part must make an effort to understand the whole.

Collaboration reduces redundancy and improves the quality of our work.
Internally and externally, we celebrate good collaboration. Wherever
possible, we work closely with upstream projects and others in the free
software community to coordinate our efforts. We prefer to work
transparently and involve interested parties as early as possible.

Value decisiveness, clarity and consensus

Disagreements, social and technical, are normal, but we do not allow them
to persist and fester leaving others uncertain of the agreed direction.

We expect participants in the project to resolve disagreements
constructively. When they cannot, we escalate the matter to structures with
designated leaders to arbitrate and provide clarity and direction.

Ask for help when unsure

Nobody is expected to be perfect in this community. Asking questions early
avoids many problems later, so questions are encouraged, though they may be
directed to the appropriate forum. Those who are asked should be responsive
and helpful.

Step down considerately

When somebody leaves or disengages from the project, we ask that they do so
in a way that minimises disruption to the project. They should tell people
they are leaving and take the proper steps to ensure that others can pick
up where they left off.
Leadership, authority and responsibility

We all lead by example, in debate and in action. We encourage new
participants to feel empowered to lead, to take action, and to experiment
when they feel innovation could improve the project. Leadership can be
exercised by anyone simply by taking action, there is no need to wait for
recognition when the opportunity to lead presents itself.
Delegation from the top

Responsibility for the project starts with the "benevolent dictator", who
delegates specific responsibilities and the corresponding authority to a
series of teams, councils and individuals, starting with the Community
Council ("CC"). That Council or its delegated representative will arbitrate
in any dispute.

We are a meritocracy; we delegate decision making, governance and
leadership from senior bodies to the most able and engaged candidates.
Support for delegation is measured

Nominations to the boards and councils are at the discretion of the
Community Council, however the Community Council will seek the input of the
community before confirming appointments.

Leadership is not an award, right, or title; it is a privilege,

Re: [Bitcoin-development] A critique of bitcoin open source community

[Melvin Carvalho]

On 21 October 2013 09:03, Martin Sustrik  wrote:

> On 21/10/13 08:52, Jean-Paul Kogelman wrote:
> > How about putting them into sub directories that map onto the status of
> the BIP?
> >
> > Reading BIP 1, that would make:
> >
> > Accepted
> > Active
> > Draft
> > Deferred
> > Final
> > Rejected
> > Replaced
> > Withdrawn
>
> Have it been considered to do this via IETF? The process there is
> hardened by 40 years of experience and 7000+ RFCs. Probably better than
> anything you can devise yourself.
>

IETF is great for some things.  I think the bitcoin URI scheme is being
registered with them.

However the process can take many years to get to an RFC, for something
relatively simple, not to mention there can be costs too

Given that crypto currencies are a relatively new field, I am unsure the
IETF has a wealth of expertise in this area, compared with the core devs

Maybe IETF is better to standardize some of the communications or
serialization components, but not so much the BIPs.  Or perhaps some of the
BIPs can be written up as "Informational" rather than "Proposed Standard"
in the RFC format, and reviewed

I've followed quite a few FLOSS projects over the years.  Overall, I've
been amazingly impressed with the BIP process (dont forget it's used in
other systems too -- python?).  It seems an agile process, that strikes an
great balance between needed features, and documentation.  I think that's
exactly what will continue bitcoin's momentum in the short to medium term.


>
> Martin
>
>
> --
> 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=60135031&iu=/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=60135031&iu=/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

[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=60135991&iu=/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

[Melvin Carvalho]

On 2 November 2013 14:02, Mike Hearn  wrote:

> On Sat, Nov 2, 2013 at 6:01 AM,  wrote:
>
>> 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://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
>

I actually use client certificates for almost all of my authentication.

It's true that the browser manufacturers have created an UX which is not
ideal, and very little effort is made to improve it.  But it is possible.
See this project from Mozilla labs.

http://www.azarask.in/blog/post/identity-in-the-browser-firefox/

Unfortunately this got killed :(

More popular is the trusted third party model like OAuth or Persona.
There's a conflict of interest as well, because browser manufacturers are
often identity providers too, so there is an incentive to push TTP
technology.

There's two elements here.  One is paswordless login (which I love).  The
other is who controls your identity.  I like to control my own identity (in
my browser) using PKI.  But facebook and the big webmail providers have a
lions share of the market.

The way to shift the balance is to offer the right incentives.


>
>
> --
> 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=65839951&iu=/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=65839951&iu=/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

[Melvin Carvalho]

On 2 November 2013 17:26, Mike Hearn  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 wrote:
>
>> 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=65839951&iu=/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=65839951&iu=/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

[Melvin Carvalho]

On 2 November 2013 22:57, slush  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 copy&paste 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,  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=65839951&iu=/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=65839951&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sour

Re: [Bitcoin-development] Message Signing based authentication

[Melvin Carvalho]

On 2 November 2013 22:14, Johnathan Corgan  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=65839951&iu=/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=60136231&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] we can all relax now

[Melvin Carvalho]

On 6 November 2013 06:33, kjj  wrote:

> One of the things that really gets me going is when someone devises a
> model, tests it against itself, and then pretends that they've learned
> something about the real world.
>
> Naturally, the Selfish Mining paper is exactly this sort of nonsense.
> Their model is one with no latency, and one where the attacker has total
> visibility across the network.  An iterated FSM is not a suitable
> simulation of the bitcoin system.  The bitcoin network does not have
> states, and to the extent that you can pretend that we do, you can't
> simulate transitions between them with static probabilities.
>
> The authors understand this deep down inside, even though they didn't
> work out the implications.  They handwave the issue by assuming a total
> sybil attack, and in true academic spirit, they don't realize that the
> condition necessary for the attack is far, far worse than the attack
> itself.
>
> Greg said he'd like to run some simulations, and I'm thinking about it
> too.  Unfortunately, he is busy all week, and I'm lazy (and also busy
> for most of tomorrow).
>
> If neither of us get to it first, I'm willing to pitch in 1 BTC as a
> bounty for building a general bitcoin network simulator framework. The
> simulator should be able to account for latency between nodes, and
> ideally within a node.  It needs to be able to simulate an attacker that
> owns varying fractions of the network, and make decisions based only on
> what the attacker actually knows.  It needs to be able to simulate this
> "attack" and should be generic enough to be easily modified for other
> crazy schemes.
>
> (Bounty offer is serious, but expires in one year [based on the earliest
> timestamp that my mail server puts on this email], and /may/ be subject
> to change if the price on any reputable exchange breaks 1000 USD per BTC
> in that period.)
>
> Basically, the lack of a decent network simulator is what allowed this
> paper to get press.  If the author had been able to see the importance
> of the stuff he was ignoring, we wouldn't be wasting so much time
> correcting him (and sadly the reporters that have no way to check his
> claims).
>
> https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663
>

Thanks for posting this bounty.  I'm interested in working on it, and will
give it a try.  I also have some other commitments, so I suspect you guys
will finish it first tho... but if not, I'll post details of the simulator.


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

[Bitcoin-development] moving the default display to mbtc

[Melvin Carvalho]

Rationale
===

Given the recent rise in value there seems to be anecdotal evidence that 1
bitcoin being so high is putting off a lot of normal buyers, because they
feel that putting down $400+ and only getting "1 coin", or having to buy in
multiples of 1 whole coin, is too much.. only after it being explained that
they can buy fractional amounts to they regain interest, apparently
happening increasingly.


Straw Poll


6 months ago there was a straw poll on this

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

Roughly 2/3 of respondents favoured switching

A further 20% said to switch after it hits 1000

Satoshi's comments:


Eventually at most only 21 million coins for 6.8 billion people in the
world if it really gets huge.

But don't worry, there are another 6 decimal places that aren't shown, for
a total of 8 decimal places internally.  It shows 1.00 but internally it's
1..  If there's massive deflation in the future, the software could
show more decimal places.

If it gets tiresome working with small numbers, we could change where the
display shows the decimal point.  Same amount of money, just different
convention for where the ","'s and "."'s go.  e.g. moving the decimal place
3 places would mean if you had 1.0 before, now it shows it as 1,000.00.

https://bitcointalk.org/index.php?topic=44.msg267#msg267


Would now be a good time to start thinking about changing the default
display in the software.  Perhaps initially it could be a dropdown display
option, then at some point mbtc becomes the default?
--
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=63469471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Melvin Carvalho]

On 15 November 2013 01:37, Daniel F  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=63469471&iu=/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=63469471&iu=/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?

[Melvin Carvalho]

On 14 October 2013 20:08, Adam Back  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 intentio

Re: [Bitcoin-development] Message Signing based authentication

[Melvin Carvalho]

On 6 November 2013 07:41, slush  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=111408631&iu=/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)

[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=84349831&iu=/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

[Melvin Carvalho]

On 27 December 2013 19:08, Mike Belshe  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/

Testnet does not currently fully function with for creating transactions:

http://test.webbtc.com/

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

Re: [Bitcoin-development] Happy new year!

[Melvin Carvalho]

On 1 January 2014 19:33, Mike Hearn  wrote:

> Bitcoin had an incredible year in 2013, and I very much enjoyed working
> with and meeting you all.
>
> I'm very much looking forward to some of the upgrades coming in 2014.
> Though a lot happened in the general community, last year was kind of quiet
> with respect to the core software. I'm hoping this year we can pick up the
> pace a little.
>

Happy new year!  Thanks for your awesome contribution and to all those that
contributed to development.

"Bitcoin" was one of the 100 most searched for terms in 2013, really
looking forward to 2014!


>
> Cheers!
>
>
> --
> 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=84349831&iu=/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=84349831&iu=/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

[Melvin Carvalho]

On 3 January 2014 06:22, Troy Benjegerdes  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=84349831&iu=/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=84349831&iu=/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

[Melvin Carvalho]

On 27 December 2013 19:05, Mike Hearn  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=84349831&iu=/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=124407151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Melvin Carvalho]

On 13 March 2014 16:50, Mike Hearn  wrote:

> On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik  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] Bitcoin for W3C Payments Workshop, March 24-25

[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. Do

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

[Melvin Carvalho]

On 16 April 2014 10:14, Wladimir  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] Proposal for extra nonce in block header

[Melvin Carvalho]

On 27 April 2014 09:07, Timo Hanke  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-developme

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

[Melvin Carvalho]

On 14 November 2013 12:45, Melvin Carvalho  wrote:

> Rationale
> ===
>
> Given the recent rise in value there seems to be anecdotal evidence that 1
> bitcoin being so high is putting off a lot of normal buyers, because they
> feel that putting down $400+ and only getting "1 coin", or having to buy in
> multiples of 1 whole coin, is too much.. only after it being explained that
> they can buy fractional amounts to they regain interest, apparently
> happening increasingly.
>
>
> Straw Poll
> 
>
> 6 months ago there was a straw poll on this
>
> https://bitcointalk.org/index.php?topic=220322.0
>
> Roughly 2/3 of respondents favoured switching
>
> A further 20% said to switch after it hits 1000
>
> Satoshi's comments:
> 
>
> Eventually at most only 21 million coins for 6.8 billion people in the
> world if it really gets huge.
>
> But don't worry, there are another 6 decimal places that aren't shown, for
> a total of 8 decimal places internally.  It shows 1.00 but internally it's
> 1..  If there's massive deflation in the future, the software could
> show more decimal places.
>
> If it gets tiresome working with small numbers, we could change where the
> display shows the decimal point.  Same amount of money, just different
> convention for where the ","'s and "."'s go.  e.g. moving the decimal place
> 3 places would mean if you had 1.0 before, now it shows it as 1,000.00.
>
> https://bitcointalk.org/index.php?topic=44.msg267#msg267
>
>
> Would now be a good time to start thinking about changing the default
> display in the software.  Perhaps initially it could be a dropdown display
> option, then at some point mbtc becomes the default?
>
>
Just a FYI on this topic.  In Gavin's recent interview he described the
block reward as 25,000 millibits (about 25 minutes in).

https://www.youtube.com/watch?v=4pBd-OD9Rns

Decide for yourself whether or not that's meaningful :)

PS very enjoyable and accessible panel ...
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development