Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
Well the point of the Merkle tree is that if I all you have is the top, and all I give you is a leaf node and the siblings of all parents of that leaf, then by simply hashing you can check if the node was actually present in the tree. The only reason this works is because it's hard for an attacker to come up with the list of values which would ultimately hash together to produce the expected top value. But if the hash function is actually just XOR, it becomes completely trivial for me to claim any value I want was in the tree. 1) Pick the fake value you want to claim was in the tree (leaf node) 2) Choose some random values to fake the depth in the tree 3) Calculate the last value as 'Prev (x) Top' 4) When your victim goes to verify set membership, they will get the top value they expected On Tue, 04 Feb 2014 08:04:14 -0800, Peter Todd wrote: > On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote: >> Because it's trivial to create collisions! You can choose exactly what >> output you want. That's why XOR is a very bad digest scheme. > > You're close, but not quite. > > So, imagine you have a merkle tree, and you're trying to timestamp some > data at the bottom of the tree. Now you can successfully timestamp the > top digest in the Bitcoin blockchain right, and be sure that digest > existed before some time. But what about the digests at the bottom of > the tree? What can an attacker do exactly to make a fake timestamp if > the tree is using XOR rather than a proper hash function? -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote: > Because it's trivial to create collisions! You can choose exactly what > output you want. That's why XOR is a very bad digest scheme. You're close, but not quite. So, imagine you have a merkle tree, and you're trying to timestamp some data at the bottom of the tree. Now you can successfully timestamp the top digest in the Bitcoin blockchain right, and be sure that digest existed before some time. But what about the digests at the bottom of the tree? What can an attacker do exactly to make a fake timestamp if the tree is using XOR rather than a proper hash function? -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
Because it's trivial to create collisions! You can choose exactly what output you want. That's why XOR is a very bad digest scheme. - Sent from my phone Den 4 feb 2014 14:20 skrev "Peter Todd" : > On Tue, Feb 04, 2014 at 02:13:12PM +0100, Mike Hearn wrote: > > Hah, good point. If nobody completes the homework, I'll post a fixed > > version tomorrow :) > > Heh, here's another 25mBTC while we're at it: > > > https://github.com/opentimestamps/opentimestamps-client/commit/288f3c17626974de7eaef4f1c9b5cd93eecf40f6 > > Why is that a bad idea? > > Bonus question: What was I smoking? (hint: where do I live?) > > > On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd wrote: > > > > > On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote: > > > > Hello, > > > > > > > > I'm pleased to announce the release of bitcoinj 0.11, a library for > > > writing Bitcoin applications that run on the JVM. BitcoinJ is widely > used > > > across the Bitcoin community; some users include Bitcoin Wallet for > > > Android, MultiBit, Hive, blockchain.info, the biteasy.com block > explorer > > > (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), > bitpos.me, > > > Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic > advanced > > > contracts research and more. > > > > > > > > The release-0.11 git tag is signed by Andreas Schildbach's GPG key. > The > > > commit hash is 410d4547a7dd. This paragraph is signed by the same > Bitcoin > > > key as with previous releases (check their release announcements to > > > establish continuity). Additionally, this email is signed using DKIM > and > > > for the first time, a key that was ID verified by the Swiss government. > > > > > > > > Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m > > > > Signature for last paragraph: > > > > H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg= > > > > > > The above makes for a great homework problem for budding > cryptographers: > > > Why did the three forms of signature, DKIM, long-lived bitcoin address, > > > and Official Swiss Government Identity fail to let you actually verify > > > you have the right code? (but make for great security theater) > > > > > > Bonus question: Who has the smallest work-factor for such an attack? > > > > > > Two rewards of 25mBTC for correct responses to each question from a > > > crypto newbie. > > > > > > > Thanks to Mike Belshe, the wallet can now send to P2SH addresses. > > > > > > Thanks > > > > > > > Generated signatures now use canonical S values. This will aid a > future > > > hard-forking rule change which bans malleable signatures. > > > > > > Soft-forking rule change. > > > > > > -- > > > 'peter'[:-1]@petertodd.org > > > 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 > > > > > -- > 'peter'[:-1]@petertodd.org > 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 > > > -- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
On Tue, Feb 04, 2014 at 09:43:31AM -0500, Jeff Garzik wrote: > On Tue, Feb 4, 2014 at 8:17 AM, Peter Todd wrote: > > Bonus question: What was I smoking? (hint: where do I live?) > > Cryptographers smoke... hash, right? > > (couldn't resist) I think we have a winner; as you can see Jeff must be a great father. -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
On Tue, Feb 4, 2014 at 8:17 AM, Peter Todd wrote: > Bonus question: What was I smoking? (hint: where do I live?) Cryptographers smoke... hash, right? (couldn't resist) -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
On Tue, Feb 04, 2014 at 02:13:12PM +0100, Mike Hearn wrote: > Hah, good point. If nobody completes the homework, I'll post a fixed > version tomorrow :) Heh, here's another 25mBTC while we're at it: https://github.com/opentimestamps/opentimestamps-client/commit/288f3c17626974de7eaef4f1c9b5cd93eecf40f6 Why is that a bad idea? Bonus question: What was I smoking? (hint: where do I live?) > On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd wrote: > > > On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote: > > > Hello, > > > > > > I'm pleased to announce the release of bitcoinj 0.11, a library for > > writing Bitcoin applications that run on the JVM. BitcoinJ is widely used > > across the Bitcoin community; some users include Bitcoin Wallet for > > Android, MultiBit, Hive, blockchain.info, the biteasy.com block explorer > > (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), bitpos.me, > > Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic advanced > > contracts research and more. > > > > > > The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The > > commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin > > key as with previous releases (check their release announcements to > > establish continuity). Additionally, this email is signed using DKIM and > > for the first time, a key that was ID verified by the Swiss government. > > > > > > Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m > > > Signature for last paragraph: > > H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg= > > > > The above makes for a great homework problem for budding cryptographers: > > Why did the three forms of signature, DKIM, long-lived bitcoin address, > > and Official Swiss Government Identity fail to let you actually verify > > you have the right code? (but make for great security theater) > > > > Bonus question: Who has the smallest work-factor for such an attack? > > > > Two rewards of 25mBTC for correct responses to each question from a > > crypto newbie. > > > > > Thanks to Mike Belshe, the wallet can now send to P2SH addresses. > > > > Thanks > > > > > Generated signatures now use canonical S values. This will aid a future > > hard-forking rule change which bans malleable signatures. > > > > Soft-forking rule change. > > > > -- > > 'peter'[:-1]@petertodd.org > > 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 > > -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
Hah, good point. If nobody completes the homework, I'll post a fixed version tomorrow :) On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd wrote: > On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote: > > Hello, > > > > I'm pleased to announce the release of bitcoinj 0.11, a library for > writing Bitcoin applications that run on the JVM. BitcoinJ is widely used > across the Bitcoin community; some users include Bitcoin Wallet for > Android, MultiBit, Hive, blockchain.info, the biteasy.com block explorer > (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), bitpos.me, > Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic advanced > contracts research and more. > > > > The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The > commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin > key as with previous releases (check their release announcements to > establish continuity). Additionally, this email is signed using DKIM and > for the first time, a key that was ID verified by the Swiss government. > > > > Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m > > Signature for last paragraph: > H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg= > > The above makes for a great homework problem for budding cryptographers: > Why did the three forms of signature, DKIM, long-lived bitcoin address, > and Official Swiss Government Identity fail to let you actually verify > you have the right code? (but make for great security theater) > > Bonus question: Who has the smallest work-factor for such an attack? > > Two rewards of 25mBTC for correct responses to each question from a > crypto newbie. > > > Thanks to Mike Belshe, the wallet can now send to P2SH addresses. > > Thanks > > > Generated signatures now use canonical S values. This will aid a future > hard-forking rule change which bans malleable signatures. > > Soft-forking rule change. > > -- > 'peter'[:-1]@petertodd.org > 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 > -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote: > Hello, > > I'm pleased to announce the release of bitcoinj 0.11, a library for writing > Bitcoin applications that run on the JVM. BitcoinJ is widely used across the > Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit, > Hive, blockchain.info, the biteasy.com block explorer (written in Lisp!), > Circle, Neo/Bee (Cypriot payment network), bitpos.me, Bitcoin Touch, > BlueMatt's relay network and DNS crawler, academic advanced contracts > research and more. > > The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The > commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin key > as with previous releases (check their release announcements to establish > continuity). Additionally, this email is signed using DKIM and for the first > time, a key that was ID verified by the Swiss government. > > Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m > Signature for last paragraph: > H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg= The above makes for a great homework problem for budding cryptographers: Why did the three forms of signature, DKIM, long-lived bitcoin address, and Official Swiss Government Identity fail to let you actually verify you have the right code? (but make for great security theater) Bonus question: Who has the smallest work-factor for such an attack? Two rewards of 25mBTC for correct responses to each question from a crypto newbie. > Thanks to Mike Belshe, the wallet can now send to P2SH addresses. Thanks > Generated signatures now use canonical S values. This will aid a future > hard-forking rule change which bans malleable signatures. Soft-forking rule change. -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
Hello,
I'm pleased to announce the release of bitcoinj 0.11, a library for writing
Bitcoin applications that run on the JVM. BitcoinJ is widely used across the
Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit,
Hive, blockchain.info, the biteasy.com block explorer (written in Lisp!),
Circle, Neo/Bee (Cypriot payment network), bitpos.me, Bitcoin Touch, BlueMatt's
relay network and DNS crawler, academic advanced contracts research and more.
The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The commit
hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin key as with
previous releases (check their release announcements to establish continuity).
Additionally, this email is signed using DKIM and for the first time, a key
that was ID verified by the Swiss government.
Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature for last paragraph:
H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg=
Notable changes and new features
Thanks to Ken Sedgwick, an implementation of BIP39 ("Mnemonic code for
generating deterministic keys") has been added. This is compatible with the
latest Trezor implementation.
Thanks to Mike Belshe, the wallet can now send to P2SH addresses.
Thanks to Matt Corallo, the network layer was rewritten from scratch. It no
longer depends on Netty, and it now supports both blocking and non-blocking
sockets. In practice that means Java's built in support for transparent SSL and
SOCKS becomes available again, which in turn means connecting via Tor is now
possible. The new framework is lightweight, easy to understand and has been
running a DNS seed crawler for some months now.
Thanks to Kevin Greene, we've added some support for the BIP70 payment
protocol. Wallet authors can now consume payment requests, check their
signatures and submit payments with the new easy to use PaymentSession class.
The wallet-tool command line UI has support and an article explains how to use
it.
Thanks to Miron Cuperman, the wallet can now watch arbitrary addresses and
scripts. The wallet could previously watch an address as long as the public key
was known. Now it's possible to watch for addresses even when the public key is
not known.
Also thanks to Miron, Bloom filtering was also improved. The system now tracks
false positive rates and cleans the filter when FP rates get too high.
Unfortunately, some privacy bugs in Bloom filtering remain, which could
(amongst other things) allow a malicious remote peer to test whether you own a
particular key.
Thanks to Alex Taylor (bitpos.me), a new PostgreSQL based pruning block store
was added. This block store is fast, and indexes the UTXO set, allowing for
fast lookup of the balance of any given address.
A Java 8 based wallet template app is now included. The template is designed
for people writing contract based applications. It provides a simple app that
can be copy/pasted, which connects to the P2P network, manages a wallet, and
provides a GUI that shows progress, balance, address+qrcode for receiving money
and has a button that is used to empty the wallet out. It's designed to have an
attractive and modern look, with tasteful animations and artwork.
Micropayment channels got many big improvements to the API and implementation.
The release in 0.10 can be seen as a beta, in this release the micropayments
code has been taken for a test drive for a couple of real apps and many rough
edges polished as a result.
The default USER_THREAD executor can now be replaced, allowing a 1-line switch
of all callbacks onto a thread of your choice instead of needing to override
each callback, each time. This should simplify and clean up the GUI code of
wallet apps significantly.
The WalletTool command line app has a more convenient user interface now.
A new DNS seed has been added. The seed is run by Christian Decker, from ETH
Zurich.
bitcoinj 0.11 will shortly be available via Maven Central. Please use the
dependency verifier plugin and/or check the PGP signatures on the uploads, if
you use this!
Smaller improvements
We finished adding nullity annotations to the API. You should now be able to
assume that any method not annotated with @Nullable won't ever return null
values.
The WalletAppKit got a bunch of new features and convenience APIs.
The wallet will now create inputs with dummy signatures if the private key for
an output is missing, rather than throwing an exception. You can then edit the
input later to substitute in a real signature. This is useful when the signing
is being done elsewhere, outside of the library.
In full verification mode, execution of scripts (i.e. checking signatures) can
now be switched off. This is useful if you trust the source of the chain and
just want to calculate the UTXO set.
The wallet risk analysis code is now pluggable, better documented and checks
for finality in a more sensible way.
Various memory usage and flow co
