Stanford University Launches New Blockchain Research

CS251P: 'Bitcoin Engineering', taught by Balaji Srinivasan and Dan Boneh. ("Stanford's new lab course on building Bitcoin-enabled applications. Learn how to rewire internet services on the basis of Bitcoin.")

CS251P: 'Bitcoin Engineering', taught by Balaji Srinivasan and Dan Boneh. ( submitted by eragmus to Bitcoin [link] [comments]

CS251P: 'Bitcoin Engineering', taught by Balaji Srinivasan and Dan Boneh. ("Stanford's new lab course on building Bitcoin-enabled applications. Learn how to rewire internet services on the basis of Bitcoin.")

CS251P: 'Bitcoin Engineering', taught by Balaji Srinivasan and Dan Boneh. ( submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Finally! Real privacy for Bitcoin transactions from some Core developers

Greg Maxwell made a VERY exciting announcement for some real cutting edge stuff: a way to get full privacy with transactions in Bitcoin!
The great thing about this is, unlike ZCash, this new method:
There is a video here that describes confidential transactions in more detail. But the exciting announcement today is a way to make confidential transactions work with a size overhead only 3 times that of normal transactions. When combined with the further privacy improvement of CoinJoin or ValueShuffle, there is virtually no size overhead and no trusted third party or sharing of private data is required!
Thank you Greg, Pieter, and other Core team contributors for this excellent work on confidential transactions, coinjoin, and working on the theory and engineering to bring this to Bitcoin! Exciting developments! Thanks also Benedikt Bünz, Jonathan Bootle for your discovery of BulletProofs and Dan Boneh, Andrew Poelstra for your work on this.
Update: As pwuille pointed out, while the size overhead is 3X (or less per transaction w/ coinjoin), the CPU overhead for verification is still an order of magnitude higher than regular transactions. But we'll know more once they start working on an implementation.
submitted by fortunative to Bitcoin [link] [comments]

Minimizing Trust in Hardware Wallets with Two Factor Signatures

Cryptology ePrint Archive: Report 2019/006
Date: 2019-01-02
Author(s): Antonio Marcedone, Rafael Pass, abhi shelat

Link to Paper


Abstract
We introduce the notion of two-factor signatures (2FS), a generalization of a two-out-of-two threshold signature scheme in which one of the parties is a hardware token which can store a high-entropy secret, and the other party is a human who knows a low-entropy password. The security (unforgeability) property of 2FS requires that an external adversary corrupting either party (the token or the computer the human is using) cannot forge a signature. This primitive is useful in contexts like hardware cryptocurrency wallets in which a signature conveys the authorization of a transaction. By the above security property, a hardware wallet implementing a two-factor signature scheme is secure against attacks mounted by a malicious hardware vendor; in contrast, all currently used wallet systems break under such an attack (and as such are not secure under our definition). We construct efficient provably-secure 2FS schemes which produce either Schnorr signature (assuming the DLOG assumption), or EC-DSA signatures (assuming security of EC-DSA and the CDH assumption) in the Random Oracle Model, and evaluate the performance of implementations of them. Our EC-DSA based 2FS scheme can directly replace currently used hardware wallets for Bitcoin and other major cryptocurrencies to enable security against malicious hardware vendors.

References
[1] Jes´us F Almansa, Ivan Damg˚ard, and Jesper Buus Nielsen. Simplified threshold RSA with adaptive and proactive security. In Eurocrypt, volume 4004, pages 593–611. Springer, 2006.
[2] Dan Boneh, Xuhua Ding, Gene Tsudik, and Chi-Ming Wong. A method for fast revocation of public key certificates and security capabilities. In USENIX Security Symposium, pages 22–22, 2001.
[3] Jan Camenisch, Anja Lehmann, Gregory Neven, and Kai Samelin. Virtual smart cards: how to sign with a password and a server, 2016.
[4] Yvo Desmedt and Yair Frankel. Threshold cryptosystems. In Advances in Cryptology – CRYPTO 1989, pages 307–315. Springer, 1990.
[5] J. Doerner, Y. Kondi, E. Lee, and a. shelat. Secure two-party threshold ECDSA from ECDSA assumptions. In 2018 IEEE Symposium on Security and Privacy (SP), pages 595–612, 2018.
[6] Rosario Gennaro and Steven Goldfeder. Fast multiparty threshold ecdsa with fast trustless setup. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1179–1194. ACM, 2018.
[7] Rosario Gennaro, Stanis law Jarecki, Hugo Krawczyk, and Tal Rabin. Robust and efficient sharing of RSA functions. In Advances in Cryptology – CRYPTO 1996, pages 157–172. Springer, 1996.
[8] Steven Goldfeder, Rosario Gennaro, Harry Kalodner, Joseph Bonneau, Joshua A Kroll, Edward W Felten, and Arvind Narayanan. Securing bitcoin wallets via a new DSA/ECDSA threshold signature scheme, 2015.
[9] Yehuda Lindell. Fast secure two-party ECDSA signing. In Advances in Cryptology – CRYPTO 2017, pages 613–644. Springer, 2017.
[10] Yehuda Lindell and Ariel Nof. Fast secure multiparty ecdsa with practical distributed key generation and applications to cryptocurrency custody. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1837–1854. ACM, 2018.
[11] Philip MacKenzie and Michael K Reiter. Delegation of cryptographic servers for capture-resilient devices. Distributed Computing, 16(4):307–327, 2003.
[12] Philip MacKenzie and Michael K Reiter. Networked cryptographic devices resilient to capture. International Journal of Information Security, 2(1):1–20, 2003.
[13] Antonio Marcedone, Rafael Pass, and abhi shelat. Minimizing trust in hardware wallets with two factor signatures. Cryptology ePrint Archive, Report 2018/???, 2018.
[14] Microchip. Atecc608a datasheet, 2018.
[15] Antonio Nicolosi, Maxwell N Krohn, Yevgeniy Dodis, and David Mazieres. Proactive two-party signatures for user authentication. In NDSS, 2003.
[16] Marek Palatinus, Pavol Rusnak, Aaron Voisine, and Sean Bowe. Mnemonic code for generating deterministic keys (bip39). https://github.com/bitcoin/bips/blob/mastebip-0039.mediawiki.
[17] Tal Rabin. A simplified approach to threshold and proactive RSA. In Advances in Cryptology – CRYPTO 1998, pages 89–104. Springer, 1998.
[18] T.C. Sottek. Nsa reportedly intercepting laptops purchased online to install spy malware, December 2013. [Online; posted 29-December-2013; https://www.theverge.com/2013/12/29/5253226/nsacia-fbi-laptop-usb-plant-spy].
submitted by dj-gutz to myrXiv [link] [comments]

Compact Multi-Signatures for Smaller Blockchains

Cryptology ePrint Archive: Report 2018/483
Date: 2018-06-10
Author(s): Dan Boneh, Manu Drijvers, Gregory Neven

Link to Paper


Abstract
We construct new multi-signature schemes that provide new functionality. Our schemes are designed to reduce the size of the Bitcoin blockchain, but are useful in many other settings where multi-signatures are needed. All our constructions support both signature compression and public-key aggregation. Hence, to verify that a number of parties signed a common message m, the verifier only needs a short multi-signature, a short aggregation of their public keys, and the message m. We give new constructions that are derived from Schnorr signatures and from BLS signatures. Our constructions are in the plain public key model, meaning that users do not need to prove knowledge or possession of their secret key.
In addition, we construct the first short accountable-subgroup multi-signature (ASM) scheme. An ASM scheme enables any subset S of a set of n parties to sign a message m so that a valid signature discloses which subset generated the signature (hence the subset S is accountable for signing m). We construct the first ASM scheme where signature size is only O(k) bits over the description of S, where k is the security parameter. Similarly, the aggregate public key is only O(k) bits, independent of n. The signing process is non-interactive. Our ASM scheme is very practical and well suited for compressing the data needed to spend funds from a t-of-n Multisig Bitcoin address, for any (polynomial size) t and n.

References
  1. Ahn, J.H., Green, M., Hohenberger, S.: Synchronized aggregate signatures: new definitions, constructions and applications. In: Al-Shaer, E., Keromytis, A.D., Shmatikov, V. (eds.) ACM CCS 10: 17th Conference on Computer and Communications Security. pp. 473–484. ACM Press, Chicago, Illinois, USA (Oct 4–8, 2010)
  2. Andresen, G.: m-of-n standard transactions. Bitcoin improvement proposal (BIP) 0011 (2011)
  3. Bagherzandi, A., Cheon, J.H., Jarecki, S.: Multisignatures secure under the discrete logarithm assumption and a generalized forking lemma. In: Ning, P., Syverson, P.F., Jha, S. (eds.) ACM CCS 08: 15th Conference on Computer and Communications Security. pp. 449–458. ACM Press, Alexandria, Virginia, USA (Oct 27–31, 2008)
  4. Bagherzandi, A., Jarecki, S.: Multisignatures using proofs of secret key possession, as secure as the Diffie-Hellman problem. In: Ostrovsky, R., Prisco, R.D., Visconti, I. (eds.) SCN 08: 6th International Conference on Security in Communication Networks. Lecture Notes in Computer Science, vol. 5229, pp. 218–235. Springer, Heidelberg, Germany, Amalfi, Italy (Sep 10–12, 2008)
  5. Bansarkhani, R.E., Sturm, J.: An efficient lattice-based multisignature scheme with applications to bitcoins. In: Foresti, S., Persiano, G. (eds.) CANS 16: 15th International Conference on Cryptology and Network Security. Lecture Notes in Computer Science, vol. 10052, pp. 140–155. Springer, Heidelberg, Germany, Milan, Italy (Nov 14–16, 2016)
  6. Barreto, P.S.L.M., Lynn, B., Scott, M.: On the selection of pairing-friendly groups. In: Matsui, M., Zuccherato, R.J. (eds.) SAC 2003: 10th Annual International Workshop on Selected Areas in Cryptography. Lecture Notes in Computer Science, vol. 3006, pp. 17–25. Springer, Heidelberg, Germany, Ottawa, Ontario, Canada (Aug 14–15, 2004)
  7. Bellare, M., Namprempre, C., Neven, G.: Unrestricted aggregate signatures. In: Arge, L., Cachin, C., Jurdzinski, T., Tarlecki, A. (eds.) ICALP 2007: 34th International Colloquium on Automata, Languages and Programming. Lecture Notes in Computer Science, vol. 4596, pp. 411–422. Springer, Heidelberg, Germany, Wroclaw, Poland (Jul 9–13, 2007)
  8. Bellare, M., Namprempre, C., Pointcheval, D., Semanko, M.: The one-more-RSAinversion problems and the security of Chaum’s blind signature scheme. Journal of Cryptology 16(3), 185–215 (Jun 2003)
  9. Bellare, M., Neven, G.: Multi-signatures in the plain public-key model and a general forking lemma. In: Juels, A., Wright, R.N., Vimercati, S. (eds.) ACM CCS 06: 13th Conference on Computer and Communications Security. pp. 390–399. ACM Press, Alexandria, Virginia, USA (Oct 30 – Nov 3, 2006)
  10. Boldyreva, A.: Threshold signatures, multisignatures and blind signatures based on the gap-Diffie-Hellman-group signature scheme. In: Desmedt, Y. (ed.) PKC 2003: 6th International Workshop on Theory and Practice in Public Key Cryptography. Lecture Notes in Computer Science, vol. 2567, pp. 31–46. Springer, Heidelberg, Germany, Miami, FL, USA (Jan 6–8, 2003)
  11. Boldyreva, A., Gentry, C., O’Neill, A., Yum, D.H.: Ordered multisignatures and identity-based sequential aggregate signatures, with applications to secure routing. In: Ning, P., di Vimercati, S.D.C., Syverson, P.F. (eds.) ACM CCS 07: 14th Conference on Computer and Communications Security. pp. 276–285. ACM Press, Alexandria, Virginia, USA (Oct 28–31, 2007)
  12. Boneh, D., Gentry, C., Lynn, B., Shacham, H.: Aggregate and verifiably encrypted signatures from bilinear maps. In: Biham, E. (ed.) Advances in Cryptology – EUROCRYPT 2003. Lecture Notes in Computer Science, vol. 2656, pp. 416–432. Springer, Heidelberg, Germany, Warsaw, Poland (May 4–8, 2003)
  13. Boneh, D., Lynn, B., Shacham, H.: Short signatures from the Weil pairing. In: Boyd, C. (ed.) Advances in Cryptology – ASIACRYPT 2001. Lecture Notes in Computer Science, vol. 2248, pp. 514–532. Springer, Heidelberg, Germany, Gold Coast, Australia (Dec 9–13, 2001)
  14. Brogle, K., Goldberg, S., Reyzin, L.: Sequential aggregate signatures with lazy verification from trapdoor permutations - (extended abstract). In: Wang, X., Sako, K. (eds.) Advances in Cryptology – ASIACRYPT 2012. Lecture Notes in Computer Science, vol. 7658, pp. 644–662. Springer, Heidelberg, Germany, Beijing, China (Dec 2–6, 2012)
  15. Budroni, A., Pintore, F.: Efficient hash maps to G2 on BLS curves. Cryptology ePrint Archive, Report 2017/419 (2017), http://eprint.iacr.org/2017/419
  16. Burmester, M., Desmedt, Y., Doi, H., Mambo, M., Okamoto, E., Tada, M., Yoshifuji, Y.: A structured ElGamal-type multisignature scheme. In: Imai, H., Zheng, Y. (eds.) PKC 2000: 3rd International Workshop on Theory and Practice in Public Key Cryptography. Lecture Notes in Computer Science, vol. 1751, pp. 466–483. Springer, Heidelberg, Germany, Melbourne, Victoria, Australia (Jan 18–20, 2000)
  17. Castelluccia, C., Jarecki, S., Kim, J., Tsudik, G.: A robust multisignatures scheme with applications to acknowledgment aggregation. In: Blundo, C., Cimato, S. (eds.) SCN 04: 4th International Conference on Security in Communication Networks. Lecture Notes in Computer Science, vol. 3352, pp. 193–207. Springer, Heidelberg, Germany, Amalfi, Italy (Sep 8–10, 2005)
  18. Certicom Research: Sec 2: Recommended elliptic curve domain parameters. Tech. rep., Certicom Research (2010)
  19. Chang, C.C., Leu, J.J., Huang, P.C., Lee, W.B.: A scheme for obtaining a message from the digital multisignature. In: Imai, H., Zheng, Y. (eds.) PKC’98: 1st International Workshop on Theory and Practice in Public Key Cryptography. Lecture Notes in Computer Science, vol. 1431, pp. 154–163. Springer, Heidelberg, Germany, Pacifico Yokohama, Japan (Feb 5–6, 1998)
  20. Coron, J.S., Naccache, D.: Boneh et al.’s k-element aggregate extraction assumption is equivalent to the Diffie-Hellman assumption. In: Laih, C.S. (ed.) Advances in Cryptology – ASIACRYPT 2003. Lecture Notes in Computer Science, vol. 2894, pp. 392–397. Springer, Heidelberg, Germany, Taipei, Taiwan (Nov 30 – Dec 4, 2003)
  21. Drijvers, M., EdalatNejad, K., Ford, B., Neven, G.: Okamoto beats Schnorr: On the provable security of multi-signatures. Cryptology ePrint Archive, Report 2018/417 (2018), https://eprint.iacr.org/2018/417
  22. Fuentes-Casta˜neda, L., Knapp, E., Rodr´ıguez-Henr´ıquez, F.: Faster hashing to ð2. In: Miri, A., Vaudenay, S. (eds.) SAC 2011: 18th Annual International Workshop on Selected Areas in Cryptography. Lecture Notes in Computer Science, vol. 7118, pp. 412–430. Springer, Heidelberg, Germany, Toronto, Ontario, Canada (Aug 11–12, 2012)
  23. Gentry, C., O’Neill, A., Reyzin, L.: A unified framework for trapdoor-permutationbased sequential aggregate signatures. In: Abdalla, M., Dahab, R. (eds.) PKC 2018: 21st International Conference on Theory and Practice of Public Key Cryptography, Part II. Lecture Notes in Computer Science, vol. 10770, pp. 34–57. Springer, Heidelberg, Germany, Rio de Janeiro, Brazil (Mar 25–29, 2018)
  24. Gentry, C., Ramzan, Z.: Identity-based aggregate signatures. In: Yung, M., Dodis, Y., Kiayias, A., Malkin, T. (eds.) PKC 2006: 9th International Conference on Theory and Practice of Public Key Cryptography. Lecture Notes in Computer Science, vol. 3958, pp. 257–273. Springer, Heidelberg, Germany, New York, NY, USA (Apr 24–26, 2006)
  25. Hardjono, T., Zheng, Y.: A practical digital multisignature scheme based on discrete logarithms. In: Seberry, J., Zheng, Y. (eds.) Advances in Cryptology – AUSCRYPT’92. Lecture Notes in Computer Science, vol. 718, pp. 122–132. Springer, Heidelberg, Germany, Gold Coast, Queensland, Australia (Dec 13–16, 1993)
  26. Harn, L.: Group-oriented (t, n) threshold digital signature scheme and digital multisignature. IEE Proceedings-Computers and Digital Techniques 141(5), 307–313 (1994)
  27. Horster, P., Michels, M., Petersen, H.: Meta-multisignature schemes based on the discrete logarithm problem. In: Information Securitythe Next Decade. pp. 128–142. Springer (1995)
  28. Itakura, K., Nakamura, K.: A public-key cryptosystem suitable for digital multisignatures. Tech. rep., NEC Research and Development (1983)
  29. Komano, Y., Ohta, K., Shimbo, A., Kawamura, S.: Formal security model of multisignatures. In: Katsikas, S.K., Lopez, J., Backes, M., Gritzalis, S., Preneel, B. (eds.) ISC 2006: 9th International Conference on Information Security. Lecture Notes in Computer Science, vol. 4176, pp. 146–160. Springer, Heidelberg, Germany, Samos Island, Greece (Aug 30 – Sep 2, 2006)
  30. Le, D.P., Bonnecaze, A., Gabillon, A.: Multisignatures as secure as the DiffieHellman problem in the plain public-key model. In: Shacham, H., Waters, B. (eds.) PAIRING 2009: 3rd International Conference on Pairing-based Cryptography. Lecture Notes in Computer Science, vol. 5671, pp. 35–51. Springer, Heidelberg, Germany, Palo Alto, CA, USA (Aug 12–14, 2009)
  31. Li, C.M., Hwang, T., Lee, N.Y.: Threshold-multisignature schemes where suspected forgery implies traceability of adversarial shareholders. In: Santis, A.D. (ed.) Advances in Cryptology – EUROCRYPT’94. Lecture Notes in Computer Science, vol. 950, pp. 194–204. Springer, Heidelberg, Germany, Perugia, Italy (May 9–12, 1995)
  32. Lu, S., Ostrovsky, R., Sahai, A., Shacham, H., Waters, B.: Sequential aggregate signatures and multisignatures without random oracles. In: Vaudenay, S. (ed.) Advances in Cryptology – EUROCRYPT 2006. Lecture Notes in Computer Science, vol. 4004, pp. 465–485. Springer, Heidelberg, Germany, St. Petersburg, Russia (May 28 – Jun 1, 2006)
  33. Lysyanskaya, A., Micali, S., Reyzin, L., Shacham, H.: Sequential aggregate signatures from trapdoor permutations. In: Cachin, C., Camenisch, J. (eds.) Advances in Cryptology – EUROCRYPT 2004. Lecture Notes in Computer Science, vol. 3027, pp. 74–90. Springer, Heidelberg, Germany, Interlaken, Switzerland (May 2–6, 2004)
  34. Ma, C., Weng, J., Li, Y., Deng, R.: Efficient discrete logarithm based multisignature scheme in the plain public key model. Designs, Codes and Cryptography 54(2), 121–133 (2010)
  35. Maxwell, G., Poelstra, A., Seurin, Y., Wuille, P.: Simple schnorr multi-signatures with applications to bitcoin. Cryptology ePrint Archive, Report 2018/068 (2018), https://eprint.iacr.org/2018/068/20180118:124757
  36. Maxwell, G., Poelstra, A., Seurin, Y., Wuille, P.: Simple schnorr multi-signatures with applications to bitcoin. Cryptology ePrint Archive, Report 2018/068 (2018), https://eprint.iacr.org/2018/068/20180520:191909
  37. Merkle, R.C.: A digital signature based on a conventional encryption function. In: Pomerance, C. (ed.) Advances in Cryptology – CRYPTO’87. Lecture Notes in Computer Science, vol. 293, pp. 369–378. Springer, Heidelberg, Germany, Santa Barbara, CA, USA (Aug 16–20, 1988)
  38. Micali, S., Ohta, K., Reyzin, L.: Accountable-subgroup multisignatures: Extended abstract. In: ACM CCS 01: 8th Conference on Computer and Communications Security. pp. 245–254. ACM Press, Philadelphia, PA, USA (Nov 5–8, 2001)
  39. Michels, M., Horster, P.: On the risk of disruption in several multiparty signature schemes. In: International Conference on the Theory and Application of Cryptology and Information Security. pp. 334–345. Springer (1996)
  40. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008), http://bitcoin.org/bitcoin.pdf
  41. Neven, G.: Efficient sequential aggregate signed data. In: Smart, N.P. (ed.) Advances in Cryptology – EUROCRYPT 2008. Lecture Notes in Computer Science, vol. 4965, pp. 52–69. Springer, Heidelberg, Germany, Istanbul, Turkey (Apr 13–17, 2008)
  42. Ohta, K., Okamoto, T.: A digital multisignature scheme based on the Fiat-Shamir scheme. In: Imai, H., Rivest, R.L., Matsumoto, T. (eds.) Advances in Cryptology – ASIACRYPT’91. Lecture Notes in Computer Science, vol. 739, pp. 139–148. Springer, Heidelberg, Germany, Fujiyoshida, Japan (Nov 11–14, 1993)
  43. Ohta, K., Okamoto, T.: Multi-signature schemes secure against active insider attacks. IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences 82(1), 21–31 (1999)
  44. Okamoto, T.: Provably secure and practical identification schemes and corresponding signature schemes. In: Brickell, E.F. (ed.) Advances in Cryptology – CRYPTO’92. Lecture Notes in Computer Science, vol. 740, pp. 31–53. Springer, Heidelberg, Germany, Santa Barbara, CA, USA (Aug 16–20, 1993)
  45. Park, S., Park, S., Kim, K., Won, D.: Two efficient RSA multisignature schemes. In: Han, Y., Okamoto, T., Qing, S. (eds.) ICICS 97: 1st International Conference on Information and Communication Security. Lecture Notes in Computer Science, vol. 1334, pp. 217–222. Springer, Heidelberg, Germany, Beijing, China (Nov 11–14, 1997)
  46. Pointcheval, D., Stern, J.: Security arguments for digital signatures and blind signatures. Journal of Cryptology 13(3), 361–396 (2000)
  47. Ristenpart, T., Yilek, S.: The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks. In: Naor, M. (ed.) Advances in Cryptology – EUROCRYPT 2007. Lecture Notes in Computer Science, vol. 4515, pp. 228–245. Springer, Heidelberg, Germany, Barcelona, Spain (May 20–24, 2007)
  48. Schnorr, C.P.: Efficient signature generation by smart cards. Journal of Cryptology 4(3), 161–174 (1991)
  49. Scott, M., Benger, N., Charlemagne, M., Perez, L.J.D., Kachisa, E.J.: Fast hashing to g2 on pairing-friendly curves. In: Shacham, H., Waters, B. (eds.) PAIRING 2009: 3rd International Conference on Pairing-based Cryptography. Lecture Notes in Computer Science, vol. 5671, pp. 102–113. Springer, Heidelberg, Germany, Palo Alto, CA, USA (Aug 12–14, 2009)
submitted by dj-gutz to myrXiv [link] [comments]

[uncensored-r/Bitcoin] Finally! Real privacy for Bitcoin transactions from some Core developers

The following post by fortunative is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ Bitcoin/comments/7d5zbc
The original post's content was as follows:
Greg Maxwell made a VERY exciting announcement for some real cutting edge stuff: a way to get full privacy with transactions in Bitcoin!
The great thing about this is, unlike ZCash, this new method:
  • Doesn't use untested new cryptography
  • Can be high performance (compared to alternatives)
  • Doesn't require a trusted setup
  • Doesn't break pruning
There is a video here that describes confidential transactions in more detail. But the exciting announcement today is a way to make confidential transactions work with a size overhead only 3 times that of normal transactions. When combined with the further privacy improvement of CoinJoin or ValueShuffle, there is virtually no size overhead and no trusted third party or sharing of private data is required!
Thank you Greg, Pieter, and other Core team contributors for this excellent work on confidential transactions, coinjoin, and working on the theory and engineering to bring this to Bitcoin! Exciting developments! Thanks also Benedikt Bünz, Jonathan Bootle for your discovery of BulletProofs and Dan Boneh, Andrew Poelstra for your work on this.
Update: As pwuille pointed out, while the size overhead is 3X (or less per transaction w/ coinjoin), the CPU overhead for verification is still an order of magnitude higher than regular transactions. But we'll know more once they start working on an implementation.
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

Progress On Hardfork Proposals Following The Segwit Blocksize Increase | Peter Todd | Aug 05 2016

Peter Todd on Aug 05 2016:
Repost by request from my blog, apologies for the somewhat screwy formatting!
layout: post
title: "Progress On Hardfork Proposals Following The Segwit Blocksize Increase"
date: 2016-08-05
tags:
With segwit getting close to its initial testnet release in Bitcoin Core
v0.13.0 - expected to be followed soon by a mainnet release in Bitcoin Core
v0.13.1 - I thought it'd be a good idea to go over work being done on a
potential hard-fork to follow it, should the Bitcoin community decide to accept
the segwit proposal.
First of all, to recap, in addition to many other improvements such as fixing
transaction malleability, fixing the large transaction signature verification
DoS attack, providing a better way to upgrade the scripting system in the
future, etc. segwit increases the maximum blocksize to 4MB. However, because
it's a soft-fork - a backwards compatible change to the protocol - only witness
(signature) data can take advantage of this blocksize increase; non-witness
data is still limited to 1MB total per block. With current transaction patterns
it's expected that blocks post-segwit won't use all 4MB of serialized data
allowed by the post-segwit maximum blocksize limit.
Secondly, there's two potential upgrades to the Bitcoin protocol that will
further reduce the amount of witness data most transactions need: [Schnorr
signatures](https://bitcoinmagazine.com/articles/the-power-of-schnorr-the-signature-algorithm-to-increase-bitcoin-s-scale-and-privacy-1460642496) and BLS aggregate signatures.
Basically, both these improvements allow multiple signatures to be combined,
the former on a per-transaction level, and the latter on a per-block level.
Last February
some of the mining community and some of the developer community got together to discuss potential
hard-forks, with the aim of coming up with a reasonable proposal to take to the
wider community for further discussion and consensus building. Let's look at
where that effort has lead.

Ethereum: Lessons to be learned

But first, Ethereum. Or as some have quipped, the Etherea:
The Battle for Etherea. https://t.co/2ATQRQRXnH">https://t.co/2ATQRQRXnH— Samson Mow (@Excellion) https://twitter.com/Excellion/status/759677608753627136">July 31, 2016
If you've been following the crypto-currency space at all recently, you
probably know that the Ethereum community has split in two following a very
controversial hard-fork to the Ethereum protocol, To make a long story short, a
unintended feature in a smart-contract called "The DAO" was exploited by a
as-yet-unknown individual to drain around $50 million worth of the Ethereum
currency from the contract. While "white-hat attackers" did manage to recover a
majority of the funds in the DAO, a hard-fork was proposed to rewrite the
Ethereum ledger to recover all funds - an action that many, including myself,
have described as a bailout.
The result has been a big mess. This isn't the place to talk about all the
drama that's followed in depth, but I think it's fair to say that the Ethereum
community found out the hard way that just because you give a new protocol the
same name as an existing protocol, that doesn't force everyone to use it. As of
writing, what a month ago was called "Ethereum" - Ethereum Classic - has 20% of
the hashing power as the bailout chain, and peaked only two or three days ago
at around 30%. As for market cap, while the combined total for the two chains
is similar to the one chain pre-fork, this is likely misleading: there's
probably a lot of coins on both chains that aren't actually accessible and
don't represent liquid assets on the market. Instead, there's a good chance a
significant amount of value has been lost.
In particular, both chains have suffered significantly from transaction replay
issues. Basically, due to the way the Ethereum protocol is designed - in
particular the fact that Ethereum isn't based on a UTXO model - when the
Ethereum chain split transactions on one chain were very often valid on another
chain. Both attacks and accidents can lead to transactions from one chain
ending up broadcast to others, leading to unintentional spends. This wasn't an
unexpected problem:
.https://twitter.com/petertoddbtc">@petertoddbtc we knew it would happen weeks before launch, we didn't want to implement replay-protection b.c. of implementation complexity— Vlad Zamfir (@VladZamfir) https://twitter.com/VladZamfistatus/759552287157133313">July 31, 2016
...and it's lead to costly losses. Among others Coinbase has lost [an unknown amount of
funds](https://twitter.com/eiaine/status/758560296017416194) that they may have to buy back. Even worse, BTC-e lost pretty much their entire balance
of original Ethereum coins - apparently becoming insolvent - and instead of
returning customer funds, they decided to declare the original Ethereum chain a scam instead.
A particularly scary thing about this kind of problem is that it can lead to
artificial demand for a chain that would otherwise die: for all we know
Coinbase has been scrambling behind the scenes to buy replacement ether to make
up for the ether that it lost due to replay issues.
More generally, the fact that the community split shows the difficulty - and
unpredictability - of achieving consensus, maintaining consensus, and
measuring consensus. For instance, while the Ethereum community did do a coin
vote as I suggested, turnout was extremely
low - around 5% - with a significant minority in opposition (and note that
exchanges' coins were blacklisted from the vote due to technical reasons).
Additionally, the miner vote also had low turnout, and again, significant
minority opposition.
With regard to drama resulting
from a coin split, something I think not many in the technical community had
considered, is that exchanges can have perverse incentives to encourage it. The
split resulted in significant trading volume on the pre-fork, status quo,
Ethereum chain, which of course is very profitable for exchanges. The second
exchange to list the status-quo chain was Poloniex, who have over 100
Bitcoin-denominated markets for a very wide variety of niche currencies - their
business is normally niche currencies that don't necessarily have wide appeal.
Finally, keep in mind that while this has been bad for Ethereum, it'd be even
worse for Bitcoin: unlike Ethereum, Bitcoin actually has non-trivial usage in
commerce, by users who aren't necessarily keeping up to date with the latest
dramaHHHHH news. We need to proceed carefully with any
non-backwards-compatible changes if we're to keep those users informed, and
protect them from sending and receiving coins on chains that they didn't mean
too.

Splitting Safely

So how can we split safely? Luke Dashjr has written both a
BIP, and
preliminary code
to do a combination of a hard-fork, and a soft-fork.
This isn't a new idea, in fact Luke posted it
to the bitcoin-dev mailing list last February, and it's been known as an option
for years prior; I personally mentioned it on this blog last January.
The idea is basically that we do a hard-fork - an incompatible rule change - by
"wrapping" it in a soft-fork so that all nodes are forced to choose one chain
or the other. The new soft-forked rule-set is simple: no transactions are
allowed at all. Assuming that a majority of hashing power chooses to adopt the
fork, nodes that haven't made a decision are essentially 51% attacked and will
follow an empty chain, unable to make any transactions at all.
For those who choose not to adopt the hard-fork, they need to themselves do a
hard-fork to continue transacting. This can be as simple as blacklisting the
block where the two sides diverged, or something more complex like a
proof-of-work change.
On the plus side, Luke's proposal maximizes safety in many respects: so long as
a majority of hashing power adopts the fork no-one will accidentally accept
funds from a chain that they didn't intend too.

Giving Everyone A Voice

It's notable that what Luke calls a "soft-hardfork" has also been called a
"forced soft-fork" by myself, as well as an "evil fork" by many others - what
name you give it is a matter of perspective. From a technical point of view,
the idea is a 51% attack against those who choose not to support the new
protocol; it's notable that when I pointed this out to some miners they were
very concerned about the precedent this could set if done badly.
Interestingly, due to implementation details Ethereum hard-fork was similar to
Luke's suggestion: pre-fork Ethereum clients would generally fail to start due
to an implementation flaw - in most cases - so everyone was forced to get new
software. Yet, Ethereum still split into two economically distinct coins.
This shows that attempting to k...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/012936.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Provisions: how Bitcoin exchanges can prove their solvency

It has long been a goal of the Bitcoin community for exchanges to be able to cryptographically prove solvency—that is, to prove that they still control enough bitcoins to cover all of their customers’ accounts. Greg Maxwell first proposed an approach using Merkle trees in 2013, but this requires revealing (at a minimum) the total value of the exchange’s assets and which addresses the exchange controls. Exchanges have specifically cited these privacy risks as a reason they have not deployed proofs of solvency, relying on trusted audit instead.
In a new paper presented this month at CCS (co-authored with Gaby G. Dagher, Benedikt Bünz, Jeremy Clark and Dan Boneh), we present Provisions, the first cryptographic proof-of-solvency with strong privacy guarantees. Our protocol is suitable for Bitcoin but would work for most other cryptocurrencies (e.g. Litecoin, Ethereum). Our protocol hides the total assets and liabilities of the exchange, proving only that assets are strictly greater than liabilities. If desired, the value of this surplus can be proven. Provisions also hides all customer balances and hides which Bitcoin addresses the bank controls within a configurable anonymity set of other addresses on the block chain. The proofs are large, but reasonable to compute on a daily basis (in the tens of GB for a large exchange, computable in about an hour). Best of all, it is very simple and fast for each user to verify that they have been correctly included. We can even extend the protocol to prevent collusion between exchanges. The details are in the paper, the full version of which is now online.
https://freedom-to-tinker.com/blog/jbonneau/provisions-how-bitcoin-exchanges-can-prove-their-solvency/
submitted by packetinspector to BitcoinMarkets [link] [comments]

Scaling Bitcoin 2018 Stanford Webinar - The Future of Bitcoin and Cyber Security The Bitcoin Craze Has Officially Hit College Campuses  CNBC ANALYSIS OF BITCOIN AND BLOKCHAIN - P4 Bitcoin CRASH HAS ONLY JUST BEGUN?! -LIVE Crypto Trading Analysis & BTC Cryptocurrency Price News

A group of crypto startups and organizations are sponsoring a new blockchain research center headquartered at Stanford University. The Center for Blockchain Research is being led by Dan Boneh and Professor Dan Boneh. Coursera boasts nearly thirty million registered users and two thousand different courses in a dozen languages. News.bitcoin.com registered for Professor Boneh’s Cryptography I course, and found two immediate options: 79.00 USD would earn participants a certificate, along with educational feedback, while the free option Guests: Dan Boneh. Cryptography is an indispensable tool for protecting information in computer systems. This week we speak with Dan Boneh who teaches a course, on applied cryptography and computer security at Stanford University, about learning the inner workings of cryptographic systems and how to correctly use them in real-world applications. Banks Accepting Bitcoin - Bitcoin Dan Boneh Banks Accepting Bitcoin The Truth About Bitcoins Related To The Bible Bitcoin Fad And Price Banks Accepting Bitcoin Bitcoin 2013 News Fees Bitcoin Use China. Banks Accepting Bitcoin Bitcoin Saudi Arabia Gold Silver Backed. The Bitcoin Podcast #214: Dan Boneh. Episode 214. July 22, 2018 — 86 mins. Guests: Dan Boneh. Cryptography is an indispensable tool for protecting information in computer systems. This week we speak with Dan Boneh who teaches a course, on applied cryptography and computer security at Stanford University, about learning the inner workings of

[index] [25676] [22585] [17037] [1413] [30077] [20127] [10156] [24320] [26540] [23067]

Scaling Bitcoin 2018 "Kaizen" Day 1 Part 3

In this webinar, Stanford Professor Dan Boneh discusses recent developments in crypto currency and computer security. From writing secure code to applications of the blockchain, you will uncover ... LIVE BITCOIN ANALYSIS - Plus ETH and LTC - Also Any chart Any Market Jim of All Trades 190 watching Live now Chamath Palihapitiya interview: Bitcoin Halving, Stock news, BTC 2020, Crisis Chamath ... Dan Boneh, co-director of the Stanford Computer Security Lab, said cryptography classes are red hot. » Subscribe to CNBC: http://cnb.cx/SubscribeCNBC About C... I registered to attend Consensus Distributed virtually , and really enjoyed some of the sessions. I really feel that this is an awesome time for the blockchain space, the most exciting since 2017 ... These are only my own personal opinions, ideas, speculative hypotheses, charts, technical analysis (TA), insights, curated news publications and price prediction(s) for 2019 and beyond.

Flag Counter