Re: [Bitcoin-development] Lost proposals from FellowTraveler/Monetas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-16 23:32, Gregory Maxwell wrote: > Is there any discussion thats been had relating to the BIP-drafts at: > > https://github.com/Open-Transactions/rfc/tree/master/bips > > Fellow Traveler has apparently been waiting 9 months for progress on > these proposals and I'm trying to find out where the breakdown > happened. While do not doubt that I am somehow at fault, I can't > figure out how. > > Searching my email and this list archive for "Base58 Serialization for > Transaction-Based Color Descriptors" or "Order-based Smart Property > Coloring" or the draft names bip-ccids, etc. turn up no hits at all. > I've asked several other people and there list archives show nothing. The only two proposals we sent to the mailing list were attached to this post: http://sourceforge.net/p/bitcoin/mailman/message/32736455/ The rest of the proposals in that respository, as well as those the fork here: https://github.com/Monetas/rfc/tree/master/bips were never submitted because we decided to use alternative identifiers in leiu of BIP numbers to serve as the purpose code in the HD path. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVgLRaAAoJECpf2nDq2eYjw7YQAJYrciEZZeasEJRR7XwZ5AWQ 9e/pz1SV2hoRs7TqHgHoXGINLbG9LwlXFmnoG14z+vwKvheJxlC6gOQCRIRwPfrR zwuQWyoONHn82XL44ABqjnu0fmeh7egx3FIzsgDUxUgiP5dA0BuQvrT1+DptfJ+p 5sM7ZvRqfZJbek4AHk9Y4kERQYsP4HKgC1W3Acr1In9WPSj5TRtYz7tUK+SFcO+m A3Ny5dUiAmmf5mfLZiWrEmCG34n+cCJZEU2hlQqH5ZuAHPmeTLuar91MLj/1Xltf OFlMGhmUPy1alTx8o39nwRjfXIVQLk7/D5YB3gB2CUuXd+sWbY+6LUyniOKtQK3C EmEDOUFSNm4JV1AmM+ea1HUufCJfkg1VHko4hsIyc1e7ztdECIzPQKAy7DAcu1YS BhbkxNyaUqoF+J/ggrXhT/r5oVpWsifdj4IEzaMvmOxu+p+hTkzzwitLuyknEBZE b2KWRMWNOheVpDp7RmrcTPqa4S1N8XcfJazDyigIhl0E/Bjk+pC1SHo7IIEMZMQ+ Fz7JaALd8XK0l7HBvvJnZmYwVLnQyB01B6n7z8eTTAneHhSXxa7Z1aFTkYU8Wp9o L5nb1K7gJtjBFqhLi3PMLRhARao1Q/CK5bDt9Mb3VMy9jAIr9X9/NcL473cbHtQH /h91bhkL9bvvkeCl5yQk =NgfK -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVWmA1AAoJECpf2nDq2eYjXGgP/2CpIYpG49WKAfG/PXmu1zFV +zzU/7PCz+0ez0mGCz5l3QMc9TCDs6KDx0sPHZngwwLio3C4JMpu+zfnw6gngw/G 6NNtmDZ9xWgWx3kQyBLWBCM/K63rLE1QYJqiIc7QaDuDTk5w0upwkFxLejWeem1j Z8Zy6ycHNNHE19o5pIYViWaRXojMD70fBFSoU9sAyvnOup7b5Cj4PLx7mbMbaegV gCHd7zd88AH0f2ilFiVMQJBKf03KzYjarRVrAyvAb/8VLiYMRC8SS3y2tzM+qRKl ZADAp8FiQ6GOFRssNg+x7tc3DX2ngBljLLKM90kPLR2cvwp8VHi0I0biqM8n2M17 CMjZVRNvXitNnKFc42nk51HsZR5LkDK3Rf9I1E3fBVKJ5feEbDi3tlEg9PCWD2xM PmSRzXoUBAjpr9xL2kBzlE4aTYZCmmMxAMF1mcSYujdNzQ2IN0gD1urJtCwZ8zZ1 LL2cPimS3GTWEpoQQ/Fu+0NDwiPditDGt+DN16Mi5uioPvaumHMIV6u9ZNdD9ZEv UTGW8C2Hj+ENzqhpdhlV5YfYUnKo6/ukw+xxTXRxbbLGxA6iRrVnPzsYTZoF0Vrt T4IsdzPIg5yeF5IQKEV1lLyx+gOIvmDF1RZE36NY8bGn2zusFzUGxiqWa6yw0hfw l4ytd8pfhIvTkuz1o9aQ =kWhU -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVWhBvAAoJECpf2nDq2eYj3JEP/jw/Xkgq4yZRE4FK8a8kPBqn 3ULyS74KtNyPDdpTK0bdH7//0d1ep+LvNpIkFhWCJ/WQ7T/Ft3iQl1HJvXGC0ZzM XKd7ptXLpBrKElARAORgUlFPOeKzOrOyP4uvvGAMZ+CXEnKeyxDzK+WzfYnWyDEU Q4XQ/ndwPqbZm9Nb+GeF186TXcA/KqcQEuOIw7/jFGHfFT6QBKVz1SraVrgdcMky 8KKYOsYJt8lTUjVN1INmLFoRZ0cGUd+IFKweSCibyAu9TdvVQfQSPfSnfZtDLk6X g1oPYaxX6r9+/1zm2v5ISk97nKrvNslPjeQbuW3vWlROSxGZ9lV+MVNvkqm1jSpF ip0Il+VJb8hhh9LRJV6euhLQyR+xnLIVJvslJt883rhKIBi3M/OipMuhipIeAbnV 0WQmnpQ9ZgagPoFRxGp86Cz7PWTfj7zllB3yk/M3tA8e64VQFhEnoyJO8hPqfEQh wPZP3UQ+K3PM/2oe4W5ZkfkqD6tIzGTQeMkGFeCvTsMmsW9+Ml8j4YTwKA0z5vr5 IebJ51Vpaq1noVEl46q8utpLp1wATI8SG5sBwSaR4/REUGkSWjSCeZeLcK8WzdEa SaZ8t5Rqr1AcwtD6n9rVvYoF26285120jM/YX8XgMldWi0RXrlWD4B4lA1i7eVfZ hINSIR+QsJsw7yq7Ox3/ =NMNo -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2015 02:02 PM, Andrew wrote: > The nice thing about 1 MB is that you can store ALL bitcoin > transactions relevant to your lifetime (~100 years) on one 5 TB > hard drive (1*6*24*365*100=5256000). Any regular person can run a > full node and store this 5 TB hard drive easily at their home. With > 10 MB blocks you need a 50 TB drive just for your bitcoin > transactions! This is not doable for most regular people due to > space and monetary constraints. Being able to review all > transactions relevant to your lifetime is one of the key important > properties of Bitcoin. How else can people audit the financial > transactions of companies and governments that are using the > Bitcoin blockchain? How else can we achieve this level of > transparency that is essential to keeping corrupt > governments/companies in check? How else can we keep track of our > own personal transactions without relying on others to keep track > of them for us? As time passes, storage technology may increase, > but so may human life expectancy. So yes, in this sense, 1 MB just > may be the magic number. How many individuals and companies do you propose will ever use Bitcoin (order of magnitude estimates are fine) Whatever number you select above, please describe approximately how many lifetime Bitcoin transactions each individual and company will be capable of performing with a 1 MB block size limit. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVTgNcAAoJECpf2nDq2eYjM8AP/2kwSF+HMPR1KdaZsATL4rog xSS97Q5iEX8StA61jUqHQmpXL5pG6z5DeeKT/liwcMnYnVqOEOLvoVctr3gXfgRz 9GJeTOlmN5l9xBeX/nWa0A2ql0kWZpYolBS1FwYadWReAD8R0X9UeBd9YXLZNy33 Ow9JjwRjKHhsuyrlMP8pRDKlGPoa/U+2aW4FwiysMLa0Gu6dbFjTrp3bHw4Fccpi X0E/aDN68U4FV+lZ4NzkMsBK9VARzmC8KI0DQ540pqfkcnyoYf0VERl/gslPWhfq t6Rqa7vHHMqFe82lgCd3ji8Qhsz8oBrDS4u4jqwATvgihgImOB6K85JoKmf3y2JS jByjMGd4Ep0F80Z2MRhi6HuEoRU69uY2u6l9bZxMjzvLX8sG6QTNk3uLMS3ARXcY JBjZ/g13DXgcRj01fq05CHbCTJYZgTA9pRZTY+ZKH4r0mu86b9ua7hjvyKHS6q54 uaFmRkNcnKlpCY+fvH/JUdvvmwrA0ETUdHhRyk8vzWIMi+aH4//GwrCmBNRrugzv 9JtQ1BC+tQqtSX2VkFEhAVISitgkBqurVVlGk18FvVKPFO8cnFS/6NWoPE0WLLzW 2pTuhEPjdz9UAHD3RW601rb4C0LbuwVlGO4tYBjyqCmk/vBlES2XIjQKctXZLBEy eLgn3gMwEXUTU6UdGyvb =RPhK -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 09:54 PM, Jeff Garzik wrote: > By the time we get to fee pressure, in your scenario, our network > node count is tiny and highly centralized. Again, this assertion requires proof. Simply saying things is not the same as them being true. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVS8QWAAoJECpf2nDq2eYj+/4P/2JXxo2RDAg0ptd9aUYVvzp9 KhL33cdmK8kbKBFOVcOuIrlQRzZn9iydIPC165Y40Y6Wrtgw2PoXctuqdQdXaSZI M3bHuM7mweHyb3xBHNaNHIxfwrMjQQAdOTGO7PZusghDYz2QEj44dhIcNOzO7uTD fXkhzgJfwu0l0Wqn3v/R9amRUWLE5nlM566xJ2sVtlfBMEyzR5L1GwX1lKNhxeO8 qvkgegsF2Usjz9pIUMSGFxSWZQuTSjHbhbh28JaT/wi6DI3pcTV0FPw95IPImqUh rbIqcPh43omXrHKEHV/FB+XMItD3VvR9dxogYaFZLv1EU2gnF2IM0cw5a/oyHr+L C920uEbXrvrMEJw1ftvxQyu6NY5c3/5iVMqz773oQSjOihkZ8P1JvxQnldU6mcoU RaKM13cxgjSkCqJ5R1iIldFQPCLLWUKJDkPEnGlwdLPF/vwhnCt1PZJTB5hqoCgC ab5yBVLpLgo7sbizOeX/R3WGp3NjGXDQC93Af/Vr37uiu1ZT+1P1Ow86hsZTRx6b 4d25tSGg7Tw3Bs/YOhJ9AKtlN092Y8/WBMscQu6MaFt6I/1OMX9OVH+veEj/VjwB L/dxWTRdC0HEKiYv+EuESIRoyTLlCHKBUDBgKbYSMjetg6WW64hYrpxNX7TH20o6 00bWPVV2PcEWuCc230UF =1bK6 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:35 PM, Jeff Garzik wrote: > Raising the block size limit then becomes a *human decision* to > favor some users over others, a *human decision* to prevent an > active and competitive free fee market developing at 1MB, a *human > decision* to keep transaction fees low to incentivize bitcoin > adoption, a *human decision* to value adoption over > decentralization. At the moment none of the following assertions have been proven true, yet are constantly cited as if they have been: * A competitive fee market will develop when the transaction rate becomes constrained by the block size limit * More users of Bitcoin means less decentralization Furthermore, the term "decentralization" is frequently used without being precisely defined in a way that would allow for such proofs to be debated. If there's going to be a debate on those points, then the people presenting points on both sides should take the time to show their work and explain the methodology they used to reach their conclusions. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVS5BXAAoJECpf2nDq2eYjC3kQAKQ0Jj8r1gjwpl813NiuatjA nwXJ+Zn7E+cS8bYsXbaPK1uUgcSdpi/g2jgW+VuUPlqCaNo08Pbp/O7pG5ady9st o7xJnPxttg7NO3IB7GODCJKK85uBO3dOwPp+pfs8KYCAo5PFTflpeOi4Idbd4w/R +tvLynpSX9LIZTQaJH2KEbrYUibYHZrr8hj0net9lJP8KeqMnCuiesYzjJ4pUXyE zN0SQ1v9QnpltbTVxRu1TdRBMjAxEHTJPg1jsv0hhGqIOQGHdwNavGq7+LJBen4T CvT8ooTmuq0IdihOTttl9ody6Eh0tyGPlbVHiI3c2Emm0HTxz8hN9Rl4lvPgcGdi EUW12h8ailKLg5uJL53Zp1PO6fgl0Z/WCx/zqIKRPg4lJMf5Rk5Ow86xAeIZrsbr d/+cJZEhqzPnObxkxgTIzqtG8NHcg9dhKw1xkGAkVpMXMM7Bzdku8WCntIYU4+xI btQQZlbc5h/S+X9Vcu0rJWmmQp2Q8xeEVGRh4hhA8LZLc1P+1eyESjAMWvsuq+rk Wd1kPopekhOgK0zw2j55Ov+kJXVa2pDFA7TOpcqxbdLU4eauKC4D+YQlTM4qj285 vyRq+c/AwMCPiEhBeEbppgdgwrIQP9fJ7s+2TAHaWICYlTJWkLitUjN9EBwqv3Yp LRBrgV7giz8UIrJr3hQZ =+Qmg -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 05:47 PM, Jeff Garzik wrote: > Bitcoin needs to be the best it can be (Layer 1), but all solutions > cannot and should not be implemented at Layer 1. I can provisionally agree with that statement as long as "all solutions cannot and should not be implemented at Layer 1" it taken to be a hypothesis to be tested in the context of each proposed solution rather than a law of nature. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVS4nOAAoJECpf2nDq2eYjZGEP/jvk+RNQO+Zoyp0jc6aup5Aa USUFk1TYBqbu47vvc3jFHc4V3/BjiwkUKp5bZ4iIxr3xWIA35CcjfpSJEIlEj0zM OHS2j+eS0WkNWCmWgj+3sJpQBNnqLmdBOG1q6z0aBLGwG7uabo+YAhJjlP8isfcn cBQPGjeTW82ZZLdkNaThbFr53oTYiVPNqMIIq6orUe5vetQS/zfTyowi7Y9+OT+b FMXOEmXQTzF415LImJNXOcGFx51YkLe3SuEPEqqIX/+gOcT4HMPuKbqyAu6xXRQK O7uI+6AjN1mX7Cvt19wYkUggJ7ddVKrHINSzOfsZ+pdF8mdY4TrdwJJhfN0+fnvo KYW+pmEAFRMveV8SVGJpHQ/pWECKbFiz1SRnDfjlbX/C5mHiHM4EmqCxC1pVDxOU uDukt+ZIIiP7GwPYxqSknR4lcuwsdFFJf9ldxD+ZRNsmz1l+PkaUUpdkCc9u9rUW 2IyfvPmeeVUPLP9N675kfiM3aKNO7LHN8GhSUe+1Nt/zcXg6xg0QWKdXjC8nykCa eH9gn0QoQZaZbfKnb8DLwLjCO5LiOzQTgqdo0ZSJtV/CipqyGcBJtFYW2olG/BvO Ns6qJKG6Ck76Tv31cu3YGpVbBjCxsIovchLh72KjQ9LscYg8y29evcFlnyagsewY 5CQJsAY8apmvNvmxAhRf =oRV/ -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:27 PM, Jeff Garzik wrote: > On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier > wrote: > >> To be extremely specific: should Bitcoin development >> intenionally limit the network's capabilities to leave room for >> other projects, or should Bitcoin attempt to be the best system >> possible and let the other projects try to keep up as best they >> can? >> > > > Avoid such narrow, binary thinking. On 05/07/2015 03:25 PM, Peter Todd wrote: > Altcoins and non-Bitcoin-blockchain tx systems? Assuming anything > other than honest intent isn't productive in this forum. > In summary, I asked a question neither you, nor Peter Todd, want to answer and want to actively discourage people from even asking at all. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVS4XZAAoJECpf2nDq2eYjwZcP/j4ypIBctC4Wt71KJCx4eJ3u u8DQAJKKr8BfL/zDu5bwVz0qbIX1+Wv9EwkBSYuYQaLDozDCnlttptr7qNWm62QI d5Z6HUU+g/Zbk2DSgVK57Hf3G7pzcodRq+fp6O/kNgtdE9OyZnv9giApd6F1Yy7l wgZxjlpKGMA+qKigHSHIQyu1L2JfWjw7eEiirnDtFaCgTpJqPErigX+2eMdpj8/r jTP3mEN2qStWYydWfYxfcM68gOZsvFiVBfT7qTkFXSeOdigC4bHMDMew9nqP1hlB 9uo/JESNQ4Z0/WHgDSn9fLbc/UX6SIPVn7vDAj7mZAeyaXYBrXhbHpdqhnOGhDmt R9aUopGHleY44RujES1rQWSo6D8SWlbmpXThgHU5rlRFKKSCu9/s99s7kVdLFqpS bGg42qs1LwxDiq2TuMV/9TuP10ibB4mSnKwaglcAHcrbo26ZdMF4T9YwKcEmHIrv 0hCUA0qyvKP3fqfQUVzcssJfWdvjx7/bnwLadrxSOur1IZj+2jJdzPYsT1tSiwL/ XChSN5a00LJWW5+b0ka155sEg8XcBdUECXIQtRpFedCURjeinGuMnEf6gM8NbcNS yVm5Kptf8BO11r154J93nkc3gU4VFcxudg8smaDcq3amPDkyaNBXQm+rcwIApchL SOzHWwxtA1q+pLHvxnlk =Fcdg -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 05:04 PM, Jeff Garzik wrote: > heh - I tend to think people here want bitcoin to succeed. My > statement refers to picking winners and losers from within the > existing bitcoin community & stakeholders. "Success" is not a sufficiently precise term in this context. There is a large contingent of people for whom the definition of Bitcoin "success" means serving as a stable backend which can meet the needs of their non-Bitcoin platform - and nothing more. To be extremely specific: should Bitcoin development intenionally limit the network's capabilities to leave room for other projects, or should Bitcoin attempt to be the best system possible and let the other projects try to keep up as best they can? -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVS4HiAAoJECpf2nDq2eYj23wP/j4ksm2dgzDkccMRbqFM8Pm8 oV6ImxM26bG3DJB+Rh6ttTY4DrUnZJmzQUUxfZUd3TmH/xOM4Lu35gKKhpvHTdR8 vMQz76CaTba6PzzFKC+GYyHueXLtwJxEHEZjR8m5ijPMfZoImfMbduggDaPLv/sz AUcTDtYWBoPZ9Matms4NZIOsH1S1pHw5YjcFYgxmY6ErHZPqZjoKzcc4wZnrOU+Q HCmiHOJ1U87jEge4QEJCXidCJFakyMTWt5P6hjdOFfky3VYmcoivYRA1ZemgyV2Y YyLtmHBcK7k67Tczep8rjggvK2C2oJArFGPLWHZH9bxXILaNXSpZX5G5rXZjp1vm 1voc6JDaK/slXIlfG+BZ56WyprKkiFbN6u4Wd8LG5W8gKiuCyLYr2IGKz9O3fvor NYtk6ELPfX1+0JBD0ureI7kV85D/ybNnnmMp/NyfmBKzzmqnANRrrqL5zgILuUP4 YaokcVdPpTqkN0vuAXchehEemF5MtJIYf9BayZ86ck68aMjvVJi0nX3n63f1MulP IbRbYY/8eu1891lNIPiSzbmT0zjjplo8jYEOTg32mIvEDZAy8sWwTPYS25tPd37l 3kxRCxqS1ALbAqLZprmxQ375PigE2esXZlpBHzyY4Kf+3UD/k/X8D92vdNiF7mkS HSA+TX4lf310Eq6Mb4LR =5vaU -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 04:49 PM, Peter Todd wrote: > > I think we'll find an basic assumption of civility to be more > productive, until proven otherwise. (e.g. NSA ties) I'm not sure why you'd construe my post as having anything to do with accusations like NSA ties. By "non-Bitcoin" projects I mean any altcoin or off-chain processing solution. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVS4EeAAoJECpf2nDq2eYj/vcQAIUrD+ejUKHQb0k/pcPyzmvy rl3spbbdLSFN9cBhBOgh5LaVFkCrv4/gW2X4Ih6GGYG3siXjZ2HPDXt+Zbs+bfQE nrw+IpGTYlbnJ26cFVhZWehr45qY1kMO+DVdnKufEgfVKUdYeq/d3bwL1uru4RU6 UfWihvgGGQkjEb/5ZIpRbWmb7XRP9piZCHi0pgFSa8tNDVjbb9ucKjIfrRuRe+DK GMhIAQLvIQK4M30SxOnMQLIe3upsQ6JzY+5M28HkcBNKgd0dpZbwByHIJh6/ELTO Iaf08S0mCySKoZAJFEkeQ3YOgdIlZvwYsflxiEs62Mz9Mz8uuxTo6E21XyFr6iN/ XndXCzlAZBIQuiayEUL4fUM2cmeHcvhHpGNyYjBuLibuiaIzKMBzFQqEZHGA0QzH QhptbHjTwXLxIEZy94ELH2FbQnTrnOBxOdYfmxGvlmJ0328hThW6N181L3fPHK0v 6zTChZziMhlIoZPX8AGNNsUYJFKBJs/khlbse/tQhXmm5zuIyq+Lt0nKjbhHkWJw n9y4PHxLVtmmOvptPMm00l5/w6yb8Qmxo81d6kq75ZEupjxupHH6YwjHWTehT/x2 Pt8iMX2NWVnVwVdsaqE/rH+JrgH1Pvl7TMqXMr8d7tuSWTeTBWlrcmZbS1rl0Z3T f8K2rBX6sBqmrD1xKDsn =5pB6 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 04:04 PM, Jeff Garzik wrote: > - This is a major change to the economics of a $3.2B system. This > change picks winners and losers. There is attendant moral hazard. This is exactly true. There are a number of projects which aren't Bitcoin that benefit from filling in the gap left by Bitcoin's restricted transaction rate capability. If Bitcoin fills that gap, Bitcoin wins and those other projects lose. Should decisions about Bitcoin development take into account the desires of competing projects? -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVS3jeAAoJECpf2nDq2eYj3hMP/0yk8HxypEfNa4vZo0IcKD+p bn2dftQsOEeOenBh8QT48vS3AhcjNkUsw722YwbKz6Znkyi2iU7njaUM9DV+QHwg Oytmh8XVZtviLgg3854ujdj4oAWyP4DpppVTRxTDyRdSpRj+D9y6+sGFls6z0q3/ XRcKOY23zx6/qN1k5fqUncpIpYEDhpmE7cGy26Yz0G4MtuYeceHT4LdJAHHr0iFL OY0WVM32b4F3HfkfJtt8rE0yeB7u5dbeu8KmLB0yqZQkY87sLxtT6qeoyHO6CG+N 8Iu9OWaRIZHfrZK2XlDzDKQIkTnlSxFtj4wY7/Yb4NIDO6mhMjYTSz8lWqN4ofKg 9fFHlwGS3QXXDTB+5d1IzZS5C0qF92n1NJiJjkLqhKqYuVn4U74oslZhVLxHBGHH ZAvW09obZXi5DVzhuxPzlFkpYaB+XLdmBUPEr5hx5K4I2qiL/Nvu0h031UDcMeLm x9mEHO5ZODlF9tWAVnM/b0VtwT9h6Q88NWe/OUQQZKp6D/Etcd3JE55GBNtNPDnE 2UubyHkNO4mbrEMluh24TvhZK3BB/lieq+kkHZCP7eC58eRY078lSF8R36XGdbn4 Pili15bYSrRrfmjDz24zhJX8759LPt2Zsf/Irc8Za4SoaEaYAqQU4vAmYlZyCNxj EvxXAasffnjR2K3cnZxr =YkTz -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:49 AM, Peter Todd wrote: > I'm not sure if you've seen this, but a good paper on this topic > was published recently: "The Economics of Bitcoin Transaction > Fees" ..for some very strange definitions of "good". That paper may present valid game theory, yet game theory has a well-known limitation when it comes to predicting real world behavior in that the predictions are only as good as the simplified model those predictions are based on is accurate. At the very least, we should wait to draw any conclusions from that paper until it has been sanity checked by a praxeological review. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVStYTAAoJECpf2nDq2eYjqzAQAJkLwVq3cJxaP5MirS6j+SkN NuRIQS8EzJkvojZvHCSRz3xPZpl9Cx2T6/hsLjIfzvMuDHKsaOkkLlL0q95ekv4T acfami64326DFAxiO0ptspPjCRipagmjSEwZGZwC/QZtTdnt+N9LsH0SFDP6hxbY Kf11LRd11Ap4v/VnBg/zb4daZnVm0k0nfZxK4rG1zN14r5JEu6eiodUBZc6e4qih LmopoddIwJS4MY1GoR2kCehAbJseZZyQQmHFEX1Vhc74ETGXWApfgF0tpo6ZMutd OT0WGhCpj4yG1u5bRaiNnsOy9WcBTKzDOLZUVVh/GhUGHWUulZu8ujYrX7Q6GR5S VPvOOL6Ts/RGEAE1UWKzHfPjrLZAHKgLAzBjm6o1ZXdBcnV+FsThNvd7fxHvaJsO pWGSu8qDmN/wH657Tphbthb4T/awnuf4rO6oBP+OGu+ydPIlIlt6rM2E4Bq366yy CJbzSR3x/P7fRmT2bbSg4rxTDyLFJpNIWOcNaMRBeO69OdNZxlranvFvEl/6FfqK GO/LPQiYCe/+yhXgUJzzlYpayPiPFWCg0FxwQ+xl1josTsrfPE4BUivkZvIlqOIY LX1fDHt/IIUNp8OUkY2eERxeB//dlY55nP7VGUEJLNnBkXuoBd70lMtGXxtgvw2M Wy5VER9CiEOUMMwzWi3Q =8mit -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2015 02:53 PM, Brian Deery wrote: > 1. There will be a 1:1 relationship between a payment code owner > and their identity. Presumably the payment code would be strongly > and publicly tied to the identity. This makes the notification > address strongly tied to the user. An SPV client connecting to a > full node who has a list of notification address can tie an > identity to a bloom filter and connecting IP. I've updated the proposal to provide for alternate methods of notification that can be used *in addition to* notification transactions. This frees the sender from constantly monitoring an address known to be associated with their identity, although they should check it periodically since not all senders will be capable of using every type of alternate notification method. I defined a Bitmessage notification method as an example; more can be added if required. https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVQWzPAAoJECpf2nDq2eYj8uAP/RsP050K9z8oDGy0KO+zjFwM iNzlsQaPY8kmR2k2oLXJp1n4QZIQAZly+vxjBZnOWXwAhrBcvnhNBvqdigwZYg3B oGyvGvArzkve86Ke1WF1hZEAvml3cmQ5jxYKMlwhzRPcHq2kwznw+5jRuTbf1JbE PxY5pOfnZ9ADVF5FkLR2KwBNvGA83Cle01hKd0eB6Omlb6azKDBXUqfzPPpB4lmp A8D0P3zkayzBYIiybUExfPJHUthd5wXL/TLwFkysPV7SnJE64C6Q2StD4wUtNQRS LDOw37RwhMx2Oz2YH3Ywi6w5tqYQP4LEWBuFb+LOqqphpV/FpFDl/Uznos00pz61 V9x2wrfg+MQnYk5/VIjPQxqvRsiu8yg4c2x0v+KIIMsuXKEPRFxaSS3DoaWUa1Jy +WDobHndIDw1TDqctP8LIiZ7zbWNYKJ4HgUaacHvTiA7TrJXi1KHo2b1pmnTbKhv fdHbjzd8UiMED6qeyrz1gGhjC2uSTwjZAmbBkCJccOGsrILoV1fifUW+de8qsBMH 6w6RiDwfeY2fHJHBS6O2Nhfk3OE5JaCWvy727ZXEq8lQ6dW0GOZvXg7INaktLagC tqvg85J5eCm7X8xQ33vgx8q2xt+IriMI2UnTILtb2H8XSiMRQSP7XfWDMfVGu4pb xbGZKbNS4WS+2FFKM4DK =6l99 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The notification transactions are a pain point when it comes to privacy, and yet they must exist in order to to ensure that nobody can lose their money as long as they back up their wallet seed. They could be treated as a backup, however, that clients would not normally rely upon -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVP5DDAAoJECpf2nDq2eYjdLsQAJ/nZKFavcJnCMUQ8hKp6dRq 2+7bAVIWYHuOV6sv/hvG2NaP3u24NYZ/Ji0oD3UAmkJxw9lsZuowwBBs+YAs6JAW KHTl3QtwBh0IP/V90JOZ5Yn72YWXDsNbqy7R3JhEDKOu2wVeiLqWZ2EDgGwiZ0/k aXFJbcVZEKttWYCNoZi0yRMH+S9gbi0LgOwvK9mRzF9IRz07SM1iKQeKPsW1X1UM KNeikFROMS7dHTO5HRGyFcTSwhUf8RJq2kea+4sJtj8Vlb5rURuJanL3Fav+ZZjr RWYubLp9EUrDMm9bciygL8+MKPas8hedHSW2JhjkshWYC/NoCXLBT6SGrrbj2SKL zGGeLYknjwgLTCstKSQlXW3J/xcSFwBztr//o95SwRoIKI7jpuOE6cPfUZVEuTsU Zm7IWuRw/1MMDF89gCtDkBJcX2mTARjiii1Hg0+7vCv6Q/fVgTNUvWEKeNtCNZjh wOiwd4eP1gY4CwX68c+8CfF+NOSXImJTspZJvDQcTge1/bQJNOBn+cMYxjBcJsqL ZUOvkWJqwiFERW7vjMhOVpqIyO38UluwsWgp7nlMl/npfv0ZDIrOqZrswHSTqfdc P8gSaqvpc6cMaLL/ijvOtORkVB9ZlLmlTv6mIYWHeKEf6PjIOZEb2B75zPHFAvrz TKLxjvWgvSJ4l5PrkCFA =1Id2 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2015 04:46 PM, Mike Hearn wrote: > So that's not quite what is meant normally by identity. It's not a > government / real name identity or an email address or phone number > kind of identity. I expect that mappings would begin to develop between payment codes and government / real name identities, at least as far as that businesses which are required to collect that kind of information would associate it with the payment code(s) known to be used by their customers for their own use. I proposed payment codes in this form because I'd rather see that kind of mapping be limited to the application layer and kept away from the blockchain/network layer. Even if it makes certain kind of application-layer distasteful behavior easier, it's a good trade if doing so can simultaneously provide resistance to graph analysis and make transaction-level censorship more difficult. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVPmusAAoJECpf2nDq2eYjhxIP/3Jw9f6kcEsdFTXouQ5+D5gb MjM8AW7EEA6KXj2PqrPv/H/brorW9/Ugcc8KweCjEdJAKOJV/Bl6sP5ydSZT6pmj A0IFIkbdxKLY9JC3BbmVHuiAFrsL1u2EX5arUC3WNAWeWlVEmAL92cSlAka4BBxy P/wh8xN0b4hsgA602Y4Btkv2fBHLQI9NMxW3AsujP3/S78mSxwKQZz4lYAMCowu8 NL/3toaFhrUsdHsH301jNAnxEEOodMVGmgjg/ZSdvWeHwdsE2J8Q9AJqiFDswjU5 q2kZuKmuJ6EXcGDlhelUuUpfHO34qS3/dyTydcqFrYB6eynZ8nV6S1SHaSlDEM10 b95+EpfIENtYdgAqJxwfbqpibpSEIW7cxCAopF0sSbQ2qv8rwRrcIah7KeARCrc0 e+HDcyLhYkrWrlK28vVmIxkEiQ/nmkTu9dOfoVJgXxcVl9AkiHGjo7QICOZHqfRB TOupk9UUHMmdfZC5vpj9rd+VSXJJEF19ZbGF1QsFSMuxjKTb9jAy7Dk6U/9/xK9Q +mH6QHhKzNKb8GsiowZJq3bF2mEYqmh/BPyQ06gfDLM4yvlTb+k4R6brFzm7tkWG 49hREmHK9w/wZXnH0lMCqMHRY/YqQF5bR3ujq7pB0WHLvbvDoSvyWvGQ9cVrRA24 ASb47sR77R1LlZntoSyy =b7HG -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2015 02:53 PM, Brian Deery wrote: > 1. There will be a 1:1 relationship between a payment code owner > and their identity. Presumably the payment code would be strongly > and publicly tied to the identity. This makes the notification > address strongly tied to the user. An SPV client connecting to a > full node who has a list of notification address can tie an > identity to a bloom filter and connecting IP. SPV clients that connect exclusively to hidden services through Tor could mitigate this, especially if those clients broadcast their transactions through different peers than the ones they use for checking their balance. Maybe they should even go the opposite way in terms of the false positive rate. A client could create a filter that *only* matches their notification address and use that filter with a selected peer. All the rest of their addresses would be contained in a different filter that is never sent to the same full node which is watching their notification address. > 2. The client can use a bloom filter with a higher false positive > rate. An active attacker can counter that by sending several > payment codes to an individual user. The user would then add to > their bloom filter all the shared addresses between them and the > attacker. Even with a high false positive filter, always matching > all the attacker's payment codes would strongly tie the user to the > filter. I'm not sure this problem is solvable in general. Any entity which has sent bitcoins to a known user could use that knowledge to attempt to find their bloom filter (if they use one). I think that for SPV to have any privacy at all clients need to get a lot smarter about how they use bloom filters overall, such as by connecting to more than one peer, only putting a subset of their addresses in a single filter, and temporally varying the addresses which they watch. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVPlu8AAoJECpf2nDq2eYj/cAP/iL9qlIkk/jz2N3mT4dIdrSn rQ+m7dHOSeucUhePrjdM79VzDUQWGmewdi5a1e8wCL2PCBeq/7mapEpHrvWu3xUU g0qtCa6CbSceW5pO1/BGnKpt298wrBIueeweR3/BPum90RrXT+T/ssQvjGvlY4Jg ADFeH4axalmCkc87OsJhsEbAAbP9i/u96rItV9ECpOET9pRxp4PzNT/7nz/x5n+q Lm/vuWy1yoWLUjXiAmXWJVzPs8+Pzf1liy3SEzkam156kUwTj/CqjI/uhf7heSx2 FYSswBc/R1fga7eu++Bm449KUTmyTnnEIT4109A1w18fidY2Dg6PpKYp5CGug96t aHit1hqLfc8HpNUVWLrBrHsC7riy+QGta4Ie7fAl9SvFcNturkXBFxZLO8f34WMb HFuWkcCAgZcS3hb1ShmyodMjnOWvHQo/dXAoUc+zI8yuiH9wAD6T4LOTkSwCjvvv 9y4Ia4Mr6v6oHQpUM8ddCMU4AyAYvZXFb68SsnWMZCCio3Ff9wqp2d690oSq36G7 jdjmxot7LrPMnJjNKwTl2jndDTB9Huh9sjWyE9gGBkkIib1purOYtucDsY3h6z7i 5ppG1KTph+xaOLMEvyJZyDNvPhrQGk1ll1kMoD2k7P/5OGV7QwQ0IxpoAqZ1uxJG 44rCXd7P+2R+Bza9qHSH =d2l3 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Reusable payment codes
Payment codes establish the identity of the payer and allow for simpler methods for identifying the payee, and automatically provide the payee with the information they need to send a refund. If merchants and customers were using payment codes, they would not need the BIP70 equivalents. I think the best way to explain payment codes is that they add the missing "from address" to transactions which users want, but we've had to tell them they can't have. A payment code behaves much more like an email address than a traditional Bitcoin address. On Sun, Apr 26, 2015 at 2:58 PM, Mike Hearn wrote: > Could you maybe write a short bit of text comparing this approach to > extending BIP70 and combining it with a simple Subspace style > store-and-forward network? > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Reusable payment codes
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell wrote: > On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier > wrote: > > Taking the hash of the secret would then require an extra step to make > sure > > the hash is valid for secp256k1. > > The x value may not be a valid member of the group, effectively the > same as with a hash. Its also very unequally distributed, as only > about half the possible values are points on the curve. ack > > With 97 byte standard OP_RETURN values the ephemeral public > > key could be appended to the chain code, but that's undesirable for > other reasons. > > Can you elaborate? Storing a ~33 byte (deterministically generated) > ephemeral key should be all that is required. Everything else, > including the chain code could be derived from it. What reason do you > have to include additional data? > The goal of the notification transaction is to send the same payment code to every recipient, but obscure the identity of the sender of the notification transaction from third party blockchain observers. The shared secret is used for that purpose, and the sender's public key used for ECDH can't be one derived from the payment code since the recipient doesn't yet know the payment code. The notification transaction needs to communicate the 65 byte payment code along with one ephemeral public key used for ECDH. If that ephemeral key is not located in a signature script, it has to be somewhere else (such as in the same OP_RETURN output as the payment code.) > > Taking the SHA512 of something less than 512 bits seemed wrong. > > Why should it? Adding the Y does not increase the entropy at all. As > an aside, I think this can be reformulated to only need 256 bits of > output, and then the need for yet-another-hash-function could be > avoided in some cases. > Already fixed in https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 but it would be good to get confirmation of whether the way I fixed it is valid. > In this proposal I optimized for non-reliance on third party services > > The requirement for inputs is a guaranteed dependency on third party > services; so if thats whats being optimized for here it must go (well, > I think it must go for the reason of avoiding blocking users from > using other schemes to control their coins too..). > I'm not sure what you mean by "the requirement for inputs is a guaranteed dependency on third party services" At the proposal currently stands, an SPV wallet will have no trouble sending or receiving notification transactions without access to a third party service. The recipient just needs to see the transactions associated with its notification address. The point about restricting the types of scripts used as inputs is valid, but I think workarounds are available. If nothing else, the sender can make a suitable input using it's own (suitably mixed) coins first. > I agree. I could not find a straightforward way to express a > multisignature payment code in less than 80 bytes. > > A prior stealth address proposal here handled them fine with only a > single ephemeral point in the op_return. It does result in a longer > address (is that what you're referring to with '80 bytes'?) > I considered defining an additional path level for deterministic m-of-n multisig and adding a few bytes to the payment code to express those parameters, but thought it would be too limiting since it would preclude multisig with truly independent keys. It is a thing that could be done, however. > Exchanges could restrict bitcoin withdrawals to a single payment code > known to be associated with their identified customer. > > In some jurisdictions the ability to prove that withdrawals are sent to > a positively-identified party, rather than arbitrary third parties, might > move some Bitcoin businesses out of money transmitter territory into less > onerous regulatory situations. > > But this mandates horrible key management practices, reliance on a > single "hardcoded" private key which you cannot change; even if it > might be compromised or lost to the wind. It's less horrible than > sticking to a single address because it doesn't wedge privacy, I > agree; but care should be taken that a tortured dance for confused > regulatory cargo-cult reasons doesn't mandate people not engage in > sound practices like periodic key rotation. :) > Cold storage is still available (if admittedly less convenient than in traditional wallets). I would expect exchanges in practice to allow for payment codes to be changed, just with non-trivial waiting periods and plenty of human overview. It would be an infrequent event compared to the frequency of withdrawals. Various schemes which use publ
[Bitcoin-development] Fwd: Reusable payment codes
Taking the hash of the secret would then require an extra step to make sure the hash is valid for secp256k1. Using the x value directly avoids the need for that check. On Fri, Apr 24, 2015 at 10:35 PM, Patrick Mccorry (PGR) < patrick.mcco...@newcastle.ac.uk> wrote: > When computing the diffie Hellman secret - why do you choose the x > co-ordinate instead of the hash of the secret which is standard practice > for stealth addresses > > Sent from my iPhone > > On 24 Apr 2015, at 21:27, Justus Ranvier > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki > > > This link contains an RFC for a new type of Bitcoin address called a > "payment code" > > > Payment codes are SPV-friendly alternatives to DarkWallet-style stealth > addresses which provide useful features such as positively identifying > senders to recipients and automatically providing for transaction refunds. > > > Payment codes can be publicly advertised and associated with a real-life > identity without causing a loss of financial privacy. > > > Compared to stealth addresses, payment codes require less blockchain > data storage. > > > Payment codes require 65 bytes of OP_RETURN data per sender-recipient > pair, while stealth addresses require 40 bytes per transaction. > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd > > JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa > > Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz > > QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG > > NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR > > o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo > > 2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h > > /wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9 > > EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET > > n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI > > OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+ > > SGApMBd4Q89fKzL2djae > > =Dypr > > -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 > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Reusable payment codes
I have pushed an updated version of the proposal which incorporates some of the received feedback and adds a note about the consequences of sharing a payment code-enabled walled on multiple devices: https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier wrote: > > > On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell > wrote: > >> So this requires making dust payments to a constantly reused address >> in order to (ab)use the blockchain as a messaging layer. >> >> Indeed, this is more SPV compatible; but it seems likely to me that >> _in practice_ it would almost completely undermine the privacy the >> idea hoped to provide; because you'd have an observable linkage to a >> highly reused address. >> > > I agree that the output associated with notification transactions would > require special handling to avoid privacy leaks. At a minimum they'd > require mixing or being donated to miners as a transaction fee. > > >> >> It would also more than double the data sent for the application where >> 'stealth addresses' are most important: one-time anonymous donations >> (in other contexts; you have two way communication between the >> participants, and so you can just given them a one off address without >> singling in the public network.) >> > > Communication is only one way, except for the case in which the recipient > wants to send a refund. Assuming no refund and only a single anonymous > donation in the lifetime of the sender's identity, payment codes would > require 65 bytes vs 40 bytes for stealth addresses. > > As soon as the sender sends more than one donation to the same recipient, > payment codes show an space advantage over stealth addresses. > > This kind of binding was intentionally designed out of the stealth >> > address proposal; I think this scheme can be made to work without any >> increase in size by reusing the payment code as the ephemeral public >> key (or actually being substantially smaller e.g. use the shared >> secret as the chain code, but I should give it more thought) >> > > With 97 byte standard OP_RETURN values the ephemeral public > key could be appended to the chain code, but that's undesirable for other > reasons. > > This is fundamentally more expensive to compute; please don't specify >> "uncompressed". >> > > Taking the SHA512 of something less than 512 bits seemed wrong. > > >> This appears incompatible with multisignature; which is unfortunate. >> > > I agree. I could not find a straightforward way to express a > multisignature payment code in less than 80 bytes. > > >> I'm disappointed that there isn't any thought given to solving the >> scanning privacy without forcing non-private pure-overhead messaging >> transactions on heavily reused addresses. Are you aware of the IBE >> approach that allows someone to request a third party scan for them >> with block by block control over their delegation of scanning? >> > > I suspect this is a case where we just can't have all the features we want. > > In this proposal I optimized for non-reliance on third party services and > a guaranteed ability to recover spendable funds from a seed backup. > > Gaining those two features resulted in some tradeoffs as you noted, but I > think there are enough benefits to make them worthwhile. > > In particular, payment codes could be the basis for a Heartbleed-free > payment protocol that can positively identify customers and automatically > provide refund capabilities in a merchant-customer relationship. A merchant > only requires one payment code which they can safely use for all their > customers, meaning they only ever need to associate 65 bytes with their > identity to allow customers to make sure they are paying the right entity. > > Exchanges could restrict bitcoin withdrawals to a single payment code > known to be associated with their identified customer. This would make > thefts easier (without involving address reuse as in locking withdrawals to > a single P2PKH address). > > In some jurisdictions the ability to prove that withdrawals are sent to a > positively-identified party, rather than arbitrary third parties, might > move some Bitcoin businesses out of money transmitter territory into less > onerous regulatory situations. > > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Reusable payment codes
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell wrote: > So this requires making dust payments to a constantly reused address > in order to (ab)use the blockchain as a messaging layer. > > Indeed, this is more SPV compatible; but it seems likely to me that > _in practice_ it would almost completely undermine the privacy the > idea hoped to provide; because you'd have an observable linkage to a > highly reused address. > I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee. > > It would also more than double the data sent for the application where > 'stealth addresses' are most important: one-time anonymous donations > (in other contexts; you have two way communication between the > participants, and so you can just given them a one off address without > singling in the public network.) > Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses. As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses. This kind of binding was intentionally designed out of the stealth > address proposal; I think this scheme can be made to work without any > increase in size by reusing the payment code as the ephemeral public > key (or actually being substantially smaller e.g. use the shared > secret as the chain code, but I should give it more thought) > With 97 byte standard OP_RETURN values the ephemeral public key could be appended to the chain code, but that's undesirable for other reasons. This is fundamentally more expensive to compute; please don't specify > "uncompressed". > Taking the SHA512 of something less than 512 bits seemed wrong. > This appears incompatible with multisignature; which is unfortunate. > I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes. > I'm disappointed that there isn't any thought given to solving the > scanning privacy without forcing non-private pure-overhead messaging > transactions on heavily reused addresses. Are you aware of the IBE > approach that allows someone to request a third party scan for them > with block by block control over their delegation of scanning? > I suspect this is a case where we just can't have all the features we want. In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup. Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile. In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address). In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki This link contains an RFC for a new type of Bitcoin address called a "payment code" Payment codes are SPV-friendly alternatives to DarkWallet-style stealth addresses which provide useful features such as positively identifying senders to recipients and automatically providing for transaction refunds. Payment codes can be publicly advertised and associated with a real-life identity without causing a loss of financial privacy. Compared to stealth addresses, payment codes require less blockchain data storage. Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair, while stealth addresses require 40 bytes per transaction. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo 2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h /wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9 EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+ SGApMBd4Q89fKzL2djae =Dypr -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___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: re Improving resistance to transaction origination harvesting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Forwarded Message Subject: re [Bitcoin-development] Improving resistance to transaction origination harvesting Date: Fri, 20 Mar 2015 14:06:59 +0100 From: Arne Bab. To: justus.ranv...@monetas.net Hi Justus, I read your proposal for a bitcoin darknet (friend-to-friend), but I’m not on that list, so it would be nice if you could relay my message. Wladimir J. van der Laan wrote: > Experience with other networks such as Retroshare shows that … in > practice most people are easily tricked into adding someone as 'friend' This argumentation does not apply to the friend-to-friend connections in Freenet, though, because in Retroshare you need friends to be connected at all, while in Freenet adding Friends is optional. They were made optional in direct response to seeing people exchange friend-references with strangers. An important aspect of friend-to-friend connections is that they have to provide additional value for the communication with real-life friends. I had few darknet contacts in Freenet until I started using messages to friends for confidential communication (in which freenet traffic provides a cover for the direct communication with friends). For details on confidential messaging as additional value see “Let us talk over Freenet, so I can speak freely again”: - - http://draketo.de/english/freenet/connect-speak-freely And for a description of capabilities freenet builds on top of the friend-to-friend connections, see “Freenet: The forgotten cryptopunk paradise”: - - http://draketo.de/english/freenet/forgotten-cryptopunk-paradise Best wishes, Arne -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVDDnjAAoJECpf2nDq2eYjgwUP/3fRjH25OcGmG5AS3UE/wTvf z8DrPieF4wtX4ABZTC6X/Ls9JnWeEhL3jN70SfGLzx2Exat620DVeR7nMHuQhLQj 6vWJSKLX8a0W47LmlAveagKeLMyQdOa1jZWZWJOUwxpoH0sHJwhBvRSiZeoHub2H PI+WyivRy3aUhhAc4EkFlaFbJVl7JMjdaqEaoHV2l96fKkvuJOYfzKWuxYd0noTI mgfDrXtm1zTH6H9C+B+AhXlDlaAnBoVr/EC7r4nKGeXGvOBw/UrAd/OHEySQJm6b Quo8jPBOT8mwZVanJaAbRBDnOYXP4lIxkGaH5aXCWCReiepCPtUqbGF7hHXlAwGQ LjpLr81Uxd/1TKk709FnSKtprSf6WdYmkzXCNjjPWLfd1bR7Yj71wtmDwPdy5IOS W9TSD9gszD0BmiZFncD4lyKBFletfGlZaVirXNhwgEKBgRcS48AYc71IjWfjbq0B P2wzevfdHJqda3Wr04H08pGNO9YeYVqJAvr7sqHaZdn7DyDdDhRehpzbgkphNU3c Pr1XBTheFqZZTZSya1ufVR4y9c1qFeVx1T5pqVyfUt1nNA0oaHNm0tcCOKafNAyq +9r9p08IXsjR44STpw/DHMERZ+W/XCJsACwWNo3BK7UumHlvaLoevmdmswghjblb MQKLKZaKAZA56lvPymbC =7CQT -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] Improving resistance to transaction origination harvesting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The ability of entities with large numbers of nodes to track the origination of Bitcoin transactions is very similar to an attack on the Freenet project. The Freenet project addressed this weakness by via a technique they called "Darket" - which means that nodes would only connected to a defined set of trusted peers instead of being open to all connections (Opennet) An individual Freenet node can operate in Opennet mode, or Darknet mode, or mixed mode. [1] This approach would be beneficial to Bitcoin as well to reduce privacy leaks due to harvesting attacks. Proposal: Allow Bitcoin nodes to create authenticated connections with trusted peers via CurveCP [2]. Nodes that have at least one CurveCP peer only broadcast their transactions to those peers. Use of CurveCP requires both sides of the connection to know each other's long term public key. This key can be packaged in a structure similar in concept to a Freenet node reference. A Bitcoin node reference consists of a JSON structure containing one or more "externalip" elements followed by one "pubkey" element. The structure is then clearsigned by the long term CurveCP public key contained in the "pubkey" element. Users who wish to set up a secure connection between their nodes would first use an API command to generate their node references, exchange these files, and copy them to the ~/.bitcoin/curvecp directory with a .ref extension. The node only accepts CurveCP connections from, and attempts CurveCP connection to, peers whose references are present in that directory. Instead of listening both for regular TCP and CurveCP connections on the same port, CurveCP connections would take place on a separate port, designated by -bind_curvecp, -port_curvecp, and -externalip_curvecp If -bind_curvecp is specified, the node will always listen for incoming CurveCP connections, -listen=0 can be set to disallow non-authenticated incoming connections. Relationship with Tor: This proposal would work along with, or independently of Tor usage. The same network monitoring techniques which can track an originating transaction to a particular IP address could do the same thing for a node which is listening as a hidden service, and any technique for deanonymising hidden services could then identify the point of origin. Currently the only way to configure a node to submit its transactions anonymously to the network is to make the node non-listening, which means it can not contribute to the network. This proposal would allow nodes to contribute to the network as listening nodes, while retaining privacy with regards to transactions originating from themselves. SPV peers: CurveCP connections also can be created between full nodes and SPV nodes, in which case transactions originating from the SPV peers would be routed as if they originated from the full node. [1] https://wiki.freenetproject.org/Darknet [2] http://curvecp.org - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVCFWiAAoJECpf2nDq2eYjsqIP/2Ri7gmJ1ULqRKh6k0BZskTh zW2T+Bm+QgoTqiaoLSB61kX6IjwMdTTeVmzCn8ciRIUzvn+RD4843qG0vYKAU3BZ o+7kMzfAn+KK/Y7j9S++FLteCs21GxsQfARwkKlJxvluoqxlIL50K5H1SySpmZMs UKppgAIUpHv8H+5T4hwRlgM2vnZv7YyMqEpCDAsVWtQfyOg/WsftVP2UI4zsM3ei KU36ztJYVUDqmnu3gg0mIW+lv/DqHk59d3Mo/gveRUUUTGzYXy7kKkubCzJQ5t7s AgEdm5OmlKDEhZt/gFt6AA1FEjoQY+TzDSspFCJMiXmWQU7xu+wJwP7TBINXUbXr 7TNPC0KWHkBCa0ccKvP4O72dToPQM8LQl42My8ye0sUkfqAcOldRoqYBsnpqAdVv ddvjSyr1wn1ek8bC7tjL1eRdjYz9PFeNayDv5vyur067DI5yjgpTXLjKVHxZe5TO zA8MC8gp/mHDexO9+zmi+mFdPD/HiFl2liiLMsSg7pxGxMCy6cB8sUXHNPm6+vow HHGgRWAVWVkTZNHc7n50+ugbtrudQaDOehVSH3NRLZC4pnRAg+pzZz/5Z/WWjr/M mE1M3nbitCwznFpBm/Zgg7DUZq+MMTlUwsiNdGhyqYfadW7L5/vlp4d7otNoIhOz V8zOgdC3ZwMfbf/g26PM =u2MW -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] Criminal complaints against "network disruption as a service" startups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2015 05:24 PM, Mike Hearn wrote: > Well they don't set NODE_NETWORK, so they don't claim to be > providing network services. But then I guess the Chainalysis nodes > could easily just clear that bit flag too. If a peer claims to provide network services, and does not do so while consuming another node's resources, that might be considered exceeding authorized access. bitcoind should probably have more fine-grained control over how it allocates connection resources between peers vs clients. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVA2bPAAoJECpf2nDq2eYjm/UP/0MZmdEBameT6tnLnebkru5d UeHsX6Qikv3qF+i936SkoDylg08PJNWlpApuXC5t52x262V763y9tGV8qqh3vTSf LeLeKY1M4mYCjHjegpz3JXzzF9i9OqgWl+0OxGOHDHyp8COfzKzC9FEUP3XBqitb swyeS2t0LkzJnXYV8z8pDOxn4pZN0cUaKPvBIRKEUs4PgA4JVpRTM5Rvzi7oOItz GHknxH++ja7kfFpgRSJMh3gHu4xhRiHfzGPaszrrrznpubNr42+4ouBy+QDr2XYr 1AtklROYLySeUtd0yNxeWdeaLIBSTiiDisNkD62MOTr0Zmdnc6M7IefSCqLN4fD9 wPu5a5h4HI/N/4/+kUhGmW+g5vagKMkCVlUIsG7gpGQJk4HyLElAdmgDToPJTrvr htrd7k5HjjZu8oAt/vYcx15myuQ7VXc7v193g7m3kRRx4rnZ5XCu5BJd92uaOW1e 9ARhN7hfNQbfVkZw0f+qfG0fzMSAk3aHxpao7topwKARQfYJ++Mry5qAzFfxWred IHXHbd4JqafsUJxTqDvm7oVP+l+XqlFkZTGi5u6NjPSeJL0IMFI5NqOepqAqwi0P n9tePxN19+TmK2TSGtuzWBNZXcbwujSmvzRnDouxpcTyhRXc5YBbetI4/s0xcAyK sQ2dm0SKF4S8MclylelW =IpAp -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] Criminal complaints against "network disruption as a service" startups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2015 05:08 PM, Mike Hearn wrote: > > That definition would include all SPV clients? Don't SPV clients announce their intentions by the act of uploading a filter? > I get what you are trying to do. It just seems extremely tricky. Certainly the protocol could be designed in a way that provides finer-grained access controls and connection limits, which would make the situation more clear. What I'd actually like to see is for network users to pay for the node resources that they consume, so that anyone who wants to place increased load on the network would compensate node operators for the burden: http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ Absent that kind of comprehensive solution, problems like this will continue to recur. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVA2HLAAoJECpf2nDq2eYjcvYP/iqYBxboMmTPLp9Kx3GlBdR/ IPtCxVoaZQkqrAHlbbED1YHoI7QqaufdPMb9mw8bErFX7E89u4gD93jvx2x+skqW KtqIyc5fHe4MgbtGypvE5GjSiqZZIqn7EYzLGVE5ydmO4SKpfodXIIRuQRkZ1fTG j0ovFc/bmigS7Cvf3gsMT5oW26IcEaH6mAZ/YU5oVEi1LGff8hUTq90uddOCpoqp mIj8MHMdd0yvtihjLwyJPdfT0qTOkbAxHJqwPLoOWzmrN0z1PbU9qcf0aHdDnMlT +jWHqHzSxjwyB1bmUhi6vZKVFfd1moOTI3BBj+Jqjc+xaOmXCcyAtpfzq97VITZw qhAnYM4unsC0A1GH3fQEJPvoOy0kwyNNtI7z5YOrRJtihCpFSbtULqN9DUmxwgKL /0cmOc2SyjgflTiCejazBIJk4Ie+WcV2cbgepdX8USb0tusQs+jn2HMFGUfxywTz riy9Ex8Wftl12LAYXSbMQl7GnADYG9t0HIY3JqPAhAzEdPynXUduveatiQyNc6SH IqXraTgHj6IFFWB7eLjWuIleyxcFC81qTFNUYxEajGDLbCX00emKiR3RUpVZ/wP7 8CXcV4zco1y1+va1eD/7eNhTW/Xuf3+KdqJs2reLq23fLV01HA92sRYbgLIxb0Yz yBsE+PpY06vrHqoVD/4l =Ofbb -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] Criminal complaints against "network disruption as a service" startups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2015 04:48 PM, Mike Hearn wrote: > That would be rather new and tricky legal territory. > > But even putting the legal issues to one side, there are > definitional issues. > > For instance if the Chainalysis nodes started following the > protocol specs better and became just regular nodes that happen to > keep logs, would that still be a violation? If so, what about > blockchain.info? It'd be shooting ourselves in the foot to try and > forbid block explorers given how useful they are. I'm not talking about keeping logs, I mean purporting to be a network peer in order to gain a connection slot and then not behaving as one (not relaying transactions), thereby depriving the peers to which operator actually intends to offer service of the ability to connect. That someone wants to run a large number of nodes in order to make their own logs more saleable, does not mean they are entitled to break the protocol to make other node operators subsidize their log collection. Especially if a data collection company is deploying nodes that do not relay and aggressively reconnect after a ban, it seems like they'd have a hard time arguing that they were not knowingly exceeding authorized access. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVA16sAAoJECpf2nDq2eYjxsUP/3ASGcsdGR8IEO7Fk8VghuVp jwIIM8Bu/WsoWKG76GhuPKs/qC0VC6GXKpGUBVy7bF8uwdhfdSXcyld9MIzIENJF I0wMX6B3SjqQG/g0rNZ91Dh3xKIF39/TQdDERM3yiQi1oavAc5TPLReN9ZbyRcVw vCfPWorTvrad5INCn/krcEopbI013aW2ryWnkN6sFGinF5Yf4xhrNQbQeGbhlH15 /XUIBva6/PbUs4HaC+wqJPSUfB4OmcP1ZfXMuPDEmKEWdI+3WqUYF4sNAVOke560 +RL5qMJIxSUMYMAb3p+025Fn6WOc2wupQzpH/ISkuaI+5+ne54Mx/ZHJg7Z7inov WMKfiUS6R8EHrY8IoNpO9uNqsgC+y0vlU3ELqu+gOhFTpMK7pVX2aAek8Qe7hSHy GwtG5U6AFubLqyzP9/pBJHnmDG71brsKffAXOePDjXWfLfhy78aeQ3HOnzVhv9QK snmE2C6Ex/tQDUwT9MKTdw59Hy7E7GdQlSPH+MYQKUBlkpWLDGpi7oriBRwvEy4/ NJCJU9+x7jijD7vrjBE+LSYdIQoZqE240N6teWqVc2wRPM8g+e+kSQqfjdKQdiQY waeKHBKerqRq2EGffeJWV1RIEFtFND1l8zw/5ZQF4w959zLvhk/QPHzxKyTbCM2f 3DOgEWCJFLsNzpPQ8es2 =MV9D -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] Criminal complaints against "network disruption as a service" startups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Given the recent news about Chainanalysis (https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/), and other companies who are disrupting the Bitcoin network (https://www.reddit.com/r/Bitcoin/comments/2we0d9/in_an_unrelated_thread_a_bitcoin_dev_claimed/copzt3x) it might be worth reviewing the terms of the Computer Fraud and Abuse Act and similar legislation in other countries. Although it's not possible to stop network attacks by making them illegal, it's certainly possible to stop traditionally funded companies from engaging in that activity. Note there exist no VC-funded DDoS as a service companies operating openly. It's also worth discussing ways to make the responsibilities of network peers more explicit in the protocol, so that when an entity decides to access the network for purposes other than for what full node operators made connection slots available that behavior will be a more obvious violation of various anti-hacking laws. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVA0IFAAoJECpf2nDq2eYjp0IP+wVsW69xOpFIX4yRTHrEQYh7 MCPM7OTkIay/O13TSewbxTRPww9Z6vOpmrDkFlWGYKyrLWyqUGwcKqOscE8r3P3U xdV5ACppol5HXra/bykxuaXJWF/yTM7PybFNQ2Ary0X41CFrOUITsO8SwWDl8jBu GtRgbWdALA6IQeeRLVQmMo3zC/uShOplOh/HrS2z9ZtXSm3rNkLzhnUWfznbixb0 9C1yvIM5VOwoNcRKt7uoX6cl4mFsBO3Gfjz4rr5gABerTltBlRk4c3jnUDUlQiFC cppX9eaEYMLR7y0gHWnmzWcFW7LFwMR2isyJ79O2cpUpYNzbfp0fWetM1WVAMFSK 7hyUlwVx4WgaVRT5hDb6QPHHvzCYjYq+19+9/uChh9P3s3QkKuFJUVYwHQ+wnruK hPS3/vb7Tmt1eLTUeno4RRyJJ7likHsNA2bxWSG9rDezTownkSVZe2BQh3GIZOBg H8Nu2IDWK4pHJaCiswW4jfDsucuYiP7978p8ZFbZbymeflsXz1qyUHSVm9kngfZn sYUK4rgRsdrPpong0nqlmWcQW3VgmNO1tw5gmUqWTxQLnrCxgqnSdT7srzAw1ZaS YIAaB1rBy8k7QyDCOyIsIV+n1H26ZBa8PrqdRExlz6PuWcywjuEbcIfEl9QSURA+ pLuNJ+uQN+JBjKokmaSQ =ZO1/ -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 10:17 AM, Natanael wrote: > The problem with this approach is that it is worthless as a > predictor. We aren't dealing with traffic safety and road design - > we are dealing with adaptive attackers and malicious miners and > pools. > > Anything which does not invalidate blocks carrying doublespends > WILL allow malicious miners and pools to conspire with thieves to > steal money. The probability of being hit will then be (their > proliferation in your business area) * (their fraction of the > mining power). > > That might seem to give small numbers for most sets of reasonable > assumptions. But the problem is that's only an average, and the > people being hit might have small profit margins - one successful > attack can place hundreds of merchants in red numbers and force > them to shut down. > > You should never expose yourself to attacks which you can't defend > against and which can be fatal. In particular not if there's > nothing in the environment that is capable of limiting the size or > numbers of any attacks. And there's no such thing today in > Bitcoin. > > This is why I sketched out the multisignature notary approach, and > why some decided to extend that approach with collateral > (NoRiskWallet) to further reduce trust in the notary. This is the > single most practical approach I know of today to achieve ACTUAL > SECURITY for unconfirmed transactions. > > Don't like it? See if you can do better! > > Just don't rely on zero-confirmation transactions! You just disproved your own argument. It is possible to predict risk, and therefore to price the risk. You also noted that for some Bitcoin users, the price of that risk is too high for the types of transactions in which wish to engage. In what way does that translated into a universal requirement for everybody to use multisignature notaries? Surely the users who can afford the risk can use zero conf if they like, and those who can't can use multisig notaries? -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJU6gLmAAoJECpf2nDq2eYj8/AQAJfMtBqjo1Z2Z0A7OhE9iaYD PqWXdRaCFwyV49RSDrRROrB9Vc7CENQsweHBSnNEmSj6la/YfjyobmaR5BMtTq73 ZaXOFYSGVa9S0j+1qTvz2MorBd6ocxckdunfN7N/uVb4NQRYTHUT8N7AyJgRFYO9 ElQU/8TcNCSRqSQc3z8rnUc8eN1+DgqkMDHM754huOgA0fz0OlxnLCddcCvLr0t7 ZPCtZI94FWQSWhzTK2oa41hh01xG+Eg5GhqGzM7WBqM6+d/CgNcUVeMnVOkkhgav AmlE81Km9R4AlrsGT/CcGgaC+FvBhqmDYHAGOUG3hLP+MXMe4qA5TRoRKHFvq4Gw nF6q+leI7z/TkKeiDcyEKKen5cU01SnZlVRnncccIxsjzNjCiBdXOTP6o0pTd34j 5VJQ04mF4sla5AaaSDtsbkZuMdqIZDMn1tWxbmXRQ2cUbCGoi4yYiUlqjetrs4e1 i7NopccLNVDwjGRRnaSs4KkpuW7s23XwKm6WVehrP7S9s1Bqc+84C/rL1G4IF3Ul vOz+dfxpS+yeGdEDOxb92voKo+fvL/N1sH2+cqTemuYWArDOn1kK/qKdaEfnl9p2 VcPJWuik6Ywomg4fCWmTQWcDxbWiUT/Gb/niONOYQ6iJG7mU4SH9LFBDd8qV+ljN RqUYrOBf/PaMneNxwJp+ =w36r -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 07:50 AM, Matt Whitlock wrote: > This happened to one of the merchants at the Bitcoin 2013 > conference in San Jose. They sold some T-shirts and accepted > zero-confirmation transactions. The transactions depended on other > unconfirmed transactions, which never confirmed, so this merchant > never got their money. > > I keep telling people not to accept transactions with zero > confirmations, but no one listens. A better solution is to track the failure rate of zero confirmation transactions, and adjust prices accordingly to cover the expected loss. This is what every merchant *already does* since no payment method has a 0% fraud rate. Even physical cash has a probability of being counterfeit, and the prices you pay for things at a convenience store already have that risk priced in. The idea that zero confirmation transactions require a 100% guarantee is a strawman, especially since there exists no number of confirmations the actually produce a 100% irreversibility guarantee. Zero confirmation transactions can work as long as the risk of reversal is measurable and reasonably stable. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJU6f0FAAoJECpf2nDq2eYjWJsP/3I6b9KL2tr7wEGUyiUJvn95 wR/DQw3jRoC6rP1OqZAHpePksboEtd1yTxhtnH9UEMzvzFrGeQwKaSgM0s6zbIIm 38BXH6uiTzxI2PUWxv8HDNsPvwAlj0l4EkV9E8DthK9MTDVAk5E/SFUlwgc4tdYB QinntAYknjIJd7dKVXlIaBrXg0UmTaXDKq9yoQIBTl9SE8xYbbRM154XAjVmqVrZ h88ZGkaIbpHbBEjbUpqVpPIKM/Ts4b6NwLSfloY7W+Mmvgn3p6EB4V6rt3HuV/wN L5A0RPbAESGsg0MpRcIprpAq4aiO6Qt0p6wMrZ9x6a+cx1w/RuJx7Sb3zflDjBgk FmEwqIKJJqWoTEtR2nCEkmDvwx48RJQQppEHJgdUCmxjELpJMKkvtz9Oc4CRP0ty 6JUnBmxNTHRJLL+0nn1sq5WAhTLIQaH3RcVn/SjNk2zjoUXUdx+1pIEyBaZnOckW e54SraX0KEEZNpTXHA3xJV0d2gA068CChG/TFqMO9uhohWz9jz6NZl7jFLwdBjgb Wmbid/V/bl6W/ehCiOwLDM/sOer/BDoZPqGt/j2cJZO9gP+wVdiRkojl3f97vd9k qhGV3QUsc8uiseZNxeIv2hty34KzUPz2ISPM25ZnQMavIevg3Yg0l4O7Hwnk49oK 1nhyoqk+scfLpo7vd6Ke =fVAx -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:47 PM, Allen Piscitello wrote: > Nothing will stop that. Bitcoin needs to deal with those issues, > not stick our heads in the sand and pretend they don't exist out of > benevolence. This isn't a pet solution, but the rules of the > protocol and what is realistically possible given the nature of > distributed consensus. Relying on altruism is a recipe for > failure. If there's a risk of fire burning down wooden buildings, pass out fire extinguishers and smoke detectors, not matches. The latter makes one an arsonist. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QRrAAoJECpf2nDq2eYjLtwP/3t0uplMwjpt6MP0wrPwOfkJ tRRyAaSkEsZi3+XjU2GVThG7kAlP2oIGFnoHc1QldhlEeWEJgPZyn7qq+mPx+I5+ OKb0PhSwRpTe0lh+r1dGyVqN+sSfbasJ9RSXYPmw1OW9ud4WOsgOh+oBTQWfuhvc p32Fxxx5JKjc4AnCVajSzNlPlXrBy3pFfL5F1ek4Wu+H0haz39VE/EYAWlXjyWxT vhUzv+9bcy3r8pe3eYUAmsXYLZAKb/9hWJdht6SKd509BlV6LVSrUh8Y2SJ3PYKt z3l4WmiUXkkdk1blqtLDyfUTEZSnBK8X4esj8Sp53WfOXNkgBKe1vr4EhTXaEQMU KD1e5s12xspPYgJdW9TWacIYKp3Ft3yBODJOTNZL3j0ryzYA+KU5ZumdHIm10J3S J1IDQBraONESinHybGPKYtUCikTkl6TemW/CpfjRhQONov4708FIg+KQAo6ui56N otfDGEwqH1qKgbt5DugdEBtxDmYmcYdFjID2+ZLwK6ngat8UAw2dQoCnUtkZ7w+i Oxz4cm1vIRjv+BYipQjg4IRRZNvpEXSolz6u91qqj8SlXXdY7sZ3B5HwtGSOVX5y l3NxYVOazA/NA/zcCG9ZPjr/O5sKJ40IjcLbTHvE1POuiF167xF2+U2Sdf/43d9d cE68utrIaurfJsDA/L/+ =pTe/ -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:45 PM, Peter Todd wrote: > None of those solutions are compatible with decentralized networks > for a lot of reasons. Given the inability to prevent sybil attacks > your suggestions lead to people being unfairly punished for poor > connectivity that may be entirely out of their control. They also > make maintaining a Bitcoin node and mining the blockchain require a > significant amount of hands on maintenance, again incompatible with > a decentralized system. So maybe scorched-earth solutions aren't a good idea after all. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QO8AAoJECpf2nDq2eYj4bUP/R8Lwjpdvc8Wu573+cGVRI88 /J8fURgYTxS9yvNNGRRHDYkHiqAcGI4sHIQQkqGs+A6mdDTbq6bJ04RjHoznlYbj TcpaKQkEynVSD5AjMnZ7Z/zLsc+qjFChNGNgxC3k4AW5UdBgo3VTE8HR1rVXM5C3 JLCSKv8uCRkHJxRlXZwE9/sZTZAAuLFVdTQb6sfi4Kb4Ztn8P2K2IsEnOlFwv1cZ ZNByxa56iBbNrVQa7hbbNXauIGOkj0fM3MB75JUQK/dHnW5d19bNHRIG0vnTtczH eoVvEdMtpSF/e7S6Kzx5xfcmCQsBRX7JIHyuZpBYAgr1HxjXOrdvqgWQCWDSUtNO ybzYwNKUbSCgbp6tbVTQuskm0QKVRcrrqMPZepPcgjQ/FLB8EALqarROkJTop/3p 8YatD3iq77SdnOfmFMZCFGHzn4UaxturRdEYIfeqz2Ia0YyyH3GWs1juhazyH+CM u6HbXXrq6AJmKWLYbSK1ycUBo9OhFObT9X3XswsWa0uNtSwLveqlvaI77UHkJbnr U9Ek9V0WznV1H9hn6qJpKyS/d+M64dfGjBSo79b50IxvlKrHKBPZkdHfSUyjnMFW rl9uE0jB6oLFUcqchypJ89HUeso7fD/8l36w0Z4TkMrcAy9V0RIj6P5nBYBU1U1s cLblEvdmUqmt4t+D1o4K =YnGT -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:15 PM, Alan Reiner wrote: > I'll add fuel to the fire here, and express that I believe that > replace-by-fee is good in the long-term. Peter is not breaking > the zero-conf, it was already broken, and not admitting it creates > a false sense of security. I don't want to see systems that are > built on the assumption that zero-conf tx are safe solely because > it has always appeared safe. You can argue about rational miner > behaviors all day, but in a decentralized system you have no idea > what miners consider rational, or speculate about their incentives. > As noted elsewhere in the thread, there are two problems with this analysis: 1. It asserts that zero-confirmation transactions are in a binary state of safe/broken instead of recognizing that relying on them is a non-binary risk analysis on the part of a merchant. 2. Assumptions about what is profitable for miners are based on all miners having short time horizons for calculating profits. In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more honest node operators from patching their nodes to blacklist any peer that relays replace-by-fee transactions, and maybe even publish an IP address list of those peers? Punishing Bitcoin users for not adopting somebody's pet solution to a problem neither responsible nor ethical. Child-pays-for-parent allows for stuck transactions to be cleared from the mempool, and allows recipients of zero-conf transactions to adjust their risk exposure as much or as little as they like. It's a solution that gives Bitcoin users more freedom, instead of trying to coerce them into pre-determined directions. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99 kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/ F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5 sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0 F9dKdL5zCGofvU/U5BVq =kEMr -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 05:24 PM, Oleg Andreev wrote: > >> I think that is a misdirection on your part. The point of >> replace-by-fee is to make 0-confirms reliably unreliable. >> Currently people can "get away" with 0-confirms but it's only >> because most people arent actively double spending, and when they >> do it is for higher value targets. Double spend attacks are >> happening a lot more frequently than is being admitted here, >> according to Peter from work with various clients. >> >> Like single address reuse, people have gotten used to something >> which is bad. Generally accepting 0-conf is also a bad idea(tm) >> and instant confirmation solutions should be sought elsewhere. >> There are already interesting solutions and concepts: >> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment >> channels for example. Rather than supporting and promoting risky >> 0-confirms, we need to spend time on better alternative solutions >> that will work for everyone and not during the honeymoon phase >> where attackers are fewer. > > Here's value-free assessment of the issue here: > > 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer > instant payments solution if possible. 3. As a social artifact, > today zeroconf txs happen to work for some people in some > situations. 4. Replace-by-fee will break #3 and probably hasten > development of #2. > > The discussion boils down to whether we should make #2 happen > sooner by breaking remnants of #3 sooner. > > I personally would rather not break anything, but work as fast as > possible on #2 so no matter when and how #3 becomes utterly broken, > we have a better solution. This implies that I also don't want to > waste time debating with Peter Todd and others. I want to be ready > with a working tool when zeroconf completely fails (with that patch > or for some other reasons). > > TL;DR: those who are against the patch are better off building a > decentralized clearing network rather than wasting time on debates. > When we have such network, we might all want this patch to be used > for all the reasons Peter has already outlined. You've left out of the discussion that many (or all) proposed solutions for 2 either reduce privacy, or security, or both. That fact should not be ignored or swept under the rug. There's also no mention of the degree to which child-pays-for-parent achieves the stated aims of the original proposal (clearing mempool of stuck transactions, increasing payee assurance of conformation) without introducing incentives to double spend or forcing people into privacy/security sacrifices. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5 6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4 bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF 2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45 RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232 FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM 7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8 XjbkwrkFIuKfUJyfIuR+ =ony0 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 03:20 PM, Natanael wrote: > Multisignature notaries need to convince people to select them. > They want to know that even with collateral, their funds won't be > temporarily locked up and unspendable for days at a time. > > What services would miners provide here, do you think? > >> Well, sure. It's the same model governments use and is why being >> a money > transmitter in the USA is so difficult: you need to put up large > sums of money as collateral and have your fingerprints taken 48 > times. Then you can start advertising to get customers! > > Obviously you need to have collateral to provide collateral. Can't > make cryptographic verifiable guarantees if you don't have the > resources to back them. tl;dr: Bitcoin users aren't getting very excited about somebody's pet hub-and-spoke project, so they decide to distribute a patch that will change Bitcoin's behavior such that people are forced to adopt them. Scorched earth, indeed. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3McnAAoJECpf2nDq2eYjxI8P/iClVQKNhGPr0K4D8KktUDUS CB8Gu6Rg4VqgjzwhSd1AD1CAhSkxRRgNfHOkxeu2n1wA/fs9V/x66W9G33OyHvf4 1M+BwkiNszxvfxvZVkXyPa/eqa8/alIs1jEhb19dBRn6sJ6EQyca93PG00wDhhRU JbHeYj2pYYMuu+xRpJWhRdUOpJOsLu5E9XMocS12wun7+zQCs4QfoLVcGhMv3+Ug iS3/H1NNQJegIFMQzgi5hr7CxClZ+MrsLDO7MBEZknjr0toEJXe7c5Logwc3oF8h klhFeSnhexCHNeDSGKDhG89hrgWPSDDuuyMRa3e3L4xsT2zAFcsmw0ScCmyNSto4 gUCy1gQsShDJSvsYvqjJkOcL5UfP2WLQiVJecpblf1R/tgjC0SsBoPeRMT/DeSjV xpcjUrAUzkIBuEcunFarkt7wBvL/4pvGnbYcx3uW2YX50oO7LjCcgwJLMW4ecsvn zAoc+aXqeORo2SAI3tTJKqpnn5K2k7DVTiFt1vzHVR7OxnKa/+sXk+bCkQi9/dAL bWjiBUV8hXBVIt0UBgj7Q5wgQSoAXI0D816GIA2Qb9XQfmpRb8QTmf9kQ1DrcV68 Qt1KOHPY1yCynqLMxN3ONWu4JMF+YYwrxx47Gg7wSJr5q70mHNlLljfnfb5PNLtS J6t2/QfPTMmyN3V6xkbU =hna5 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] determining change addresses using the least significant digits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/06/2015 03:08 PM, Jeff Garzik wrote: > Yes. You can certainly add additional inputs and outputs -- and as > such you can increase privacy and defrag your wallet at the same > time. A lot could be done to make regular spends resemble CoinJoin transactions and vice verse. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU1P7iAAoJECpf2nDq2eYjeXwQAJGdVdYta5CddfL+xyFNG2+l RMxkSABfgWQF6mDus6ul+EhRhOYEveuuukbK2ibcnY2U4H9ecb8Gttno9+Wi0YfM zcu1Wt/j5cJyUFjO9owZO5gse5mTCt+1njgNIGMlXHHbFEHc5OavXEgkvh8YcL/j E8Kk4YNM5Ovp47vh1ihkB4Zo+ihu5oMuY4vbBO7So4BIe8KaSLOTsOAccT17bWGo jtd6KdjfqsLSjhQoVtuQAsx9AGUS+jfjBRWSnwkeAdd4G4BE87/7DCdYnczFKhds kVwnHODA0+5dwEwZ/ChipKVzAVLVZ2a7BXUenax70P1QgfG8WwL0tueoKviRBLfc 6Xa80GHGo84qeGEkiste1qnG4XZWwi6pnTSTwP1f5CtVvGvfYRysHsMCm82Mr7vA pwrQULv6fkhI63xB+kfcXBPr0WIVrilVrEtGcypzIbPbQgRQ6k3Wg66zLoQTc8vA w2pOZYrEU1Rmfiv27/MLdvSuWzR0kF+nidwCBxUYBuKAA4K0Y8GBH0FApp9JmCEo LXIY4RU3sCCbP3C1qloN8k99q8+CDTwrZpzi2zi3r0zRorg/1tTXqavicE9KPC2j ymk+eFFJhqG51o/d6irzA5R+hK/T2JatDhneEwTBetsrbXq0D9jiN3+KB+vME0wf KJhXhGbElNyz7eA4EOMt =zcqb -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] determining change addresses using the least significant digits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/04/2015 02:23 PM, Isidor Zeuner wrote: > Hi there, > > traditionally, the Bitcoin client strives to hide which output > addresses are change addresses going back to the payer. However, > especially with today's dynamically calculated miner fees, this may > often be ineffective: > > A user sending a payment using the Bitcoin client will usually > enter the payment amount only up to the number of digits which are > considered to be significant enough. So, the least significant > digits will often be zero for the payment. With dynamically > calculated miner fees, this will often not be the case for the > change amount, making it easy for an observer to classify the > output addresses. > > A possible approach to handle this issue would be to add a > randomized offset amount to the payment amount. This offset amount > can be small in comparison to the payment amount. Another possible approach is to randomize the number of change outputs from transaction to transaction. Doing this, it would be possible to make change outputs that mimic real spends (low number of s.d.) - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU1DH9AAoJECpf2nDq2eYjt2gP/3gpojJey2URkWWk0sg9dpHU OsD37TCbrwUaS/K8UMKsuc45FSJU/EeYpaVz9r1Ifm/IeaFYPIX0tEm17n3hkcAG QPmt/xAZn9GVyPWYKjmVDmx574pqiJLeZh8bP788sZsGc4Gk7NNJniVGLtsmvFCb ZOtwS8v7UuJZx6awydrpNhw/+SsQn9Xdb8fcLqmFKWDpG2Mlrv+ds34NMlGbfO2r PqCMw1Y12J0HXLisOCGQNZNdG9mVjKw3MP0GGjUlOM+ibrrorqoO5Ifo2RGuElgw LZkzzDzg6kO8iuNOV7Jg1lz5WftRjgLRSCcMq4V+793zGJW9BeISeDcKQ2ZlWMXB Hu83m4vCYOJeECdKGWlhyTmKNNHshsiPz3SBDLxP8uR80UkS3waDIXwLxGX9Pa63 uleaZ2qHQ/0UdC9opN3Snn33M701dHNJH9iXfhf/MVnUZ0FjzsLXaJ0F0208ZxCX qGCAv5y1ijrDlCLTvakZJRIruXgxNPqtErzP9GtgXeGeDc8tRv00WiM9Olpu0EXd yjhAZGydcE3Ec2cNo+teWjeDt4Ga4OYDb7i08eegaDuj5MCDcDtlgfwNjdKbre1x S7pKKDn8V03/WST1x9fWjM04NxeSjJ0yRjOAxkLV/mlDX6lQEYJL/W+MJLvpOnTC LtZrkSmSTJ7ZR0tMgpAe =8EVe -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] IMPULSE: Instant Payments using the Bitcoin protocol
On 01/17/2015 08:45 PM, Rune Kjær Svendsen wrote: > Hi list > > Found this on reddit: http://impulse.is/ > > PDF: http://impulse.is/impulse.pdf > > I'd love to hear this list's thoughts. > > /runeks I'm concerned about the silence that always erupts whenever privacy-hostile products are proposed. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2015 12:48 PM, Tamas Blummer wrote: > The legal hurdle to force confiscation through a wallet provider > might also be lower if the target user is not domestic. Depending on the threat model, the incentive to force confiscation might also be lower. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJUvq0CAAoJECpf2nDq2eYjr9kP/RWEg8Az43T+7qMFnrk37+y/ 0pyEQ/zisao1d0LouxyGFu704U8Qayk96hUu+2GAQpS8hHVA0CmDW8E1hqKG2nGl MTTQYp7932NY2NysIvNaQDhVErZZFqMpPYCnsSrnwUrygh+QjWAI8nvrrcgprG5/ zybzs5IJjFQ7QwYJ92D01shkqQJLYYspp2ME3z97AwPCBanN8eG4Iji/V8/aJqcZ ZqF7yUjAySVUOUzR+Vju1C7N1i9MHzIG9vZA/jkaCiqZ8bvyQTm9LwSK3quoxGAB lTplIwKjWsEvs0nm0RyurcPIWq1ppfPiWCaMCNDA5Byz3mJbSrRW5ErFgBtpYkgw CF+WqoWU8fajQjqd8xcsKJmVyQqk4dUWXJQLGnd6pC3DCZGOPhr+6674vgmEQG5A bXoBAtJfAJkxkDGEsngs4EBGc08iy+t6tJUh7+wI/La8xulM5BgJkQRTnL4Hn6KS pcgYV9JP1BWMB4fkdL81mKnG98BJ98pj019C0nuPYQtSA0rUsWG9d3NYDPe87I+K 7UJ6NlNxTLxnS7nhr8Wk9UdqkFMsCQxF/RFR6I9vCQ/FMSD+i1786I72kkyf4cWJ 4ZssTX3yo6pN/faU2cBk84PQlA2ziARXqO+jzbxVR7AFpT2BESUtBdirh1CPEMfR piBBTr6I86R2bpZYv046 =pJvU -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2015 03:46 PM, Peter Todd wrote: > But ultimately we're not going to know until court cases start > happening. In the meantime probably the best advice - other than > getting out of the wallet business! - is to do everything you can > to prevent losses through malicious auto-updates. Create systems > where as many people as possible have to sign off and review an > update before it has the opportunity to spend user funds. Not > having auto-updates at all is a (legally) safe way to achieve that > goal; if you do have them make sure the process by which an update > happens is controlled by more than one person and there are > mechanisms in place to create good audit logs of how exactly an > update happened. > > Finally keep in mind that one of the consequences of a custodial > relationship is that some legal authority might try to *force* you > to seize user funds. StrongCoin made it 100% clear to authorities > that they and sites like them are able to seize funds at will - I > won't be surprised if authorities use that power in the future. The > more automatic and less transparent an update is, the higher the > chance some authority will lean on you to seize funds. So don't > make it easy for yourself to meet those demands. One suggestion you didn't mention was jurisdictional arbitrage - don't be located in the same country as the majority of your users. Or, from the other perspective, users should be strongly encouraged to get their wallet software from companies/organizations not located in the same country as them. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJUvpSqAAoJECpf2nDq2eYj0oQQAI62vLPzFrkLZoRw3bIw5GWt 6L8dpLUviRS7ZaQlNB49TT4L4Ky+MJ1PxaHwb4YPxrVcCWDLiJb51CtODduF/9rR 8N4xoQuf/6DhsBHWJE8NDwP+9JUOlY23xdSe/BlLz9N1Ql/EV0HTCu28A9xbhK1L QHgwX3p5/ZCJo7PCARF3o+EZOif5MsA4MdQ11HhyFWN/fgww9AVOIg/0m+tIqkjR yoOzFww4AejC7nxi+Q+elljpvp2Q/Nv8cVOVlp9l4+f9P7sg0em9YUCE+iAxoZTT 7b9soUXFUjWlxFITR5RnjlDUnmra9QhBIhogBQbLelt/vdoRInz+kXxroR2x3uKh EJoet2czRB1oiRKHE4iSAv+1pnavQJDVo5/mUMzeM15zCnQ16Mfu9aOpqvijK0cw u67E4IAPJ2PmUy4sPPJ/4H4FPLmJrSUkLxxzq/4prmLLmeZZvPwjavnULHir4jyG aaxFqMkbeJSeK3hLk7hnlrwpQRAEq7om+EpQ7fAx1lmEoA3eOHaeclh7/XzDwIB4 AK/jX+1ylhGvfuKNzwTQVX8dEzaHRwLAfLfHUNnP80WhBzH5ODicwcOwwOanL6/A qgqwDSSB/Q5aj3VsThQ+PR81u/wA5t/Av9+Wn/g+AEMyzCnJcnHxDe41ZEn4UzYY +RAX1P8yzF/M2ZQUeMLh =G0GE -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/30/2014 10:47 AM, Jorge Timón wrote: > What services? I must be missing something obvious about the > motivation. I understand the difference between "paying to myself > only when I mine the next block" and "offering fees to whoever > mines this tx". But how does allowing miners to pay to themselves > in this way help with security and future lower subsidies at all? I don't know what Sergio Lernet meant about miners paying themselves and future network security. If miners wanted to offer value-added services, especially if those services involved adding specific scripts to the outputs of the generation transaction, the most natural way for their customers to pay them is to allow inputs to the generation transaction. It could also be done with pay-to-fee transactions, but that would make the services more expensive due to risk premium. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUoqXIAAoJEMP3uyY4RQ21OZUH/iI9N9bQ3TLPnmCVW6bkIitD WT6uBUhBREls2NMjyDQ//UN9F9nt+aU7jN/I0AMrdB8ngFb4r1gfxSpld9KVp6Yw k3jW8Lo3WhTnCCE0a1MbBqomsAfIwDdksZoH73QW+sGYD+cShgFC55QWfE6gy3OF pge1dsWNPlMSHmWn9+g7g3+FjkhKeZFNSb0MKzIvEBE7iJOf85etJpMs9a/425sx UcJX33bVdhG51Au3PSs+0jUljoFby28EM717otq8Tkjei2hw1yNNmtws4/NcQlh3 W6TGBZLb188hUrOOH52p2Cckm8gGgw9hTc9nSLSjQS2pPjVRpTRR4smxMTKND9E= =QBYE -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- 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] BIP: Voluntary deposit bonds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/29/2014 09:10 PM, Mike Hearn wrote: > How does adding inputs to a coinbase differ from just having > pay-to-fee transactions in the block? If a miner includes pay-to-fee transactions in a block, those fees could be claimed by another miner in the case the first miner's block is orphaned. Inputs to a generation transaction can not be similarly poached. That difference makes some services possible that would can not be safely achieved with pay-to-fee transactions. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUocjPAAoJEMP3uyY4RQ21zrMH/1f3vjac9XqOZbDItjiD6XXU EkpRUROjyQAs6/tO6dwWAIcXgulYREAJsU/udQNkTYteIDFlDzwkYL+NLXpYtwHs BiZJEEwmAEHFgOD3QmmqhTx867zIbEYIB/dpHlMOppE6fhTKFr9z6JdqAKlNcHHW tkW5sq8q9uq7StiUs3/mmZ0XXeEb84N+bPiJ9S7kuTm9QWnrF1oMLhAk4M6yX8hn 7MUowmfc9RZ4uIFkqxk6gkWJSRx7dlnCRP2TRhyABpZwAcZANuPhqBOZ6eJ6T9Fs DOJ14c5JYachXW5z8GqR+abeq0JPE76kEQt145B4degJ4DTQLLhlfdvjbuJvzy4= =Kfe2 -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- 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] Setting the record straight on Proof-of-Publication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/12/2014 01:41 PM, odinn wrote: > I think the Mastercoin devs are doing fine work I wonder if all the Mastercoin devs would agree with that statement. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUivkLAAoJEMP3uyY4RQ21r5cIANvabja0i5j79a6KSkKOgEyR LhBz4mugzTc8Zej2NBeyEtv0pzO4fs5wvQo4N/1BW7aHXuFJsgJpGlV8thkuFhek UhoPC23i7u3jCPQ30PintqvCBCimse+PJa60KE2QL2DZn7WgRGKrEuo41AROxeit vfVMcFULc6bB9hxIEBpcU4RuwKJHVgzSHMkO75/uHHtPLJ9TbCfqcxT146cZvSjc Tc62ukuX1xBj5PhQM8GaUGzkQcfcZ+7d3DD1X22Gk1U6w+zat52dapy/qYgn9oA5 ubk/p/7Kywd8D44rPsr/pbdlDZxG0w77yRJIMboXhFMV7rY3sMRHHQmAUz+I8FY= =R4pR -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2014 05:26 PM, Peter Todd wrote:> For the same reason we don't do hard-forking upgrades of basically every > protocol on the planet on a regular basis, even when we don't have > consensus problems to worry about. > > Flag days are really rare in engineering, and for good reason. This explanation is completely incoherent. Because Bitcoin has a extra consensus requirements, requirements which are really rare in engineering, the necessity of fixing bugs is even greater. There are two general ways to fix bugs: either as part of a controlled, planned, and managed process, or as a response to an immediate disaster. The alternative to scheduling and planning the upgrades which are necessary to fix the bugs in the protocol, where such fixes can be written, tested, and documented at leisure, is to wait for some crisis and slap on another bandaid when the network breaks again (like it did March of last year). Who benefits from not fixing bugs in Bitcoin? - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJUXAYVAAoJEMP3uyY4RQ21YxMH/3O+vFK2jDXV5V8IIsJnU/u1 D4gYyVm89E0zmGTyLAUYCJGj0eg5tMyUUzu62hOECOeQuKdVi+mbkLi4TiF0sHIb 8k25MgqJgzH/021eoI2g2w1FrDlZut02LNX/V09+owd1yhp+SEXZ3/+HlqsZXhsv /u9u5OayzhGlzS6apQtrosl5P+KIquHqIbtwBtPOb2rvlL0miJ6sRcAH2JCXCBDT HMcswMtIGZbgqL/K7e/6vH7dUWdp0866RZXvt7aWGNUgvxHbGMs+zsnxp4nNslxM wqL71gTmtMnLcw0GtqmXPjcjo+adrPnqp45xc9lSt23PGjxxfR0FKYIPb2uZdq8= =9GOY -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On 11/06/2014 04:11 PM, Jeff Garzik wrote: > RE soft fork vs. hard fork: It's about this time at Mike Hearn will > chime in, on the side of hard forks. Hard forks are in a sense much > cleaner, and permit solving problems not otherwise solvable with a > hard fork. However, hard forks clearly have risks, notably the Big > Risk akin to a US Constitutional Convention: once you open the door, > anything can happen, any rule no matter how "sacred" can be changed. Yes, there are risks, but those risks could be managed with appropriate effort. Major players could publicly commit to a set of ground rules vis a vis what categories of changes are and are not acceptable. Maybe at some point there could even be something that resembles project management for the Bitcoin protocol. Why not schedule protocol upgrades every two years for the foreseeable future? Spend one year achieving broad consensus regarding what changes to make in the next upgrade, then spend one year in feature freeze (all future proposals postponed for the next cycle) then execute the upgrade. The top priority should be fixing bugs that make specifying and re-implementing the protocol nearly impossible. Those kinds of changes should have little difficulty achieving near-unanimous consensus. There shouldn't be any problems separating obviously-needed changes from the ones that let third parties blacklist coins, or a majority of miners vote to confiscate block rewards from minority, tamper with the issuance schedule, etc. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x38450DB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/20/2014 12:50 PM, Mike Hearn wrote: > One thing this brings up is the never-resolved issue of whether > BIPs should document how we'd *like* things to work, or how things > *actually do* work. BIP32 is an example of the former - it was new > technology and the spec was finalised before any wallets actually > implemented it. BIP 44 is an example of the latter, it basically > documents how myTREZOR works and as such there was minimal or no > scope for changes to it. Of course both kinds of document are > valuable. You also have things like BIP43 that encourage people to reserve BIP numbers to avoid namespace collisions even if their work does not affect any other project. There should be an efficient process for informational BIPs of this type. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUR9T1AAoJEMP3uyY4RQ21ADgH/0JUnkrAzKiBrtFcoXNTEkNl 7npCPY90zQDXk0RN0sV49ralMg/j71azHKmdeH3XHPF2BG3mC4+7TejhJkDEoCoB fzVyQ/a7MSz3Hnxh0iwx/4p+8A3v6oI6h3yDJeCrwdMudGYA2OfyQuFdrSuchHp6 j0yJpdxxEwtc9A/7SKk5R7yrLqeeLs4OCk2Ep8mZfCQyWssXvlJzd0IDvYZiUHrM jwLgDCAUNIotEqF4sPzxUMCUkQH3okeVhND/WvoDh8EIrE6l48I19CfDax3gJUU+ 4eI5Ooba3SRu5a8cf3V/lgtdbpJJ4i1UdpcjeWNAz1w/P1NVrWN4uJgzUilh6zU= =OWdW -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/10/2014 05:26 PM, Mike Hearn wrote: > I'm sure this suggestion will go down like a lead balloon, but > Bitcoin Core is not the first project that's had issues with Linux > distros silently modifying their software as they package it. In > this case Luke has changed things to be closer to what users > expect, which is good to see, but I expect to see the same issue > crop up with other Linux distributions in future. The temptation to > "improve" things when you're a middleman is just too great. > > The usual approach to fixing it is trademark the project name and > use that to enforce "clean" packaging. Firefox and Chrome both take > this approach. I'll probably do the same with Lighthouse (need to > figure out the trademarking process first). > > The goal here is not to remove choice, rather to ensure people know > what they're getting. It's reasonable to assume if you do "emerge > bitcoin" then you're getting Bitcoin Core as distributed by > bitcoin.org, not a highly opinionated fork of it. Renaming a > project and creating a package under the new name is not only > better for end users, but lets the fork grow into something else > and be more usable to people on other distros too. > > In this case "Bitcoin" is already a trademark, though I lost track > of who owns it at the moment (the foundation?) but I guess Bitcoin > Core is not. Regardless of whether this is a good idea or not in general, it won't work in the case of Gentoo (and similar source-based distributions) because Gentoo doesn't distribute software - they distribute instructions which allow end users to download, compile, and install software (ebuilds). On my system I can compile a modified Firefox that still calls itself "Firefox" by setting USE="-bindist". This would put Gentoo in violation of Mozilla's trademarks if they were distributing that modified version, but they aren't, so they're not. They just distribute the instructions that tells my copy of Portage how to compile the modified version. As long as I don't distribute the modified binaries I compiled, then neither am I violating Mozilla's trademarks. tl;dr: The trademarking approach is only effective with regards to binary distributions, not source-based distributions. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUOChPAAoJEMP3uyY4RQ21DNoH/0Yb3GpF230UGfQQ7Y2qQ4Sr QTNW6hwMaLSwRvdnkAxmQf1S2I3da6AJkXcyyUavJuqw+m6lxdiA3OwUQOZblEUS HkZqajS3gpCCmYJGbHD+DT3YnvDaeIQmuacsxMTXpVWK5QleH6mSdpbomc2TCS+D JulZuSQJSB997uNKqYvQmwe0b3ImgND6omoOZABjFrLESeYgQWLFBthl9vwBLtFB DqRbyvrl6+vFzX9yObAt0+iSDkoHHkPbg2/KeUCKuJaIqvFyBo0t9dvx/tvQJupk TY39a/0MW8z524e2s2SwsZbmYXSBLTlDhkTbWR0lPQH5OOcrmH7cpEG1vsZH9yY= =tfaE -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/26/2014 01:53 AM, Gregory Maxwell wrote: > On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier > wrote: >> Two draft information BIPs are attached. > > I've pinged some people privately but also pinging the list… no > commentary on this proposal? > Regarding the BIP process itself, I rather think it's broken in the case of informational BIPs. Proposals that require explicit action on the part of others do not logically belong in the same process as purely information proposals that do not require any explicit action by others are going to be carried out regardless. The only reason we proposed these as BIPs at all was to support the intent of BIP43. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUJMrzAAoJEMP3uyY4RQ217DMH/1oGHayVo4smLM/OKeu1qqXC Xex4NNh6g7Jsu2ulfJ5ow3g7jHEDzTBp33THhUv6cnV7CpDvTC+Y24LDRrYwOBQo YuQ9u0NNtrcgoi+6vs8NuGO+yZyTyBYs1emOipsICsg42H8yhEHlrMyfOTJsO6r/ nAiqR+QH6isNOjQerd9Fs0nYQ6VANs8IksL41L8ch9YAvgKx7C8WxdcQrk/S2pNL JwD7Q729J34x34HPnOb5j5Rfm1gvQInYELBu0YBaCy7D05PZd5nPSYqUC3n35hUA AMvVf65jdQVBjvjlcqDPAPdBTQ3qjhQ+7EAWKJrwlrzhGXaWA3HpipRDUSyqzBg= =OhH8 -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: "No-Collision" mode for Multisig BIP32 Wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2014 04:48 PM, Alan Reiner wrote: > Please recap/link it here so that it can be part of this > discussion. http://sourceforge.net/p/bitcoin/mailman/message/32736455/ http://opentransactions.org/wiki/index.php/Deposit_Address_(voting_pools) Currently being implemented here: https://github.com/monetas/btcwallet/commits/vp - -- Really what's so annoying is how the BIP numbering process is handled in such a way that proposals can be silently pigeonholed. Especially so in the case of an *informational* BIP which requires no action on anyone's part (except for not using the same BIP43 purpose code). We resolved this by changing the naming scheme for our proposals, and their associated purpose codes, to not rely on centrally-allocated numbers. https://github.com/Open-Transactions/rfc/tree/master/bips - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUIajuAAoJEMP3uyY4RQ215dQH/1GNOmZd19/e2Ys7MNFx0gqz rDmTFBylU3lhJrMY4CDd4Duq5+2U7HgaovqgX8UqxquHWLQUwEzZLqdEPCifLg0c d/u90cRlClFAaOxPh4HV2/3aZoS2R27N+ZjOfziW7RZySBP/2fMt4/ra+SPbkcAQ oeplYgqMRDqW52C/o2zm4y4yb0TJPS+lzSNM+JfxHSPRyY55l0KzLJfUNz1RSOze A8UAwdsLiJROKPKiSrQcqFOejPV7uqSPh10ukm/AI0k8TbvX8ffGQ083394M9IuE DB/1eyeLQVP5+lQMWNrTHk3BQ75XBEDJoSukaRENcqxtHV2m1JzTWoS2CQBXi2M= =TwI3 -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: "No-Collision" mode for Multisig BIP32 Wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2014 04:16 PM, Alan Reiner wrote: > P.S. -- "No-Collision Mode" is not a great name. Happy to take > suggestions for changing it. I'd call it a "voting pool wallet", since that was the original application for this arrangement. Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte 4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5 L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB 88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54 msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM= =t/xp -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?
On 09/15/2014 03:08 PM, Jeff Garzik wrote: > Such guidelines are a perfect example of why PGP WoT is useless and > stupid geek wanking. > > A person's behavioural signature is what is relevant. We know how > Satoshi coded and wrote. It was the online Satoshi with which we > interacted. The online Satoshi's PGP signature would be fine... > assuming he established a pattern of use. I wrote up an example of how the WoT and the behavior signature might be combined via a game: http://bitcoinism.blogspot.ch/2013/09/building-pgp-web-of-trust-that-people.html tl;dr: "Identity" is not a name - it's a set of shared experiences with other people. Identity systems that want to be successful should focus on those shared experiences rather than names. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x38450DB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/23/2014 04:17 PM, xor wrote: > On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote: >> Encryption is of little value if you may deduce the same >> information by observing packet sizes and timings. > > Instead of spawning a discussion whether this aspect is a reason to > NOT encrypt, you should do the obvious: > > Fix that as well. X being broken is not a reason for not fixing Y. > Pad the then encrypted packets with random bytes. The fact that > they are encrypted makes them look like random data already, so the > padding will not be distinguishable from the rest. Also, add some > random bias to their timing. The packet size and timing issue will become less of an issue as the network grows anyway. One transaction inserted into a 3 transaction-per-second encrypted stream is more obvious than the same transaction inserted into a 100 or 1000 TPS stream. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJT+MZWAAoJEMP3uyY4RQ21tDoH/0SPYQcUkYJcuDhTkJCFWdyx ob3H7ITEcqD0UZ3n3QHdxHfCDlP2srL0EcfjbNceRX5inP47jdoGj7uIkY/NRHQ0 4J2WCIrcu1Bj3ZxXG59PtfUzMjxhMGDMSk5eE+6BjVQILrkxxrqSpVjykfoq5s6Y EBdT2Pf4djQ5k2fQ2PX1dTt5iCvFh0ufq3McrYsciRzguRwlelw1W34tPBqGSv0n LScgvqYUTGC7otUdA5K/3WBq6SSo7E13hJxiLKQZMQ4CPpSlsiAhI5fuhl0OBljC hCtS+eugFmvMICQt0ELds++nnA5WN/Yjx1WIrnLA1EmNiAkS9RSEVMcyab0TtdI= =0sjO -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/20/2014 12:16 AM, Peter Todd wrote: > The easiest way to do this would be to make the Debian/Ubuntu > packages depend on Tor, and include a install-time script to setup > the hidden service. I've verified with the Tor devs that they would > welcome the additional load on the Tor network that Bitcoin would > add. The easiest way for the people who operates nodes would be to compile Tor into Bitcoin Core as a library so that it "just works" when turned on. -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJT8/B9AAoJEMP3uyY4RQ21YbcH/1golU27alo57cfCqjMei6uD iJ69NMQ6wO4U9r8VX8Rwkd/8IVK+gP4eJNRj4FlUNU0eXFcXj3zaCpnHnO30OEPV tdx/dyd/sq/gn5WL3m29MsP5ZVX8pIIH8aQ6jjLWC0SsE6KUJeK6f48o/XST4kMn a5w1YkUW1Mo/1lLmIlTnmapNrMYq1VppOi0F8AaRgMjTkoX/aGOgu6yIlGJXjAbA E8zlIvmLBcMq3aGNrlpE5WJBG1UQr84GYxjSQ1evL1PsllkxrSH3MODtESLYTMqB 77ZpGNbm3Ndgxvr03pXhXPGbrug3qX92fbKI42XkSC7n/pWLe5YKUiAukDN4NjU= =ttua -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/19/2014 11:38 PM, J Ross Nicoll wrote: > That's not great, certainly, but how many nodes actually require > that level of security All of them. While the rest of the 'net is busy deprecating HTTP and all other unencrypted transport methods, why is it(*) even a debate? Security should be on by default. Make users who don't want it jump through hoops to turn it off instead of the other way around. (*) where "it" is the desirability of blocking passive surveillance, not the particular algorithm to use. -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJT8+AdAAoJEMP3uyY4RQ21kv8IANDkveCGJX5b5c+waXTHcEf0 MgrGlkUZgZaP+fNNME32MEeQMywkyHohZly1KKYyqf+Qi2YkZ7rFiZj5e16EtGVK zBQCrvOyMZVv/tWPfRxrZV+jC5dUBPryaCV3XwyK3w8u5WpDhpC1be6uBjY6qtTB 58MzdMBEEwceUwDezAIpGxsr5fKw+by4WyL23HQybSgUSHWh9S9hSp4dY1L8sDdr atdFOvjiwY7zQe9V4mrtSv2pwmWIfOJE3RBhwSdPBtsMqO0PAnUEmxKYANQjh8qV W147aQT97DYkWb3TucY+gVbsfKSzvNoiXwvWMpmXT1Kz8wia0vX7MoPBtO6+uOk= =6tJk -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP43 Purpose code for voting pool HD wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 We'd like to reserve two purpose codes for the HD multisig structure that will be used for the Bitcoin wallets used for voting pools, so we've documented the structure in the form of two BIPs. One is used for the wallets suitable for storing bulk bitcoin deposits, the other is used for storing colored coin deposits. The primary difference is that bulk deposit wallets use cold storage and are allowed to incur significant administrative overhead, where as colored coin wallets do not use cold storage because they must be capable of being generated on the fly. Two draft information BIPs are attached. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:jus...@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJT84VCAAoJEMP3uyY4RQ21LZcH/RYN5dUc5TjOI6Z72I4aNqDL cZMzIo1WTK6OHsO2GUo+3L4avf+dCb2om/hDJgoLz/Oh9BMY77vF3UTIPIzGmN9X 2Oeyjg+wJG9z2L/B1f7oo4MX9c2ppUNfp2x5zDaURvME9CLkY7hLCBWp/OxU1HHb MhLn0ICtpw3FnHddVWFwhvBxcCzJm6t2pBlM8mmTr4t52/08gklY1LVdUW0zmf9W eFe50Y2KQ+uhVZfAga1wmFwY1pJBUmf6fAVqeK6AGDPkLVHDvN8P+mco+Qks++VZ mTENKXWAmskGViTjd0pb8EdoSoMsDIa1eRHbpwAbbb2PEoc9pdccgwH6CscgN1I= =R/HX -END PGP SIGNATURE- BIP: BIP- Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets Authors: Justus Ranvier Jimmy Song Status: Draft Type:Informational Created: 2014-08-11 ==Abstract== This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43 and is based on BIP44. ==Motivation== The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed. ==Path levels== We define the following 7 levels in BIP32 path: m / purpose' / (5 color definition levels) / address_index Apostrophe in the path indicates that BIP32 hardened derivation is used. Each level has a special meaning, described in the chapters below. ===Purpose=== Purpose is a constant set to TBD (or 0xTBD) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification. Hardened derivation is used at this level. ===Color Definition=== Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits). Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used. Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function. The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels Public derivation is used at this level. ===Index=== Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. Public derivation is used at this level. ==Compatible wallets== * [[https://github.com/conformal/btcd|btcd]] is the reference Bitcoin wallet for voting pools. ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] * [[bip-TBD.mediawiki|BIP44 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]] * [[http://opentransactions.org/wiki/index.php?title=Voting_Pools|Voting Pools]] BIP: BIP- Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets Authors: Justus Ranvier Jimmy Song Status: Draft Type:Informational Created: 2014-08-11 ==Abstract== This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43 and is based on BIP44. ==Motivation== The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed. ==Path levels== We define the following 4 levels in BIP32 path: m / purpose' / coin_type' / series' / address_index Apostrophe in the path indicates that BIP32 hardened derivation is used. Each level has a special meaning, described in the chapters below. ===Purpose=== Purpose is a constant set to TBD (or 0xTBD) following the BIP43 recommendation. It indicates that the subtree of this node is used
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/19/2014 03:30 PM, Richard Moore wrote: > Oh, I see. I misread, thinking you wanted the dev team to have a > private key and share the public key, similar to alerts. But each > peer would have a public/private key pair and use something akin to > ECDH for a symmetric key and transport using a block cipher? > > How would you share the public key? If I were a man-in-the-middle, > I could intercept the public key, generate my own and pass that > along and then decouple the pipe when the other side shares their > public key. > > Also, you should not ignore your SSH fingerprint, as you exactly > open yourself to mitm attacks. http://curvecp.org If that's not acceptable, even using TLS with self-signed certificates would be an improvement. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJT83Y1AAoJEMP3uyY4RQ21aqUH/3rGvgz3J6UYY2Qb2qzNoucB QqIj4fByZncX7Fhx5YK6fc6QoLr4Oqxd+zgbJ3ghrLtAJ7dm61iLmmib8MuDz2K1 kQj8xmZhWuUFI26bjK54RlKoWg46XFKNKcaVub6JmVg9dH8mX86mF746KnR5ZqdX BuehWoEqcHlY3JkrTgOGpHjT/EGScZQxzJHzsBOfUJuX12lFtzcWzBTZyo5K8fD+ 6eub3i6Fc4qn/c788UVFsmHeWV+NCeB1/y94V1+peIPWYhrZO+FVm+xEflG4U81Q MRejqNjFT8ztT5vRHx1qJsmIgnzT0SXfh+FRt0hdqJizjlmyntMmCXjFmtnIeT8= =9qWl -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [ANN] Armory 0.92 with Decentralized Multi-sig and Simulfunding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2014 09:50 PM, Alan Reiner wrote: > (though, in the future, we hope to provide an optional service to > help synchronize the data between parties) Before rolling your own service, it might be a good idea to add Bitmessage integration to provide the P2P communication layer. Even if you resolved to create such a service without creating any negative privacy or confidentially side effects, I'd be more inclined to trust Bitmessage to get that right in the long term, because the service you'd create isn't your primary product or core competency. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJT2ovhAAoJEMP3uyY4RQ21zw4H/3vjcZXP6e0/5IG745PDy/AC Br1ChlyQjBpU7X9CQfrxDmUUGs7HDrwLjd/SZAV1/PUUXXfE3nDr24hsF8+PlGex AiZhO7k92xfwRMWxMmcVVt/kuaOldHZUqHDUenT3drJ/bPnV+R3FJ9O6Ougu/YVy H2BRjpdPGrZx9NP/hE/7evA7rPF8pcshpMBiwq6RiHFdu/+2jcThFZoMIaJsAcif 1vZOzP6vTUKkr3E7tRt5ZQrdb4vvGxX+xMomm8fzPmV3GkpJ/Kyyypx+ovaH74V5 oXXg62XRz4lSziWV5Sp4p/18VjRyUkxwvfXXMt9sW6vNvRDxtJNP8/ZKpkMjO3s= =ClEd -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Plans to separate wallet from core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/24/2014 09:07 AM, Wladimir wrote: > My main argument for the split is that full nodes and wallets have > completely different usage scenarios: > > - A wallet should be online as little as possible, ideally only > when you do transactions or want to check for them. > > - A full node should be online 24/7 or it is virtually useless to > the network. I think btcd has done this right. A wallet is a daemon that runs constantly in the background, just like the full node. The GUI (which is distinct from the wallet) runs as little as possible. Presumably there's no need for a 1:1 relationship between wallets and GUIs. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTqZpVAAoJEMP3uyY4RQ21E48H/0XNYBzR8QZjfku/MeL5IbwL A56jrlWe2EZTabwfKdGx12L5oeBXe3DOeLsTizqIu0vijcl7qQryU49AjrVe91Rx OdEi4lmaiXdkM3lWeWUxLoLLHR1B+1f8T18Mrnzo+yasyrywPb+6H79VN5KERdA2 5yHYCZyHXdNoXpzyf38GC2PdYJmAZdrRfAGyC5+OXSwE3XLhpRBrSBh/mrx0ct5M ghkCKtsmJCJJ6sR2TbFxaj71kPp0J0tp8JVvjVEqC2uB4Ih0NY+79kz8L81TaNmw ol1o6p7TypIk7QRQ4ES3Fq0ALh2aQ/tX4rc0GC0ed+xLi+dHJ2wGBI37HoyGIyg= =Nn9X -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2014 05:11 PM, Kevin wrote: > Why do you want to punish pools? It's part of a general trend wherein people look at all the things that can be accomplished in an economy that has a division of labor*, and see some misbehavior at the edges, and decide that rather than fixing the misbehavior we should throw out the entire concept of labor specialization. Hating on labor specialization as a concept, rather than simply finding solutions for specialist misbehavior, was the basis for scrypt mining, PoS, and MaidSafe. (*) http://www.econlib.org/library/Essays/rdPncl1.html - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTox/JAAoJEMP3uyY4RQ216F0IAKo26MEK/IrIlHMw4UYsWBWK LWWLe4mfUb+I74ZHPzC2ZE7u6Lf6vAeeG/mLe8K/ls1qBJk9ae7bsA+DVvRn8LfW Ir/seYtCCnLpxhHGbVtYOeWaS+WyOWMKBz1moOTJcgWwPPiL5BLk9SvaLqgy2GDV fJeniqtkZ96Vzif1DNdQtiLfn9aJRL2Er0EO7VL4ojmaM3Bv6Z6l+e0eLVVh8DKe u1Sp4UOpqJmVHJq+9EeMhdfmOqNWGUA5wFRiDsWfzUDHLkAlISM+sFFSD0CzO0RK P5whGxo58bSMigbQYOfoTZqgKQefQeXAqtlnrLOLq9/EOZ/34cJET5Z0S/K/F5E= =3KMH -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incentivizing the running of full nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2014 07:00 PM, Justus Ranvier wrote: > There can be multiple independent transport networks for Bitcoin. > > There already is: ipv4, ipv6, Tor, and native_i2p (out of tree > patch). > > As long as multihomed hosts that act as bridges then information > will propagate across all of them. -- Justus Ranvier > - sent with R2Mail2 > > - Original Message - From: Matt Whitlock > >> Now another concern: won't this proposal increase the likelihood >> of a network split? The free-market capitalist nodes will want to >> charge their peers and will kick and ban peers that don't pay up >> (and will pay their peers to avoid being kicked and banned >> themselves), whereas the socialist nodes will want all of their >> peers to feed them transactions out of the goodness of their >> hearts and will thus necessarily be relegated to connecting only >> to other altrustic peers. Thus, the network will comprise two >> incompatible ideological camps, whose nodes won't interconnect. Also consider that currently there are many people have already demonstrated a willingness to donate bandwidth and resources to the public by running nodes, so those people aren't going to disappear. They could operate mixed-mode nodes, with a fraction of the allowed incoming connections reserved for free peer, with free connections might be limited in terms of time duration. Bitcoin-accepting brick-and-mortars would probably allow free access to anyone connected to their internal wifi to facilitate people wanting to pay. Crowdfunded free bridges, assurance contracts, etc are all other ways to let people get into the network with no upfront cost. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ 197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpWMVbWHviYiZ7UufmzMgwPtfMCsQAxSb q3OMAkcSGJZL8pcy9/9NWpOGAHY2DRtGtu8oSqXcBSW/IQCubmUNmzopt8O/H74= =9hrW -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incentivizing the running of full nodes
There can be multiple independent transport networks for Bitcoin. There already is: ipv4, ipv6, Tor, and native_i2p (out of tree patch). As long as multihomed hosts that act as bridges then information will propagate across all of them. -- Justus Ranvier - sent with R2Mail2 - Original Message - From: Matt Whitlock Sent: 2014/06/16 - 13:10 To: Mike Hearn , Justus Ranvier Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes > On Monday, 16 June 2014, at 7:59 pm, Mike Hearn wrote: >> > >> > This is a cool idea, but doesn't it generate some perverse incentives? If >> > I'm running a full node and I want to pay CheapAir for some plane tickets, >> > I'll want to pay in the greatest number of individual transactions possible >> >> Peers can calculate rewards based on number of inputs or total kb used: >> you're paying for kilobytes with either coin age or fees no matter what. So >> I think in practice it's not a big deal. > > So effectively, if you pay for your bandwidth/storage usage via fees, then > the reward system is constrained by proof of burn, and if you pay for your > usage via coin age, then the reward system is constrained by proof of stake. > > Now another concern: won't this proposal increase the likelihood of a network > split? The free-market capitalist nodes will want to charge their peers and > will kick and ban peers that don't pay up (and will pay their peers to avoid > being kicked and banned themselves), whereas the socialist nodes will want > all of their peers to feed them transactions out of the goodness of their > hearts and will thus necessarily be relegated to connecting only to other > altrustic peers. Thus, the network will comprise two incompatible ideological > camps, whose nodes won't interconnect. signature.asc Description: PGP/MIME digital signature -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incentivizing the running of full nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2014 04:25 PM, Matt Whitlock wrote: > How can there be any kind of lottery that doesn't involve proof of > work or proof of stake? Without some resource-limiting factor, > there is no way to limit the number of "lottery tickets" any given > individual could acquire. The very process of Bitcoin mining was > invented specifically to overcome the Sybil problem, which had > plagued computer scientists for decades, and now you're proposing a > system that suffers from the same problem. Or am I wrong about > this? If you allow the solution set to include pay-to-play networks, and not just free P2P networks, then it's easier to find a solution Imagine every node is competing with its peers in terms of relevancy. Relevancy is established by delivering newly-seen transactions first. Each node keeps track of which of its peers send it transactions that it hadn't seen and forwarded to them yet (making sure that the transactions do make it into a block) and uses that information to determine whether or not it should be paying that peer, or if that peer should be paying it, or if they are equal relevancy and no net payment is required. Once any given pair of nodes can establish who, if anyone, should be paying they could use micropayment channels to handle payments. Nodes that are well connected, and with high uptimes would end up being net recipients of payments. Mobile nodes and other low-uptime nodes would be net payers. Now that you've established a market for the service of delivering transaction information, you can rely on price signals to properly match supply and demand. People who hate market-based solutions could always run these nodes and configure them to refuse to pay anyone, and to charge nothing to their peers, if that's what they wanted. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTnyRMAAoJEMP3uyY4RQ21XwgH/RPlhgR63XF9/Sm+z0EBxVtO 0hzDngD0iTO1v5LRmas9P5ZuQ97j8169pui+EJO8clXjV41yEu96jc0BiOQTnfMR rzPfgeZqfnVNDvIfJnLRMeVCJMiu9Tjdqx83S28Tz9sx/sgy1uw9INX7M7wOIHFR 7GLA16k4g8qcmnX89XXM3Uf7/3fhL2kiN/E59V2n6qYJAnYTUEb+uehclzR+T4v4 93oAF3TjgLU6J0VleDrvgFcyLriGBjOmkTAvmOJQF1H/s4gzHol5kbOb9vqQ7BJX QQ/mEYHEdCHTxU59FdZ5CmFYZrINHj+mNnu1RorYYF1FLbBDTDpq4zjrJpngayI= =9qQJ -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Working on social contracts (was: Paper Currency)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 11:07 PM, Gregory Maxwell wrote: > I promise that if bad people show up with a sufficient pointy gun > that I'll do whatever they tell me to do. I'll make bad proposals, > submit backdoors, and argue with querulous folks on mailing lists, > diverting them from real development and review work, all as > commanded. Maybe I'll try to sneak out a warning of some kind, > maybe... but with my life or my families or friends lives on the > line— probably not. > > ... and I think that anyone who tells you otherwise probably just > hasn't really thought it through. So what is the point of > commitments like that? People change, people go crazy, people are > coerced. Crap happens, justifications are made, life goes on— or so > we hope. I presume you're familiar with the concept of a warrant canary, so presumably you'd also see why public statements such as I was discussing would be similarly useful. Social contracts make it more difficult to hide coercion, which serves no one except the attackers. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTenU+AAoJEMP3uyY4RQ21P1UH/2fvYa7Hfv53eXA0k9appRVI 8KWpH2D95zCo/s6kIeKZtmEzhFWFkKxOHwiHZbD5JokG+U/vUeR8p+SxF1/xUc1X 1tTNAjfAALz0/KzjPKmlMQCqM5vT4yumHsDusqPuzbPFnJnwFufrAW9vWu9OJacs JEv4yoRGNZhR+eM8hCUkDfTtj7D8J3gMYyYds7K4kppiHN2UPRgZT6TCVyCRlThe 8w9MzYoTAf1WXPmzvSfPhzKMfNV9Y+tjt6ZV+KyLG1ZGLw2EDCxJR1O23QQE8IfK 53I2RgeFnvcdceoExSfYJj+kNpbPQ/WDVszswO5esoMWJ/E3j5PCBsLdGt+8e7I= =BysA -END PGP SIGNATURE- -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Working on social contracts (was: Paper Currency)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 10:06 PM, Mike Hearn wrote: > Sorry. I will never agree to the concept of a relevant idea so > dangerous it cannot be discussed. That's medieval thinking. If you > would like to create a parallel development forum where people have > to swear an oath not to think bad thoughts, go right ahead and do > so. > > But I'm glad to see you correctly identified yourself as one of the > people causing problems on this list. Your vicious attacks are one > of the reasons we're now seeing threads that start with "I hope I > don't get flamed or laughed at for this idea but " which is > totally unacceptable. I would prefer you just unsubscribe, in the > hope we get a second chance from some of the potential developers > we've lost. > I'm glad to see you correctly identified yourself as well. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTemXNAAoJEMP3uyY4RQ21KNUH/12vTPOPNjQQIunTkNCSqV6P hub7mrW/hS4NSlK7P3Laq5qj+qB9ou/uIRCPP6uIhk6scicbukn31nw1p/er0YoQ XGFE+SmF+Z5Ysz/5uA1OP9VdjBKggbI6rFVZKbt5DwrFK0gCDMtgcxO2y6CFGR+U mFhD9ORf/NdAozFanXSEk81p5OfZqhhnxaPPpPnwQeojtLwE20reLrEcCKy6XMEs Mtfan+qgPJYTmWiWmDHsrFsz+5HwpkR5giDf4hzW5J1F8Vj+LTPXjGz9Txldk89t 0dRmYFAtE74QgXsIRvWny9ho4YL/Nn+WHf0Qf3HKh31wrzSea0KFKpPaa32xpKA= =jIov -END PGP SIGNATURE- -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Working on social contracts (was: Paper Currency)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 09:41 PM, Gavin Andresen wrote: > Now I'm really confused. > > Why would Mike or I have the authority to write a "social contract" > to promise anything about future-Bitcoin? YOU can make promises about YOUR future behavior. So can everyone else. The rest of the community can keep track of which developers will and will not make promises about what changes they will and will not attempt to implement in Bitcoin, and they can use that information to make informed decisions about which software they will choose to support. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTemMNAAoJEMP3uyY4RQ21KJMH/1MbnPxZ42sjVjEiGSQBkGfE E3jt8aAf2DTza8xtybSmT/pHVhx/VUT4UNj9oBZayqJ1eUNr6YMgGCP8J+DxBtN+ mYH4lTnCiR4+hjO9aux0AWFV+hfZSq7A41QH6wymLa5CyywOtc+i7i3qU5ZGrbtX 9yBrQpFilvMIlrAOBDlXUwb06FDK17ZHHX4V5sI8PSRYJvoiWCrk12Vqj1Z95UOy ayzWGwbO30ky6lGirBXfpu2e2WJADE9sc43ecNCDplUMR4D4n9jwAUldEiMSBKg2 pwUNcfj1gaKkscj4QmGKMbq6yug+lrSa8qq/jFsbQq+2pqT4VjlQlrN52wz7Yeg= =Jafe -END PGP SIGNATURE- -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Paper Currency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 02:21 PM, Mike Hearn wrote: >> Submitted with humility and some fear of getting laughed out of >> here... >> > > Off topic aside, a bunch of us have lately started to think about > the atmosphere on this list and how to improve it. Nobody should > have to fear getting flamed or laughed at for proposing ideas, even > if they turn out to be silly ones. Gavin talked about this in his > Bitcoin 2014 keynote and asked for someone to solve the forum > trolling problem. You and Gavin could do a lot better by working on a Bitcoin social contract - a promise of what features will *never* be added (or taken away) from Bitcoin, because despite what you say it's not acceptable to propose anything at all. Maybe start with things like how the Bitcoin protocol will never be changed to allow for confiscation of funds, regardless of who might demand such a feature. You are willing to promise all users of Bitcoin that you'll never propose to steal their coins, aren't you? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTekt4AAoJEMP3uyY4RQ214QgIAM3DdtAUTG63FG/r9Yg4dWb+ TXWoXRd9AYDg/SAirF6qV+r6K0vohMv8UJhCpX0OnNSOfxKcgVt2CnG8i3iWBRu1 V+LRFmaHkJ+vJLaR2lEdFKMc2DVuZUIXGH6jEgVo/dzFJGZ/GcoUwTBrZztjCHDy WbpuuIfV2ya1bqkhMOn78pDgkDfXBD7qWQsz0MTzSkPitT0AnUEPxCl3KBWizkdH shGwE4YNhRSX+yTBaFHVMqFb9LzExEWgIgkgghddKfJzj9REcw6wiotD3DvYaDl7 LPegCttg0vdG4YTVlTH0iMwFYC3qrw/Ab43uqLjTy7aWyFjhsPtKceTE3KpGDrk= =dRhy -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About the small number of bitcoin nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 09:11 AM, Jeff Garzik wrote: > Meh. I like example configs, perhaps tuned by the distro. If the > distro (_not_ Bitcoin Core upstream) chooses to install a > bitcoin.conf in the proper location, that's up to them. > > >> - bitcoind and Bitcoin Core should be in Linux repos: > > Agreed with conditions: 1) The distro MUST let bitcoin devs dictate > which dependent libs are shipped with / built statically into the > bitcoin binaries/libs. 2) The distro MUST permit fresh updates even > to older stable distros. 2) The maintainer(s) MUST be active, and > follow bitcoin development, release status, etc. on a near-daily > basis, be able to respond quickly if security issues arise, etc. If we're talking about making bitcoind behave like a proper daemon, then syslog support should be on the list. Also, the option to store things in FHS-compliant directories (not somewhere/.bitcoin) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTebHTAAoJEMP3uyY4RQ2170IIAMDcx5rj/ZlCTJTOJ2sFttFM miK9t7oewJ73UpgvFniCUngfjk9Tt5knmskQYEMQ5C9Do/P3Deh1gF6MBBuuai5G kDNDv51zMEqhwGcqGrPYFMV3NEnBEjullTMgJFvKJf1kZRo7uplwp+eUhILjgSY5 mZjLIUK8iKDNn+Pi8/2UetAvyaRibHAsAnkJnEeOoKAhxUbtzjgZsj08loCCmJrs RleOTLgArdc33e1bwTTwsS9DDvF18RNTACglsc75Oz0ohHyc5U1A1hBfaRuyu6Fv 8BK+0KPg/zdBCnM1m3aueVukg9p3kIfB2VUVFBHBTo4CPMi91k6oldbfRHy8dXw= =SjxO -END PGP SIGNATURE- -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2014 02:13 PM, Mike Hearn wrote: > I do think we need to move beyond this idea of Bitcoin being some > kind of elegant embodiment of natural mathematical law. It just > ain't so. > I think everybody understands that Bitcoin has a positive net present value exactly because it, unlike every other digital currency which came before, does not include a feature that allows for balances to be confiscated. Implementing any such feature, to any degree at all, would render Bitcoin completely valueless. There are two possibilities here: If you understand this, then your proposal is a malicious attempt to undermine Bitcoin. If you don't understand this then you suffer from a very serious case of economic illiteracy, a case so bad that your continued participation in Bitcoin represents a clear and present danger to all Bitcoin users. If you can't even get the easy questions right, then god help us all if you're ever faced with a difficult one. I don't have enough evidence to distinguish between the incompetence hypothesis and the malice hypothesis, but it doesn't matter. Regardless of your abilities or motives your proposal is unacceptable. If you want a currency where miners can vote to steal from other miners then implement it in Hearncoin and leave Bitcoin alone. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTX/2dAAoJECoisBQbQ4v0jAoH/R1oNZ1tVp6DJ5BuPg0ZTav0 Dvzq8EfX/uRbRgmxotCHMwY6FJCoXqJTLyOnl2p670t7l5ZXqd91MdKKP2z7jYPY GsVbqfGreF0dWKCd0mKTG5DM8pxndNWteGIsw9/sYvY/3p2Vopzp6N7fpl8TEf6p 2nyIzEqTD4aK5QkhM+sNnP1Cyh/l5AjJTES23GqSQIMG6vzLgqE8kyze+ANFVg1U yka6bz4DX7DO7meyJyyOFaMJu6mgY+m6dSVaR7j/QmQMu22SwlSiPgqe6iO//os3 zcmwe/x4+5CmqJOO/PL5Or28iw/Qdf6vNePiaEIFtBzoKnHBhS2nAtL6jnOL928= =4yIu -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 03:37 PM, Jorge Timón wrote: The 21 million bitcoin limit is not important because of its exact value, nor is it important because Satoshi picked it. The 21 million limit is important because users hold bitcoin based on the promise that the block reward will never be adjusted ex post facto. The behavior users are relying on is "The bitcoins you hold are forever a calculable fraction of all the bitcoins that will ever be issued." That's what bitcoin holders agreed to, and that's what can never be changed. The fact that the number is arbitrary is not relevant. We can agree to meet for lunch at some arbitrarily chosen time, and the fact that the time was chosen arbitrary in no way means that one party arbitrarily choosing not to show up doesn't break the agreement. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWUTWAAoJECoisBQbQ4v0JiwIALQtf4GrNaIdEidJr+f3z8G3 smDgU5xXhN4+1Eo5xU/ZmQy03tU5E00/PRiMTHz1RNXeO+w/iu4PlAJN7pk5oy75 QzDtaCzDjKMCN+1PCQ5VNCL04ws8JifU6QLxSgXgsShBnv19FlxiejgvjNWg+Lzc uHxyP0PlvfF5BWTiEV68KYcfQPbamOH7Vb8v4tQ4/j/ioA7mYso+Q0jX0Y4ae1FN XNs4KnTsIFTsXWzBIYFlFPwQ5d+mdG84W7FpmwwcXaRWQxMwdJq8QjlUuFng439B 6OgQqtq4wmvwoPjKS5nOesfdrdH9Scx2zg6uwhaY0zKMtPW/CEzzLFUfq+cZ6q0= =r+t0 -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 06:37 PM, Mike Hearn wrote: > If you want to try and argue that the development list is the wrong > place to discuss development, please do so on another thread (or > your blog). Let's keep this thread for discussion of the original > proposal - ideally, discussed with the dryness that a topic as > nerdy as distributed consensus algorithms deserves ;) > Is that what you say to yourself to quiet your conscience at night (assuming you're one of the non-sociopathic humans who does indeed have one)? It's "just a nerdy distributed consensus problem"? The things you're talking about fucking around with have real life implications for quite a few people and your casual dismissal of this is precisely why I responded in the way that I did. What you're doing is reckless endangerment and you're not got to get away with brushing it off as a mere technical detail. Sunlight is the best disinfectant, and this episode is demonstrating to the world exactly how averse you are do that kind of transparency. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd 3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1 V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ= =L5nX -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 06:15 PM, Peter Todd wrote: > But I also agree with Gavin that the bitcoin-development email list > is a perfectly good place to have these types of discussions. I > myself have used it repeatedly to publish ideas specifically due to > wide readership and multiple independent archives. A development list is a great place to decide how to implement a technical feature, one that feature has been deemed desirable. The chief scientist has a platform via which he can publicly announce proposed protocol changes. Anyone else could do the same. There are conference happening all the time where people can announce ideas like this, to give time for the community to hear the idea and generate feedback. There is absolutely nothing so urgent about this attack that requires the consensus process to start here, in a place that most Bitcoin users don't even know about and wouldn't even know which search terms to apply to look for such a discussion if they did. >> PS: We don't even know who runs BitUndo. They seem to have lots >> of money to spend on web design - I wonder where it came from? > > Actually we do: Eric Springer > > See > > http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/ > > https://github.com/espringe - joined Feb 11 2010 > > Anyway that's just twitter bootstrap or something; I hear the > wizards can pump out a site like that in a few hours. > I stand corrected. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWARRAAoJECoisBQbQ4v08kkIAKMSSCn9mBCMj6RwWHK6abud UlaKOAh4LNAaJ+pIQD103EGH3JE9pzeaDouupTbdIHqb8CxVO3dn9UFXdfkDW1cf YsOOfE0N5crfaODd+NU6jjaf5jXOgmT2ibCU3sSjmphDBMstZfrSaCljtyaj290Y urnW1pdL5ZA0zLAUjNO2kXSbuHaE3CTz72s4dWsiRBsQLVAD8j5C5o8gxFVeZd7s Ba4yGtGAsd0HWikUjE2L4G/J8RzbxUrm5w31A4lawkF+SqtJcFiwoxrXX+FVdi/8 rfAY/l0EBoRrkW+cajcj29eq1eOOIER0Zcu2FzpPc45Xywh9RCh8C3zgWitOvcI= =IR+Y -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 05:57 PM, Mike Hearn wrote: > I'm not going to bother arguing in replies to a blog post. Suffice > it to say, miners are already handsomely compensated via both > inflation and fees for doing their job of preventing double spends. > Your suggestion is people should pay them EVEN MORE for simply not > being corrupt. My proposal is simpler - how about we find the ones > that are claiming people's money via coinbases yet not doing their > jobs correctly, and take the money back (or destroy it). I think I > prefer that one. Miners that are maliciously double spending cannot > justify their existence, they offer no useful service and do not > deserve compensation as a result. > The integrity of Bitcoin is more important than you and your personal preferences. You don't have the right to decide which valid scripts in the blockchain will be disregarded, and neither does anyone else. If you don't like what's in the blockchain, you and everybody else can work within the protocol to orphan the offending block. But if you fail, then what's written in the blockchain is final and the sole purpose of the network is to enforce it - deal with it. PS: We don't even know who runs BitUndo. They seem to have lots of money to spend on web design - I wonder where it came from? - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWADBAAoJECoisBQbQ4v0A/0H/25j9bvZaEqfyLJSHNh7PGwC TpMu0s8D94nX/ipwaOjeY1QMtnWnX9b2H/lDZSnk1rm7IXJTq1c+R/50Uqx5U9QI oYnsKX1TiB+T5Uv0C5PaIptEMgPkcNyHwsdXyaaUcu2djB0/YhFRlWR7WCH2QyNG 3LR5XWLGJz7v6rDxwvMXEHJWO5950bASP1xCVLc/N0PI7BoEUmeRzAoDa1mGJ9yw XkVUVDV03B85uTSEriBuQ49ASvv9faAhcehwRwvFFp2krVz6Ov5Jxrv7UN+B61R2 sgZhI3vaTsyRf+8+pkp0dvSpbwwJ7ESBm+BRMPGTnV1AlwJKqjzDYHgowSe01Nw= =COsH -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 05:47 PM, Gavin Andresen wrote: > And why do you think your blog is more public than this open, > publicly archived mailing list??? > Non-developers are more comfortable using social media tools. Blog posts can be shared, Tweeted, and commented upon using nothing more than a web browser. The barrier to participation on a mailing list is higher, and the visibility is lower. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTV/0yAAoJECoisBQbQ4v0Fm8H/j0fG7s/iEQUDlV2+5mxeiBO eoPY2gwuDSTjXc74/3olPHrL/BTGtGg90zwFmlwruUJOaW2m3xvbTD78S8e3HmCC fqqFKQLg+gOQYud2oiHVNW6H++QqKgSJXu4Lr87ZTkpiRGTgr5PWyhe+4sLeXxam InqcFmtTHiUMKlmiPj/FUaPHxYT+n+FaPuiZRUYt0Wfxcc9b1n6gEpV7r36Wh8gl e3rMeDwTfsj/0R4+E+oFEgPl7XBGIJWAf4Nzebuog4ABlqzm4B/RlclZ/5N3W2zZ 6ym6dGpFwN+RuDY2/S2kah6dAeKyk2mAsAChoSOj+vfhCW9wKzclVyM2FNV6lwE= =djWj -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 03:07 PM, Mike Hearn wrote: > On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier > wrote: > >> If enough miners don't like a block that has been mined, they can >> all work to orphan it without any change to the protocol >> whatsoever. >> > > As was already pointed out, yes. However this requires them to > immediate establish a majority consensus and be absolutely sure it > really is the majority. You suggest an out of band mechanism for > that, but why is this better than using the actual consensus > mechanism you're trying to measure? > > >> Once you've changed the network such that it is no longer a >> machine that faithfully processes scripts > > > Bitcoin imposes far more rules than just execution of the > scripting language, many of which are entirely arbitrary and the > result of (controversial) human judgement, like the inflation > schedule. You can't claim Bitcoin implements only some kind of > natural law. > I've formulated my replies to you and this proposal in a more public venue, where such discussions of existential changes to the protocol more rightfully belong: http://bitcoinism.blogspot.com/2014/04/dirty-deals-in-smoke-filled-rooms.html - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTV/Y0AAoJECoisBQbQ4v08NcH/RfkaBAcS5eAKmwePqFuqIUN xJKyIWo+tyY1vPYgArCVNsYr3YM8Wc5fkpqLNxCaM7S0/UmO8YaOdiD7XJyl7bF9 xAveyRt1mfHhx9x6hnPLYbe8WKqtjssSt6MglN8OXtf0EDO+eIxPj6Ya8OZ5YJrL N8SMHaDs2J+qy3Qfec9keE5dyhYLNRC6PjYPVvrRAyqFSjt/8r4Z2a4r0oqvv3Yt mYU1Tx+WoXMKXWY/Dwql1NLbuspZsOhPx/ncROZ5KVryCdrcW/GEIEQ6P0AIdHvT TKYJzh1bdRDYDmVS5z8nUG6waxJwuWPStQo7UYdg26daRUw5qPzjO9SMLLFZPCU= =OOck -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 07:55 AM, Mike Hearn wrote: > 2. Miners can vote to reallocate the coinbase value of bad blocks > before they mature. If a majority of blocks leading up to maturity > vote for reallocation, the value goes into a pot that subsequent > blocks are allowed to claim for themselves. Thus there is no risk > to voting "no" on a block, the work done by the Finney attacker is > not wasted, and users do not have to suffer through huge reorgs. If enough miners don't like a block that has been mined, they can all work to orphan it without any change to the protocol whatsoever. Why are proposing this a change to the network that allows miners to vote to disregard output scripts, instead of creating an out of band network via which miners can coordinate actions using the capabilities the protocol already allows? Once you've changed the network such that it is no longer a machine that faithfully processes scripts, and instead is a machine via which a set of controllers can decide which valid scripts will be honored and which ones will not, what will be the next proposed condition under which the miners can confiscate and redistribute balances? - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTV9OUAAoJECoisBQbQ4v0XE8H+QGcOc3JiYsS2/xoR8SqpyEx gDChDFvhaao9qMPhfxBG0bso+4ITZ5c3mJawkqdBm3ZZPeygt1fLqvxe4c1AWocH YCf9CyZJlm8KsDJOqorja5o/6oXjH5xiGgVi042Jhb9wj/aGNPFvL9X6DGhEeFKQ uXFN4wTSPViEOryVqo3vEFh3md9Y1AIqcvc/b5M+EAtvaAD33/ALnzY9CNKymQZE o0JGLEfwamKkZ+QA0mTfeDheJe9kj0KOQhXqOG/x3NlKCFVpmGz3daWZHJCFMDb4 +RmDwoxOKvXxgveXu9w4d3bc3SQZ75hygmeMvVQwZggia31wqrHtsWLqIiFhVnU= =hpdg -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] mid-term bitcoin security (Re: Warning message when running wallet in Windows XP (or drop support?))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2014 11:06 AM, Adam Back wrote: > Btw not to reignite the stealth vs reusable address bike shedding, > but contrarily I was thinking it maybe actually better to try to > rebrand address as "invoice number". People understand double > paying an invoice is not a good idea. And if they receive the same > invoice twice they'll query it. "Invoice number" is still too coarse-grained. If anyone cared about user privacy, then whatever was supplied to users as an "invoice number" would be a BIP32 extended public key, or something equivalent to that, which would allow the payer to create as many unique addresses as they needed to avoid merging inputs. Also, from a business accounting perspective it's broken and wrong to assume a 1:1 relationship between payment transactions and invoices anyway: http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUTkSAAoJECoisBQbQ4v0t44H/1dl/QFBbJKNatghyaCnrcYE eQlq6RtUo9ZCGTehg4K8Q3wlHcNxTi5ojkZ0ccf9O6lWFAO3Dij9jeiUB0irX1SP leGVV6I3CU6DYMLN+1AHqeHfGQ6T367zdlc69TO5E3Z3nEfStWVAnp6BwraDpgLs OslTSlWiqAFZRrP9G18E7OF/jZcjxdW5QUuQk1ktW0yyZpL6LuwWHqRwoJ0LuR/V nL/OeUUHD3k563c4et5uejVkoGRkLOnk9rLiAQNeX6FfL5T4t2Ae/45PywiLmXoN 7Egd9g7pDU0qZMnXTd9/JLMi1Vlx61pKogg3xSj/NLQuUwJJDTbua7dxjXOtC8I= =9KG3 -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 06:50 PM, Gregory Maxwell wrote: > Who says anything about a broken incentive model. You've made past > claims about resource requirements that I think made no sense and > then failed to defend them when they were challenge. Anyone reading the archives of the list will see about triple the number of people independently confirming the resource usage problem than they will see denying it, so I'm not particularly worried. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRZhsAAoJECoisBQbQ4v0iD8H/A1RZyLJN6f+zt5x78CFgRdp zqZua3NBwUN2L9mI/PU1NADtxoXgkq49XusHRc+bjLu17VxGMUOsmB+AeK3VU4sN BVC1qIcWCa+OPMkgnMFrdydz4OGxX5xiJoCNsqveZIEYc8nQoCDfsn/fwqL50/Ct NfmPzh/cW7uUZ+h2bBgduGD3fzpQBlnnswAbHHX3FbBh9MvcaCfROeXXqUCedWj9 H2qVCNWTkIFJksJkqyF3f+KfedOTIyUwflx/0niBvzXcP9w4oK+WpBApHACWxiSA H3KHYNF0s2/fs+mIkabPLRX1PIUk15ln29FapoDvlHW9jzDE92x6JFnMppI4rEs= =ILks -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 06:19 PM, Wladimir wrote: > If no one wants to volunteer resources to support the network > anymore, we'll have failed. If the security of the network depends on a broken incentive model, then fix the design of the network so that economics works for you instead of against you. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRZLiAAoJECoisBQbQ4v0RRMIAKL84ju4b9XAls9sOxQGrLMr xifQDhThCQKC4/qkOmGU8zseIdKRgXEq4auMF9/0BlgoSxsBcKynlRH2fFtYY7ol sdjCy/5dk+MBu3K1GCvNn/cuGkpIJJxrom/9riSiaPtivE5ncl7cyW5hFqf2MzRd dF6q937ocgBd8d2VuOQleQ9N5gue1+du77soxfp8oY7dXNdwk5ZrngeYxz1umsjQ lBAI/3JYkKVhU5Rte3deJcMHe6xA+neIzvcfWbOZYrkdwWE+jLSKnDkDkCOXJnuP vOI8CAteaFctV2mfgXX2CmNDWVeFsyCwoQwbnCmuE/uiM5y235PcTrsyr6U+Zzs= =oQPK -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/2014 05:40 PM, Mike Hearn wrote: > The primary resources it needs are disk space and bandwidth, after > an intensive initial day or two of building the database. Check out the kind of hardware causal users are running these days. The bottleneck is not bulk disk space, but rather IOPS. Most users don't have spare machines to dedicate to the task of running a full node, nor is it acceptable for them to not be able to use their device for other tasks while the node is bootstrapping. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTQuVNAAoJECoisBQbQ4v004EIAMPpQLrVlzCoGjcgALyHV4xK 6JDnlCHXTR72mTlKwcbD6Dpyr/Dl6tcXtdbQi0m3gsbOcAZI/eHtrswgunaq7c1y mTOM2klPE4M8+B/4Ecp+2iK2UM/swlL3z8ryx/HPhgOZ+Rr7AENe3WUYOKiVNE4O YQP1x9c0l09ma3ZU0sLmz2VTyqVzI7yV3mu/+HKcwYnqNrK9i/c8MRhOLdZ0gcUL b2PtjjCdnSNLelZvwSLcqqR5+1oejAVwgt1Aq4RGyZzD9DVdCXUR9c9HWLAs0MEU WPU5gU03YmrE5mkgGHRO3YnDbky0gdAGEw2Phzqd2upud4CLqdhEqA4v6/tQhpk= =BVpU -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/2014 05:16 PM, Gregory Maxwell wrote: > When I read "resource requirements of a full node are moving > beyond" I didn't extract from that that "there are implementation > issues that need to be improved to make it work better for low > resource users" due to the word "requirements". In order to prevent future confusion: whenever I talk about requirements (or generally use the present tense) , I'm talking about reality as it currently exists. If I ever decide to talk about hypothetical future requirements in some imaginary world of Platonic forms, as opposed to the requirements imposed by the software that's actually available for casual users to download today, I'll mention that specifically. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTQuRkAAoJECoisBQbQ4v07zUH/2wNQ7+0211+wm5oQP/ABHg7 kQVeQcRz8/BhOp3hzv6HiQ9Oaekfz7QhClbJYPUPE3aR2gxGoCgT6B1G2N75q0pG piGVgCeogaBA3Ny91sOPRMv92cGWpbTeyO+rhIIIlYWPiZobTaYttYYm1zF6oc6K CdYzCW9X12/NIXxEkbPnAFJ01Uty0HKccTP+9jex7+gobzl2yCo4MyywwtWF9XEk K9aZ3+3i+12+F4nDMAAimD02SV6dI8GMpahMf4kNXn0CcMefC9A28FdhhApPh7Nx 1phQnMPZMPdYt0aHgjgzt4N+SR/1EOUZaoqk9ccyXh+khBR84tiUEo6NuOIfTGM= =Mr12 -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/2014 11:34 AM, Mike Hearn wrote: > At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and > still falling: > >http://getaddr.bitnodes.io/dashboard/chart/?days=60 > > I know all the reasons why people *might* stop running a node (uses too > much disk space, bandwidth, lost interest etc). But does anyone have any > idea how we might get more insight into what's really going on? It'd be > convenient if the subVer contained the operating system, as then we could > tell if the bleed was mostly from desktops/laptops (Windows/Mac), which > would be expected, or from virtual servers (Linux), which would be more > concerning. It doesn't do much good to only focus on the immediate symptoms at the exclusion of big picture trends. There are three things happening now that have nothing to do with operating systems. 1. The resource requirements of a full node are moving beyond the capabilities of casual users. This isn't inherently a problem - after all most people don't grow their own food, tailor their own clothes, or keep blacksmith tools handy in to forge their own horseshoes either. 2. The growth of small and medium-sized native Bitcoin businesses is lagging #1. Native here means their revenue and expenses are both denominated in BTC. Most business adoption we've seen so far doesn't actually handle bitcoins themselves. They use Bitcoin as a payment method whose processing they outsource. Contributing to this is the fact that Bitcoin Core, although it has made great progress in the 0.9 release, can't be accurately described as "enterprise ready". 3. The P2P protocol used by the network is broken from an incentive perspective. Resource usage wouldn't be a problem as long as the users which consume resources pay for them and the users who provide resources are compensated, and they communicate via an efficient price discovery mechanism. Right now there is no obvious way to incorporate price discovery for bandwidth usage or storage space without a completely new P2P protocol, and the effectiveness with which progress has been blocked towards price discovery of transaction fees (the area where it is most obviously necessary) means that I'm not optimistic that this subject will ever be effectively addressed by Bitcoin Core. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTQsgzAAoJECoisBQbQ4v0ZA8H/1YIJAg7AEUUe5RnuuAz7lVV uiHtpmbmGaZ+Bd0qi1DEfPdeBP9bDKpO3O5napmtz+mqIE5H3VgAVg7z9U0sMf16 sZAJIWuVCg2drY/NaE+n3TKEEd4Z1Zj51rWde/KD6xjgR2usV9nLugkEJdLNahZu 0EbdAv40oCSZ8PScNElYqQyM8qcbta7LuDRCnnWvCyunZJzL4LSkQwDcsAWQ+oSv FyqKY/e1Kd6mLyrN/NppMzdqiLv95zmE56Qkh6rlKeF+JgXxlfiEfDv8osl8IWJR TOpmW0Dr+E4qe9E3nA7X5gV46nf8gxGZ4b0cUP+wivN9RRaE27+JlKhKaAV3ulc= =vdPa -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2014 03:41 PM, Laszlo Hanyecz wrote: > www.githubb.com resolves to addresses announced by AS53665 > > Some basic info about AS53665 can be seen at > http://bgp.he.net/AS53665 They probably have a dedi or VPS at > Cogent. They didn't even create an IRR record for their AS or > their only route. > > Let's see what google has to say about malware from AS53665 (TL;DR > - it's a malware site) > http://www.google.com/safebrowsing/diagnostic?site=AS:53665 Be careful out there. https://www.techdirt.com/articles/20140124/10564825981/nsa-interception-action-tor-developers-computer-gets-mysteriously-re-routed-to-virginia.shtml - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTPDMBAAoJECoisBQbQ4v0SrgIAJIHBmYbWCmZhQqt0trfrjDk GT5jQmQwo7yUzhgan/3Bx0BFD9t0EL65iK6e4RZei5EK7tXvWeaAYztQsfuEybxc +sm6B5w1497Tdj1PwqrfS/OITasY7+CJKLurYn0e/01sZp2STMR0d/rjYxtgUAnI 9hf6FOi/KbXRj7AUoUm3Ut1J9xxIv3GgP3oZVtWNBdWFgk0KcoNVtMxZMARz1OUd OnUCQnyLLfNVT79HdQiHmYMDkPXttLNS4VMfryx9gccCZfJK1ES58YpZA31EFEe7 zsWOYRV4H124upD4fog2KBASyQj5e7dHjqWSjxcitX6kt8Sbf7WzSC2lKwaJPZ0= =Awk+ -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dust recycling
On 03/29/2014 08:05 PM, Gregory Maxwell wrote: > Use dust-b-gone and make it someone elses problem to get it relayed. :) > That's a sub-optimal solution, as it introduces a third party. What if his server goes down? An universal solution is preferable. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dust recycling
On 03/29/2014 07:55 PM, Goss, Brian C., M.D. wrote: > Could you collect the dust into a transaction with no outputs (thus making it > all tx fees) or putting in to an anyone can spend tx? > > The large number of signatures (for large n) would make the tx size > large...but, if enough dust were out there, it might be worth propagating to > a pools hash power. What would make it easier is if there was a standard output type for sending the entire transaction to miner fees, that would make even large transactions propagate that would normally be dropped by fee/kB rules. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Best practices for dust remining
Suppose am m-of-n multisig wallet receives a bunch of dust deposits due to somebody advertising the Olympics, or any other reason, and the users of the wallet don't want the few satoshis involved. What is the best way to allow all these dust outputs to be re-mined in order to clean up the utxo set, keeping in mind the scripts may include large values of n? -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 70 and OP_RETURN
On 03/29/2014 01:30 PM, Mike Hearn wrote: > They would just encode the OP_RETURN script into an Output structure. I'm > not sure about the question - you seem to give the answer yourself in the > first paragraph? > I guess what I was asking is whether or not all BIP70 compatible clients will support the creation of all standard output types, including OP_RETURN outputs. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 70 and OP_RETURN
The description of the Output message states that the payment request can specify any standard TxOut script, and that OP_RETURN is a standard transaction type that would imply the ability to specify OP_RETURN outputs in BIP 70 payment requests. If the creator of a payment request wanted the sender to include a small amount of data as an OP_RETURN output, how would they specify this? -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On 02/28/2014 07:25 PM, Mark Friedenbach wrote: > Transaction fees are a DoS mitigating cost to the person making the > transaction, but they are generally not paid to the people who > actually incur costs in validating the blockchain. Actual transaction > processing costs are an externality that is completely unpaid for. What that means is the network layer is broken and needs to be fixed. Bitcoin is the blockchain, not the P2P network. If the existing network is not incentive compatible, then that's the root cause which should be addressed. There's no reason to enshrine the broken behavior and use it as a roadblock to stop progress. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Framework for modular input selection policy for Bitcoin wallets
One of the areas that isn't as well developed as it could be in terms of wallet design is fine-grained control over input selection policy. Coin control is great when a human is manually crafting transactions, but that's not really a very scalable solution. The attached image is a possible way to stack different independent selection algorithms. If wallets implemented something like this, it would be easy for other programs to implement new application-specific algorithms that would not need to completely reinvent the wheel. As an example, voting pools in Open-Transactions will implement cold storage in a FIFO manner, meaning that UTXOs will be clustered into groups which should be consumed in a specific sequence. Within that constraint, however, they still want to minimize transaction size. If wallets were designed to make selection policy modular, they'd only need to implement their FIFO algorithm and stack it in before the default algorithm. Surely this capability would be useful to other projects as well. It would also allow people who want to prioritize privacy over transaction cost to easily modify the behavior of their clients and would make it easier to incorporate new tx construction algorithms like CoinJoin. Link to the image in case attachment is stripped: http://i.imgur.com/Fkkq7pI.png -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
