Kalle Rosenbaum | 24 May 22:45 2015
Picon

Proof of Payment BIP-able?

Hi all!

As indicated in my first email regarding Proof of Payment (Mars 13, subject "Proof of Payment"), I would like to BIP it. I have two proposals:

* PoP datastructure and process: https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment
* btcpop: URI scheme: https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme

Basically, my question to the community is: Do you agree that these are BIP-able?

The proposals are not yet BIP formatted, but pretty complete. An implementation is avaliable at https://github.com/kallerosenbaum/poppoc. Specifically, the PoP validating code is in PopValidator.java.

As far as I can tell from the previous thread, no major objection against the idea was raised. PoP, if standardized, would bring a lot of utility to bitcoin: Paysite login, concert tickets, left luggage lockers, lotteries, video rental, etc.

Further on, I'd like to extend BIP70 to support PoP, but that will have to wait until we have consensus around the two basic proposals above.

I have received some great feedback from the community and included most of it in the updated version of the specification. The essential changes are:

* If a PoP for some reason appears in the bitcoin p2p network, we must make sure that IF it is included in a block it should have minimal impact. The solution I chose was to include all outputs of the original paymet in the PoP. That way, if the PoP is included it will not alter the payees. (Thanks to Tom Harding for pointing out the problem and Magnus Andersson for the initial solution).

* The check if the transaction is actually a tx that you want proof for is moved to later in the validation process. Otherwise, one could get information on what transactions pays for which services by simply sending erroneously signed PoPs with a transaction id we're interested in.

* A version field of 2 bytes is included. Currently the only valid version is 0x00 0x01. (Thanks Martin Lie)

* The "PoP" literal is removed. It provides little value as the receiver of a PoP expects a PoP. (Again, thanks Martin Lie for making me think about this.)

Regards,
Kalle Rosenbaum
------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Wladimir J. van der Laan | 24 May 09:47 2015
Picon

Bitcoin Core 0.9.5 released

Bitcoin Core version 0.9.5 is now available from:

  https://bitcoin.org/bin/0.9.5/

This is a new minor version release, with the goal of backporting BIP66. There
are also a few 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

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

Notable changes
================

Mining and relay policy enhancements
------------------------------------

Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its `getblocktemplate` must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.

0.9.5 changelog
================

- `74f29c2` Check pindexBestForkBase for null
- `9cd1dd9` Fix priority calculation in CreateTransaction
- `6b4163b` Sanitize command strings before logging them.
- `3230b32` Raise version of created blocks, and enforce DERSIG in mempool
- `989d499` Backport of some of BIP66's tests
- `ab03660` Implement BIP 66 validation rules and switchover logic
- `8438074` build: fix dynamic boost check when --with-boost= is used

Credits
--------

Thanks to who contributed to this release, at least:

- 21E14
- Alex Morcos
- Cory Fields
- Gregory Maxwell
- Pieter Wuille
- Wladimir J. van der Laan

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

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Emin Gün Sirer | 20 May 12:25 2015
Picon

Virtual Notary.

Hi everyone,

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

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

  * proof of Bitcoin address ownership

  * proof of Tweet

  * proof of real estate value

  * proof of DNS ownership

  * proof of existence

  * proof of web page contents

  * proof of weather conditions

The factoids can be recorded on the blockchain (if you pay for the transaction with Bitcoin or PayPal), or they can be part of a free attestation chain that we maintain. The website provides a permanent URL to the factoids it generates; it also provides an X.509 certificate that you can download and keep safe in perpetuity, independent of the website.

The link to the website is here:

The link to the writeup describing the various factoids and their use cases is here:

We are actively looking for people who are interested in developing the service further. Specifically, if you have suggestions for how to extend the service, for new proof/factoid types, or for how to build a business case around the core idea, please let us know.

Best,
- egs

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Andrew | 20 May 04:55 2015
Picon

Scaling Bitcoin with Subchains

Hi

I briefly mentioned something about this on the bitcoin-dev IRC room. In general, it seems experts (like sipa i.e. Pieter) are against using sidechains as a way of scaling. As I only have a high level understanding of the Bitcoin protocol, I cannot be sure if what I want to do is actually defined as a side chain, but let me just propose it, and please let me know whether it can work, and if not why not (I'm not scared of digging into more technical resources in order to fully understand). I do have a good academic/practical background for Bitcoin, and I'm ready to contribute code if needed (one of my contributions includes a paper wallet creator written in C).

The main problem I see with increasing the block size limit is that it increases the amount of storage required to fully validate all transactions for say 100 years (a person's life). With 1 MB blocks, you can store all lifetime transactions on a 5 TB drive, which basically any regular user can do. With 10 MB blocks, you need a 50 TB drive, not accessible for regular users. Yes, it's possible that in the future hard drive technology will get cheaper and smaller, but this still didn't happen, so we can't just say "it should be doable at the rate of Moore's law etc...", we need to know that it is accessible for everyone, now. Also, don't forget that human life expectancy can increase with time as well. I know, it sounds silly to use a human lifetime as a measurement of how far back each user should be able to store transactions for, but what is a better measurement? This is a technology made for people i.e. humans, right, and the important part is that it is for regular people and not just well privileged people. You can search my last four emails for some more calculations.

What sipa told me on the IRC channel is that Bitcoin Core does not care about old transactions. It only looks at the current blocks. Yes, that makes sense, but how do you know that your machine wasn't compromised when validating the previous blocks? And what if you want to check some old transactions (assuming you didn't index everything)? What if some of your old transaction data was lost or corrupted? I think it is clear that it is useful to be able to validate all blocks (since 100 years) rather than just a pruned part. It empowers people to have as much information about Bitcoin transactions as do large data centers; transactions that may include government or corporate corruption. This is the key to how Bitcoin enables transparency for those who should be transparent (individual users with private addresses can still remain anonymous). Also, 5 TB takes about 20 days to sync starting fresh, on a regular computer, so it allows easy entry into the system.

So assuming we agree that people should be able to store ~ a lifetime of transactions, then we need 1 MB blocks. But of course, this leads to huge transaction costs, and small purchases will be out of limits. So to fix this, I propose adding a 10 1 MB chains below the main chain (sorry on the IRC room I said 10 10 MB chains by mistake), so effectively, you have a new 10 MB chain that is partitioned into 10 parts. You can also add a third level: 100 1 MB chains, and keep going like that. The idea is that when you make a large transaction, you put it through the top chain; when you make a medium sized transaction, you put it through one of the middle chains, which will be verified (mined) by the middle chain, and the top chain will verify the aggregate transactions of the middle chain. If you have a small sized transaction, you put it through one of the bottom chains, the bottom chain verifies it, the middle chain verifies the aggregate transactions of the bottom chain, and the top chain verifies the aggregate transactions of the middle chain. By aggregate transaction, I mean the net result of multiple transactions, and I suppose it can be 20 transactions belonging only to one "sibling" chain for level 2, or 200 transactions for level 3, etc...

Now, how does the system decide to which of the 10 chains the middle sized transaction goes to? I propose just taking some simple function of the input addresses mod 10, so that you can just keep randomly generating a wallet until you get one with only addresses that map to only one of the 10 chains (even distribution), so that someone can choose one of the 10 chains, and store only the transactions that belong to that chain. They should also choose a chain from level 3, etc... So in effect, they will be storing a chain with block size O(n) where n is the number of levels. They may store multiple sibling chains at one level, if they want to track of other people's transactions, such as those of their government MP, or perhaps, they want to have a separate identity that would be more anonymous with a separate series of sibling chains. This will increase the storage size, but the increase will be proportional to the number of things you want to keep track of (at least this kind of system gives you the ability to fine tune your storage needs to the level of "things" you want to keep track of). Also, note that there may likely be duplication of transactions, since transactions can include addresses that are associated with different silbling chains, but this effect shouldn't make a big difference, and again will depend on the complexity of the transactions you want to keep track of.

So how can this work? I propose that we keep the current chain as the top chain, and then create 10 level 2 chains that also store Bitcoin and the Bitcoin can be transferred between chains (I think this is the idea of sidechains). How can we incentivize people to keep mining on the level 1 chain? Perhaps force it into the (soft fork) protocol that anyone mining on level 2, has to also mine on level 1, and in general, anyone mining on level n+1 has to also mine on levels n,n-1,...,1. Also, level 1 will have the best decentralization, so there should be enough people paying fees to get transactions there for their large transactions that require a high level of security and trust. Even if people stop using level 1, any bitcoin you own in the level 1 chain, can be transferred to level 2, and still you have 1 MB blocks due to the partitioning scheme. How to prevent transactions from clustering on one or a  few sibling chains in a particular level? Well the more empty chains should have lower fees, so that should incentivize people... Note: This system also allows for the fine tuning of the transaction size to security ratio. Yes the lower chains will be less secure, but a lower sized transaction does not need as much security.

For instant transactions, there can also be Lightning channels linked to whatever level of chain you want.

OK so it seems to me that this can work and would only require a soft fork. But, as I said, I only have a high level understanding of the Bitcoin protocol, so it feels kind of too good to be true, and I am ready for heavy criticism. I am only writing this because I care about Bitcoin and I want it to remain decentralized and become the best that it can be. I think it is important to do the right thing rather than (as most people naturally do) the most convenient thing.

Thanks

--
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Eric Martindale | 19 May 18:13 2015

ChainDB Whitepaper


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello all,

BitPay has just released our first whitepaper on ChainDB, a new
peer-to-peer database system backed by the Bitcoin blockchain.  This
paper outlines our intended consensus mechanism, proof of fee.

Please take a look at the paper here: https://bitpay.com/chaindb.pdf

We are seeking comments and feedback on this mechanism.  I am happy to
answer any questions about the paper itself.

Sincerely,

Eric Martindale
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVW2E9AAoJEHLoNvKeOhrJkLwP/1J14yGlZzddp4ApGRFsnnIz
t8U9uZVvjsqxseYv6Pw3ZStQRkuBgcPDcQwMexeBi/0Z5K34LOM1565XRLtNG2sb
AeLHG11ZLNK9SQSga2B0yc95uXs2Zje7Z+A+Q+h7HjhnkcQKbuLA+kB2+ZJv1CA3
dV/5A0oCMBbZukzuFkbgmnhCaNwYjWY15UbwksKb2c3ktuLxZ5zUq/ZI+W+0PZsN
Px2m/qkKb0UiUfbZU5Zva8HSI8lxQrEm/dkv4voglwlG3M7fvmgXcUi+8q0VslDi
2Bx99rhpBaC79eHDUouhTNvLykP7Hal4KdyuzShlNBN+Z6AQyoeOdAQhk9YNw/iq
c/tyiw6fFQVjEOJuJfetl2thByI+/hNH2m70BRXnaOtM+rQ4iIeaR7KevMi+WyYr
+X9M6eqaYvkVXD1y0lEDCfsatYIhLUcXUVkM8gAdXF2yatqfCHENVYdZu9EDhYNa
zC/N2akO+XNmj0a4mder3Oy0/j7vHTXq8HLHGFbCy3S3nld+A0Qe0/JTo/Vj1IZX
REyBnWsaguIE8l/I/+423rzQYKlSEwP5j+V/ObTYouVCwmy+uJC8evNCI8T/APy9
Y04ocYLb2DnKLDOD8mlf+huf4x9WwK8+CdF/wm2g1SxLBchy5lkrmhbbD846HiRF
m7EvzfRGI5zweCNIyx9Y
=nDJ2
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Dave Collins | 19 May 18:05 2015

Regtest Consensus Forking Behavior Introduced in Bitcoin Core in May 2014

Hello All,

Josh Rickmar and I discovered a subtle consensus change in Bitcoin Core
which causes forking behavior on regtest.  Luckily it does not affect
mainnet or testnet, however it does mean that regtest difficulty
retargetting is broken.

I've made a post to the bitcointalk forums at
https://bitcointalk.org/index.php?topic=1065504 for the nicer formatting
which explains in detail.

Regards,

Dave Collins

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Wladimir J. van der Laan | 19 May 15:44 2015
Picon

Bitcoin Core 0.10.2 released


------------------------------------------------------------------------------
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
Wladimir J. van der Laan | 19 May 10:25 2015
Picon

Bitcoin Core 0.9.5 release candidate 1 tagged

Hello,

I've just tagged release candidate 1 for 0.9.5 (tag `v0.9.5rc1`).

The reason for this backport release is to make BIP66 available on the 0.9 branch. This has been requested by
a few users, mostly miners.

Full (preliminary) release notes can be found at: 
https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md

In contrast to 0.10.x releases it is unclear whether there will be enough gitian signatures for a binary
release, any help with building is welcome.
See https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-process.md
(many steps have changed since then, so the release process for 0.10 or master will not work)

Wladimir

------------------------------------------------------------------------------
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
Justus Ranvier | 18 May 23:57 2015

Re: Open Bitcoin Privacy Project Spring 2015 Report


Replying to the list because this is a common question.

We rated as many wallets as we could based on the amount of manpower
we had available to perform the ratings.

We will be holding a recruiting drive shortly to solicit additional
volunteers so that we can cover more wallet for the next round of ratings.

On 05/18/2015 11:40 PM, Eric Lombrozo wrote:
> mSIGNA is notably absent from the report despite having some of the
> most advanced security and privacy features and having been on the
> bitcoin.org site longer than some of the other wallets reviewed.
> 
> Is there some process to get reviewed I missed? Please add us to
> the report.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus <at> openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
Attachment (0xEAD9E623.asc): application/pgp-keys, 17 KiB
------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Justus Ranvier | 18 May 18:16 2015

Open Bitcoin Privacy Project Spring 2015 Report


We're produced the first in what we hope to be a long series of
reviews of Bitcoin wallet privacy features, available here:

http://www.openbitcoinprivacyproject.org/2015/05/spring-2015-wallet-privacy-rating-report/

https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/raw/master/2015-1/OBPP%20Bitcoin%20Wallet%20Privacy%20Rating%20Report%20-%20Spring%202015.pdf

Specifically from the readers of this list, we are very interested in
feedback regarding our privacy threat model and the rating criteria we
derive from it.

Threat model:
https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/2015-1/threat%20model.wiki

Please send any suggestions or corrections via a GitHub issue to the
wallet-ratings repository so that we can incorporate it into future
reports.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
justus <at> openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
Attachment (0xEAD9E623.asc): application/pgp-keys, 17 KiB
------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Tom Harding | 14 May 17:22 2015

No Bitcoin For You

A recent post, which I cannot find after much effort, made an excellent
point.

If capacity grows, fewer individuals would be able to run full nodes. 
Those individuals, like many already, would have to give up running a
full-node wallet :(

That sounds bad, until you consider that the alternative is running a
full node on the bitcoin 'settlement network', while massive numbers of
people *give up any hope of directly owning bitcoin at all*.

If today's global payments are 100Ktps, and move to the Lightning
Network, they will have to be consolidated by a factor of 25000:1 to fit
into bitcoin's current 4tps capacity as a settlement network.  You
executing a personal transaction on that network will be about as likely
as you personally conducting a $100 SWIFT transfer to yourself today. 
For current holders, just selling or spending will get very expensive!

Forcing block capacity to stay small, so that individuals can run full
nodes, is precisely what will force bitcoin to become a backbone that is
too expensive for individuals to use.  I can't avoid the conclusion that
Bitcoin has to scale, and we might as well be thinking about how.

There may be a an escape window.  As current trends continue toward a
landscape of billions of SPV wallets, it may still be possible for
individuals collectively to make up the majority of the network, if more
parts of the network itself rely on SPV-level security.

With SPV-level security, it might be possible to implement a scalable
DHT-type network of nodes that collectively store and index the
exhaustive and fast-growing corpus of transaction history, up to and
including currently unconfirmed transactions.  Each individual node
could host a slice of the transaction set with a configurable size,
let's say down to a few GB today.

Such a network would have the desirable property of being run by the
community.  Most transactions would be submitted to it, and like today's
network, it would disseminate blocks (which would be rapidly torn apart
and digested).  Therefore miners and other full nodes would depend on
it, which is rather critical as those nodes grow closer to data-center
proportions.

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

Gmane