Re: [Bitcoin-development] Electrum 2.0 has been tagged
Congrats on the release! Electrum is a very nice wallet. On 03/01/2015 04:23 PM, Thomas Voegtlin wrote: Dear Bitcoin devs, I just tagged version 2.0 of Electrum: https://github.com/spesmilo/electrum/tree/2.0 The electrum.org website will be updated later today. The release notes are a bit dense, due to the large amount of changes and new features in this release. In the coming weeks we will be adding more detailed documentation to the wiki and to the website. There has been a very long hiatus in Electrum releases, because it took me a lot of time to decide about the new seed derivation method and wallet structure. Now that this part is done, I hope that we will resume to a faster release pace. I would like to thank all the people who contributed to this release, developers, beta testers, but also people from this list who provided useful feedback. Cheers, Thomas _ RELEASE-NOTES # Release 2.0 * Before you upgrade, make sure you have saved your wallet seed on paper. * Documentation is now hosted on a wiki: http://electrum.orain.org * New seed derivation method (not compatible with BIP39). The seed phrase includes a version number, that refers to the wallet structure. The version number also serves as a checksum, and it will prevent the import of seeds from incompatible wallets. Old Electrum seeds are still supported. * New address derivation (BIP32). Standard wallets are single account and use a gap limit of 20. * Support for Multisig wallets using parallel BIP32 derivations and P2SH addresses (2 of 2, 2 of 3). * Compact serialization format for unsigned or partially signed transactions, that includes the BIP32 master public key and derivation needed to sign inputs. Serialized transactions can be sent to cosigners or to cold storage using QR codes (using Andreas Schildbach's base 43 idea). * Support for BIP70 payment requests: - Verification of the chain of signatures uses tlslite. - In the GUI, payment requests are shown in the 'Invoices' tab. * Support for hardware wallets: Trezor (Satoshilabs) and Btchip (Ledger). * Two-factor authentication service by TrustedCoin. This service uses 2 of 3 multisig wallets and Google Authenticator. Note that wallets protected by this service can be deterministically restored from seed, without Trustedcoin's server. * Cosigner Pool plugin: encrypted communication channel for multisig wallets, to send and receive partially signed transactions. * Audio Modem plugin: send and receive transactions by sound. * OpenAlias plugin: send bitcoins to aliases verified using DNSSEC. * New 'Receive' tab in the GUI: - create and manage payment requests, with QR Codes - the former 'Receive' tab was renamed to 'Addresses' - the former Point of Sale plugin is replaced by a resizeable window that pops up if you click on the QR code * The 'Send' tab in the Qt GUI supports transactions with multiple outputs, and raw hexadecimal scripts. * The GUI can connect to the Electrum daemon: electrum -d will start the daemon if it is not already running, and the GUI will connect to it. The daemon can serve several clients. It times out if no client uses if for more than 5 minutes. * The install wizard can be used to import addresses or private keys. A watching-only wallet is created by entering a list of addresses in the wizard dialog. * New file format: Wallets files are saved as JSON. Note that new wallet files cannot be read by older versions of Electrum. Old wallet files will be converted to the new format; this operation may take some time, because public keys will be derived for each address of your wallet. * The client accepts servers with a CA-signed SSL certificate. * ECIES encrypt/decrypt methods, availabe in the GUI and using the command line: encrypt pubkey message decrypt pubkey message * The Android GUI has received various updates and it is much more stable. Another script was added to Android, called Authenticator, that works completely offline: it reads an unsigned transaction shown as QR code, signs it and shows the result as a QR code. -- 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/ -- 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Seems like a good deal, what am I missing? The disruption caused to every other user or the bitcoin network. Transactions unconfirmed, history is rewritten, the poor Byzantine General who sent his soldiers off to battle finds out that his scouts have been paid to change their reports. Neil On 2 March 2015 at 06:59, Troy Benjegerdes ho...@hozed.org wrote: So let's play this out a little.. Let's call it Solomon's spend[1] Exchange gets hacked, bitcoins move. The exchange has a contract with an insurance company and miners for 'scorched earth' theft response that creates a double-spend of the original transaction. So now there's a 10,000 bitcoin incentive for miners to roll back the chain and start (re)mining the block where the theft occurred. The exchange gets an insurance payout, some miner wins the lottery, and the thief gets nothing. Seems like a good deal, what am I missing? [1] http://en.wikipedia.org/wiki/Judgment_of_Solomon On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote: I should note that my proposal does require a change to the consensus rules...but getting bitcoin to scale will require this no matter what. - Eric Lombrozo On Feb 22, 2015 3:41 AM, Eric Lombrozo elombr...@gmail.com wrote: It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
[Bitcoin-development] Electrum 2.0 has been tagged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Bitcoin devs, I just tagged version 2.0 of Electrum: https://github.com/spesmilo/electrum/tree/2.0 The electrum.org website will be updated later today. The release notes are a bit dense, due to the large amount of changes and new features in this release. In the coming weeks we will be adding more detailed documentation to the wiki and to the website. There has been a very long hiatus in Electrum releases, because it took me a lot of time to decide about the new seed derivation method and wallet structure. Now that this part is done, I hope that we will resume to a faster release pace. I would like to thank all the people who contributed to this release, developers, beta testers, but also people from this list who provided useful feedback. Cheers, Thomas _ RELEASE-NOTES # Release 2.0 * Before you upgrade, make sure you have saved your wallet seed on paper. * Documentation is now hosted on a wiki: http://electrum.orain.org * New seed derivation method (not compatible with BIP39). The seed phrase includes a version number, that refers to the wallet structure. The version number also serves as a checksum, and it will prevent the import of seeds from incompatible wallets. Old Electrum seeds are still supported. * New address derivation (BIP32). Standard wallets are single account and use a gap limit of 20. * Support for Multisig wallets using parallel BIP32 derivations and P2SH addresses (2 of 2, 2 of 3). * Compact serialization format for unsigned or partially signed transactions, that includes the BIP32 master public key and derivation needed to sign inputs. Serialized transactions can be sent to cosigners or to cold storage using QR codes (using Andreas Schildbach's base 43 idea). * Support for BIP70 payment requests: - - Verification of the chain of signatures uses tlslite. - - In the GUI, payment requests are shown in the 'Invoices' tab. * Support for hardware wallets: Trezor (Satoshilabs) and Btchip (Ledger). * Two-factor authentication service by TrustedCoin. This service uses 2 of 3 multisig wallets and Google Authenticator. Note that wallets protected by this service can be deterministically restored from seed, without Trustedcoin's server. * Cosigner Pool plugin: encrypted communication channel for multisig wallets, to send and receive partially signed transactions. * Audio Modem plugin: send and receive transactions by sound. * OpenAlias plugin: send bitcoins to aliases verified using DNSSEC. * New 'Receive' tab in the GUI: - - create and manage payment requests, with QR Codes - - the former 'Receive' tab was renamed to 'Addresses' - - the former Point of Sale plugin is replaced by a resizeable window that pops up if you click on the QR code * The 'Send' tab in the Qt GUI supports transactions with multiple outputs, and raw hexadecimal scripts. * The GUI can connect to the Electrum daemon: electrum -d will start the daemon if it is not already running, and the GUI will connect to it. The daemon can serve several clients. It times out if no client uses if for more than 5 minutes. * The install wizard can be used to import addresses or private keys. A watching-only wallet is created by entering a list of addresses in the wizard dialog. * New file format: Wallets files are saved as JSON. Note that new wallet files cannot be read by older versions of Electrum. Old wallet files will be converted to the new format; this operation may take some time, because public keys will be derived for each address of your wallet. * The client accepts servers with a CA-signed SSL certificate. * ECIES encrypt/decrypt methods, availabe in the GUI and using the command line: encrypt pubkey message decrypt pubkey message * The Android GUI has received various updates and it is much more stable. Another script was added to Android, called Authenticator, that works completely offline: it reads an unsigned transaction shown as QR code, signs it and shows the result as a QR code. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8y7fAAoJECvVgkt/lHDm78oP/2uIqCyOwLsAJGkAI3CPFxtw WssFJlnCnFiA4tPv5pd7HdOgxQkTaPbUHftexfdd/lpfmFvxZVoHcA/32IIKFH63 BU2bnEyYOaW1A4XfNDQH6VG7eT2er1HOlHCtIgzRl0KJNmVggU6DnXnHkUs1PVvg pyEIR7Xv3GiK7rcS4qCS/9COroqQGFOXJAiLnOaQP5KszT1bMUdoL7mBPTfavnla LM+2MgKJOWv+JpHQCDp3XwAXX62LLsS2BjdK1Jt6OpGA6IuVQGBSaTIn5K81S+Yh M6RDKbP3kObYQ+bzLvtWrzgUD3sdht/V8L5ZPS3+Jibvmhae2zRrm/YpJZ77Yjd4 7QliCFGH0+Gwle72yOempFGWULwq7p6yo4dVZXpj1G3XmbZXuvFg4jYeC/usCx+T kQgMBPWME2m80fCzhJew1pRChSs/lzVreB0Lh6Tm/5Pibmy721J4oUr6oLkaR9Uy NMrYqnSy0+tCEOXHrpCYhqogyzzdjOlv0gWKqB2uSkO5TkEHv2eyHeiZttAn11qO sb85q/k0kYQBZZEvKJ9022eyKHjejDhQjKsCVIHhb81BJ1QYnZFIxBiKkVMxf0u5 sT2TTi18eOrYCUGD2WJ+ALyI1zN1sHO0/sn5+XzlC0jg+1KUXoo0j8NYnzmHb0Yx 5lbdlcaw0Uo7iWkFdMYT =IGGP -END PGP SIGNATURE- -- Dive into the World of Parallel Programming The Go
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
So let's play this out a little.. Let's call it Solomon's spend[1] Exchange gets hacked, bitcoins move. The exchange has a contract with an insurance company and miners for 'scorched earth' theft response that creates a double-spend of the original transaction. So now there's a 10,000 bitcoin incentive for miners to roll back the chain and start (re)mining the block where the theft occurred. The exchange gets an insurance payout, some miner wins the lottery, and the thief gets nothing. Seems like a good deal, what am I missing? [1] http://en.wikipedia.org/wiki/Judgment_of_Solomon On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote: I should note that my proposal does require a change to the consensus rules...but getting bitcoin to scale will require this no matter what. - Eric Lombrozo On Feb 22, 2015 3:41 AM, Eric Lombrozo elombr...@gmail.com wrote: It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Bitcoin was/is a disruptive technology for credit card payment processors, and replace-by-fee/stag-hunt is a disruptive technology for Bitcoin payment processors. I think whether you call it scorched earth is a bit more of a reflection of whether you stand to make money, or lose money from the distruption. Personally, I think 'first-seen' is a dangerous scorched-earth policy that only benefits the people who own the internet routers that determine what is seen first. But from the standpoint of consensus, can we at least agree that it's a *node policy* decision, and the market particpants should be free to choose whichever policy works best for them? Otherwise, I think the only way to make 'first-seen' work is by adding a timestamp to CTransaction. On Sat, Feb 21, 2015 at 05:47:28PM -0500, Jeff Garzik wrote: scorched earth refers to the _real world_ impact such policies would have on present-day 0-conf usage within the bitcoin community. All payment processors AFAIK process transactions through some scoring system, then accept 0-conf transactions for payments. This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth Without adequate decentralized solutions for instant payments, deploying replace-by-fee widely would simply push instant transactions even more into the realm of centralized, walled-garden services. On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach m...@friedenbach.org wrote: Thank you Jorge for the contribution of the Stag Hunt terminology. It is much better than a politically charged scorched earth. On Feb 21, 2015 11:10 AM, Jorge Timón jti...@jtimon.cc wrote: I agree scorched hearth is a really bad name for the 0 conf protocol based on game theory. I would have preferred stag hunt since that's basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) but I like the protocol and I think it would be interesting to integrate it in the payment protocol. Even if that protocol didn't existed or didn't worked, replace-by-fee is purely part of a node's policy, not part of consensus. From the whitepaper, 0 conf transactions being secure by the good will of miners was never an assumption, and it is clear to me that the system cannot provide those guaranties based on such a weak scheme. I believe thinking otherwise is naive. As to consider non-standard policies an attack to bitcoin because that's not how bitcoin used to work, then I guess minimum relay fee policies can also be considered an attack to bitcoin on the same grounds. Lastly, first-seen-wins was just a simple policy to bootstrap the system, but I expect that most nodes will eventually move to policies that are economically rational for miners such as replace-by-fee. Not only I disagree this will be the end of bitcoin or will push the price of the btc miners are mining down, I believe it will be something good for bitcoin. Since this is apparently controversial I don't want to push for replace-by-fee to become the new standard policy (something that would make sense to me). But once the policy code is sufficiently modular as to support several policies I would like bitcoin core to have a CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no policy checks at all). One step at a time I guess... On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes ho...@hozed.org wrote: On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: Most money/payment systems include some method to reverse or undo payments made in error. In these systems, the longer settlement times you mention below are a feature, not a bug, and give more time for a human to react to errors and system failures. Settlement has to be final somewhere. That is the whole point of it. Transfer costs in current electronic payment systems are a direct consequence of their non-finality. That's the point Satoshi was making in the introduction to the whitepaper: With the possibility of reversal, the need for trust spreads. The problem with that statement is I trust a merchant that I went into a store and made a payment with personally more than I trust the firmware on my hard drive [1]. The attack surface of devices in your computer is huge. A motivated attacker just needs to get an intern into a company that makes some kind of component or system that's in your computer, cloud server, hardware wallet, or what have you that has firmware capable of reading your private keys. With the possibility of mass trojaned hardware, if we are going to trust the system, it must somehow allow reversal through a
