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 decrypt
>
>
> * 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
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 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" 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" wrote: > > > > > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón > wrote: > > >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik > > >> 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=190641631&iu=/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 > > > ht
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" 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" wrote: > > > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón wrote: > >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik > >> 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=190641631&iu=/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=190641631&iu=/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
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 > 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" 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 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
[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
decrypt
* 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 Parallel Website, sponsor
