Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
As a researcher in a distributed systems group, it is awesome to see these papers flocking up that help convince the supervisors to pay more attention to blockchain technologies. thanks for keeping us up to speed. 2015-03-02 16:48 GMT+00:00 Andrew Miller : > We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, > Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have > written a “systemization” paper about Bitcoin-related research. It’s > going to appear in the Oakland security conference later this year > (IEEE Security and Privacy) but we wanted to announce a draft to this > community ahead of time. > > http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf > > One of the main goals of our work is to build a bridge between the > computer science research community and the cryptocurrency community. > Many of the most interesting ideas and proposals for Bitcoin come from > this mailing list and forums/wikis/irc channels, where many academic > researchers simply don’t know to look! In fact, we started out by > scraping all the interesting posts/articles we could find and trying > to figure out how we could organize them. We hope our paper helps some > of the best ideas and research questions from the Bitcoin community > bubble up and inspires researchers to build on them. > > We didn’t limit our scope to Bitcoin, but we also decided not to > provide a complete survey of altcoins and other next-generation > cryptocurrency designs. Instead, we tried to explain all the > dimensions along which these designs differ from Bitcoin. > > This effort has roughly been in progress over two years, though it > stopped and restarted several times along the way. > > If anyone has comments or suggestions, we still have a week before the > final version is due, and regardless we plan to continue updating our > online version for the forseeable future. > > -- > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ricardo Filipe GSD/INESC-ID Lisboa -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
On 02/26/2015 04:30 AM, Andreas Schildbach wrote: > On 02/24/2015 11:41 AM, Mike Hearn wrote: >> On 02/23/2015 04:10 PM, Eric Voskuil wrote: >>> Does this not also require the BT publication of the script for a P2SH >>> address? >> >> You mean if the URI you're serving is like this? >> >>bitcoin:3aBcD?bt= >> >> Yes it would. I guess then, the server would indicate both the script, >> and the key within that script that it wanted to use. A bit more complex >> but would still work to save URI space. > > What if the script doesn't use any key at all? > > Somehow this "re-using" the fallback address idea feels less and less > appealing to me. I think we should add our own parameter and let go of > fallback addresses as soon as possible. If will waste space during the > transition period, but after that it should make no difference any more. Agree. The amount of bitcoin URI space in question isn't a material issue when it comes to NFC. The more significant considerations here are the additional BT round trip to establish a session, greater complexity, and the potential lack of a correlating address (as you point out above). On the other hand I think the approach has merit in a scenario where the bitcoin URI is read from a QR code and BT is available (IOW no NFC). Generalizing it to the NFC-based bitcoin URI is the problem. A much cleaner generalization is to rationalize the two approaches *after* the bitcoin URI has been read (from either NFC or QR). In the QR scenario the wallet can obtain a verifiable public key from the BT terminal (subject to some limitations as discussed above). In the NFC scenario the public key is just passed in the URI. The scenarios come together at the point where they both have the public key (and the mac address). This of course implies that the the BT URL scheme, in order to be used in both places, would have to allow the public key to be optional. But in an NFC tap it would be present and in a QR scan it would not. QR-BT bitcoin:?bts: NFC-BT bitcoin:[bitcoin-address]?bts:/ As you say, this prevents the NFC scenario from perpetuating the fallback address as a requirement, which eventually shortens the bitcoin URI. Making the public key a requirement when used with NFC would simplify wallet development for NFC only wallets. But if a wallet supported both NFC and QR scanning it wouldn't make much difference. So it's not unreasonable to think of it like this: QR-BT/NFC-BT bitcoin:?bts: bitcoin:[bitcoin-address]?bts:/ This provides greater generality, but it creates a situation where NFC-only wallets need to support the more complex approach, and where use in QR codes would have scanning issues. So I think it's better to specify limits on each as in the first example. e signature.asc Description: OpenPGP digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
Great to see Electrum 2.0 tagged ! It's been a long road I know. Congratulations to ThomasV and all the other Electrum contributors. :-) Jim -- http://bitcoin-solutions.co.uk On Mon, Mar 2, 2015, at 03:37 PM, Mike Hearn wrote: > Congrats Thomas! Glad to see Electrum 2 finally launch. > > > > * New seed derivation method (not compatible with BIP39). > > > Does this mean a "12 words" wallet created by Electrum won't work if > imported into some other wallet that supports BIP39? Vice versa? This seems > unfortunate. I guess if seeds are being represented with 12 words > consistently, people will expect them to work everywhere. > -- > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have written a “systemization” paper about Bitcoin-related research. It’s going to appear in the Oakland security conference later this year (IEEE Security and Privacy) but we wanted to announce a draft to this community ahead of time. http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf One of the main goals of our work is to build a bridge between the computer science research community and the cryptocurrency community. Many of the most interesting ideas and proposals for Bitcoin come from this mailing list and forums/wikis/irc channels, where many academic researchers simply don’t know to look! In fact, we started out by scraping all the interesting posts/articles we could find and trying to figure out how we could organize them. We hope our paper helps some of the best ideas and research questions from the Bitcoin community bubble up and inspires researchers to build on them. We didn’t limit our scope to Bitcoin, but we also decided not to provide a complete survey of altcoins and other next-generation cryptocurrency designs. Instead, we tried to explain all the dimensions along which these designs differ from Bitcoin. This effort has roughly been in progress over two years, though it stopped and restarted several times along the way. If anyone has comments or suggestions, we still have a week before the final version is due, and regardless we plan to continue updating our online version for the forseeable future. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
Congrats Thomas! Glad to see Electrum 2 finally launch. > * New seed derivation method (not compatible with BIP39). Does this mean a "12 words" wallet created by Electrum won't work if imported into some other wallet that supports BIP39? Vice versa? This seems unfortunate. I guess if seeds are being represented with 12 words consistently, people will expect them to work everywhere. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development