 Show Posts
|
|
Pages: [1]
|
|
The addition of 0x01 bits to the binary seed representation is used to distinguish HD seeds from normal seeds in the current git master branch.
|
|
|
|
After speaking with Thomas, it's possible to do a workaround for offline seed generation even assuming 0x01 bits. I understand 0x01 is there for seed versioning, which is a development boon. My concern with it is libraries like Bitcore and others may choose to do BIP32 without the 0x01, and *if* that is the only difference between electrum's bip32 implementation and, say, JS wallets based on Bitcore, electrum could potentially find itself incompatible with a growing number of wallets in the future for only that reason. However, Thomas informed me there would be more than 0x01 distinguishing electrum seeds from other bip32 implementations. Interchangeability with other BIP32 wallets would be nice, but tbh, electrum kinda did its own thing for a while, so having electrum's BIP32 also be like "its own thing" wouldn't be too much of a problem I agree with this. I'm also for backwards compatibility, my thoughts at the time were that if 0x01 was the only difference between electrum and say bitcore bip32, it may be worth looking at. Only way I could thnk of to do that is to do a 1.x / 2.x split. I think jQuery makes this approach work for their userbase, but that's a very technical audience and even then I remember there was grinding of teeth when jQuery announced the 2.x / 1.x split. ChaiScript is the only other project I can think of right now that does this, and it has a highly technical audience as well. FWIW I think people will want to upgrade to bip32, and they're going to need to generate new seeds to do that regardless. The entire point of BIP32 was that you'd get standardized seeds across wallets. I've heard standardized seeds across wallets isn't happening. Multibit is adding a timestamp to the 12 words, not sure what BitcoinJ and JS libs are doing, but I don't think there's concensus. |
|
|
|
bip32 is a big upgrade for electrum. AFAIK electrum's much-anticipated multisig wallet mode is only compatible with bip32. Furthermore, in the Kivy Android app, we need bip32 to provide multi-account functionality for users who like to manage multiple wallets from the same screen. The way Electrum is looking now, there will be two split versions of the seed serviceable from the same wallet installation. You can toggle bip32 off/on from the cmdline. Under the hood, '0x01' is prepended to HD seeds in order to distinguish them from regular 12-word deterministic seeds. The 0x01 bits require adding one additional word to the seed to create adequate entropy. This brings Electrum HD seeds up from 12 words to 13 words. By comparison, Multibit HD will be going with a 12 word seed: https://secure.flickr.com/photos/94861732@N04/14228288156/?rb=1There are a few downsides to electrum's current planned split seed arrangement. One is that GUI users who wish to generate a new wallet with one type of seed need to specify that up front. For example, in Kivy on Android we're planning to default to bip32 for various reasons, but doing so means users can't enter original 12 word seeds, unless we add some type of option menu to the create account screens. A less obvious downside is that 13 word HD seeds can only be generated by software. It's impossible to roll dice to come up with a HD seed completely offline due to the insertion of 0x01. Again, with bip32 we can do multiple accounts and multisig wallets, which are hugely important features at least for Kivy. I see the move to bip32 as being a breaking upgrade in terms of UX for these reasons. I can see the logic behind moving forward with support for both original deterministic seeds and HD seeds from the same codebase, but moving to only supporting bip32 from the 2.x codebase, and only supporting normal determinstic seeds from a 1.x codebase could have several advantages. First, I assume if 2.x moved to only support HD seeds, the 0x01 bits wouldn't be needed. Which means we could default to 12 word HD seeds instead of 13. It also means the seeds could be generated completely offline. On the plus side, there are numerous wallets supporting Electrum 12 word seeds now, and it would still be possible to host a 1.x release of Electrum, kind of like jQuery with their dual 1.x and 2.x releases. To be clear, I see bip32 as a major upgrade, and I think new users will prefer using bip32 as the default mode. bip32 is also a bit of a breaking upgrade to Electrum. It's breaking not just in terms of seed compatibility, but breaking in the sense that bip32 enables multisig wallets, and multiple-accounts at least in our Kivy GUI. I view it as more of a foundational change, that is perhaps worthy of splitting off into a dedicated branch. What say you to moving to a jQuery style split codebase (1.x and 2.x)? |
|
|
|
What do you mean by an "auxiliary" menu? An additional screen not shown by default. On the server selection screen, maybe a link to a website, keybase.io or github profile, a short blurb, whatever it may be. This, combined with prompting GUI users some 20% of the time with a straightforward and easily avoided or disabled donation screen. |
|
|
|
|
It takes 2GB of RAM minimum, and about 50GB of free disk space to house the patricia tree and blockchain.
Electrum's python console although limited to ASCII welcome text is nonetheless an opportunity for server ops to build a relationship with users, and it works to a limited extent. Small donations are coming in.
It may not be the optimal method, however I favor the overall approach since it means all donations are fully consensual with a minimum of UI cruft.
|
|
|
|
Public Electrum servers are run by volunteers. Volunteer server operators require modern hardware, which is costly to procure and maintain. In my opinion, operating Electrum servers would be more popular to do if there was a higher chance of receiving BTC donations for doing so. <fluffypony> https://blockchain.info/address/1Lhxa6VfBwFbVN2ovZEYfCobZGNfefntG7<fluffypony> one lone donation in February * ovidiusoft (~ovidiusof@188.27.121.252) has joined #electrum <fluffypony> nobody reads the console and thinks about donating <toastee> perhaps the electrum project should host some sort of distributed donation pool for their server hosts <toastee> and make it a bit more prominent in the client <fluffypony> toastee: yeah but then how do you distribute funds? based on the servers reporting their activity (easily faked)? <toastee> mmm true. <mr_burdell> fluffypony: oops... that's not a donation... I accidentally reused an address <fluffypony> mr_burdell: lol <fluffypony> well there you go <toastee> haha <fluffypony> so not even a single donation <toastee>  <fluffypony> even Eagle[TM]'s server <fluffypony> https://blockchain.info/address/1Mn8D4Esq6kyhQTG5debML3uqXp9JqeTQN<fluffypony> 0.011 BTC in donations <fluffypony> it's a joke I would like to open the conversation in regards to improving the Electrum server op donation system. I only advocate UX improvements. I don't think there is all that many technical changes required. I think it would be realistic to tackle this with minimal UX friction, and without adding any mandatory fees to Electrum. I think the optimal solution would be voluntary. Voluntary donations to Electrum server ops should be easier to do, and more compelling to do, so as to make them happen in larger amounts and with higher frequency. Today, it's quite hard to donate to server ops, even if you want to. There's no official UI flow for donating to server ops, and it's really not something that is directly supported in Electrum beyond it being a wallet which is capable of sending donations. Like I've outlined with Electrum plugins, few understand that Electrum plugins exist, and few know that Electrum server ops exist and are real people. If they do know servers exist, they don't know who is running them, and they don't have an easy way to donate. Users can't tell one server op from another without expending effort on research. Or they just aren't aware the client-server op relationship exists. Server ops are given ASCII text on a console window but most users don't venture there, and if on the off chance they do venture there, it takes effort to track down the donation address and subsequently make the donation. This isn't what mainstream users are used to. It results in very low conversion rates on donations when they are intended, and very low chance of donations happening in the first place. In theory, since Electrum servers depend on Bitcoin full nodes, a solution that increases Electrum server op donations could have the indirect benefit of making Bitcoin full nodes more profitable to run. Here is the one option I see working to this end: - server ops write a very short "About Me" description, probably < 512 chars - after Electrum users send coins, declare a >20% chance that an auxiliary menu is displayed if and only if there is a non-zero number of BTC remaining in the wallet less the amount to be sent - the coins are sent as per usual - if and only if the menu is to be displayed, it should show the server op's About Me text plus an option to donate, or "No Thanks" - the autoconnect server menu popup could also feature short bios on server ops. This screen is a missed chance at building relationship with ops Our in-house UX expert may have some ideas here, too. The overall goal is to give server ops a better chance at building the relationship with Electrum users. Since it's possible to select a specific Electrum server to rely upon, users, after learning more about server ops, will choose favorites and be more likely to donate to their favorites. To conclude, the only way I see things improving for server ops is if we make a concerted effort to have users build relationships with server ops and then prompt them to act upon the increased trust and credibility. Done right, it could end up making it much more profitable to run full nodes and impose few new technical changes of Electrum client. |
|
|
|
Everything is open source, nothing non-free is to be included anywhere. quanon's buildozer script will automatically build the APK from scratch. # install electrum deps
git clone https://github.com/spesmilo/electrum
cd electrum
pip install buildozer
make theming -C gui/kivy
make apk -C gui/kivy
At least, that's if we hit a planned merge upstream before the end of April. We've been trying to get it on GitHub since October The only intention of a 'plugin shop' is to make plugins highly visible to users, since I think most users have no clue Electrum plugins exist. Ideally I'd like Electrum plugins to take after Vim plugins or some other proven distribution model. Things I wished for / wondered about:
1. Multi-sig? I wonder how that would look UI wise... (that's probably a whole can of worms... maybe later?)
2. Encrypt a short message and embed it into a URI with the public key used to encrypt. When sent to the holder of the pubkey via mail app or something, they click the URI, and if they have the privkey, input their pin and the message comes up, etc... (again, not a core functionality for a wallet... but I'd find it awesome. Another fantasy of mine.) I think Thomas is exploring both of these areas. Charles has so far come up with innovative solutions to the most important UI challenges in Bitcoin, and I think if Thomas can code it, Charles can design it. |
|
|
|
|
@luke, but this logically results from discouraging the use of OP_RETURN while criticizing developers who use the blockchain for anything that isn't by-the-book, doesn't it? It may be technically beneficial to keep these applications off of Bitcoin's back in a perfect world, and I would agree that in this form Bitcoin stays what it is which could be a good thing. However it has the effect of keeping Bitcoin unchanging, i.e. pure, which has I would argue adverse implications on the number of people interested in the idea of a decentralized economy. I'm just of the opinion that the "solution", whatever it is, has to be using Bitcoin. I don't think other cryptocurrencies can rise to the same level of success, and I also don't think OP_RETURN 80 has a noticeable effect on the long-term network topology.
|
|
|
|
|
@maaku: Electrum 198 checks eight random Electrum servers for chain length before establishing the trustworthiness of any one instance.
The decision to encase Bitcoin in minimal purity may be technically correct, but I'm personally not interested much in living in the world of today. I want a new world. I can't speak for others, but we have to decentralize everything to get there, and I don't think PhantomPhreak and Xnova are new to worthy goals like this.
I grew up in the age of Napster, and I remember file sharing services being infiltrated early on by those who wished to corrupt the P2P movement. People coming together at large scale is what overpowered it. Bitcoin history runs parallel to P2P history, and so the success of Bitcoin will identically be a question of "people".
Large scale decentralized marketplaces are an essential factor in recruiting people at large to the idea of a decentralized economic system. Consequently I think it is a tactical mistake to become divided on OP_RETURN 80 since it leads to virtually identical network topology, but enables Counterparty and by extension Bitcoin to become massively better at uniting people the world over under a new economic system.
|
|
|
|
Here is what Satoshi Nakamoto had to say about Bitcoin scalability: Long before the network gets anywhere near as large as that, it would be safe
for users to use Simplified Payment Verification (section '8') to check for
double spending, which only requires having the chain of block headers, or
about 12KB per day. Only people trying to create new coins would need to run
network nodes. At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware. A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node. http://www.mail-archive.com/cryptography@metzdowd.com/msg09964.htmlMaaku, Electrum server has implemented your ultimate blockchain compression concept, and I know for a fact that it it is still quite resource intensive. It is in Python, so there's that  . Do you forsee a future where average users can use your C++ blockchain compression implementation to easily access the blockchain via Bitcoin-QT directly? Do you forsee the user experience of Bitcoin-QT competing with Electrum's speed, simplicity and ease of use? I am heavily biased here given that I've poured my own resources into Electrum (Kivy) for the better part of 2013 and 2014 so far, but I see no future in which average computer users are running Bitcoind or Bitcoin-QT. Maybe I'm mistaken and ultimate blockchain compression will turn things around. However, the user experience and branding of Bitcoin-QT make it seem like a reference client and I do not think it will grow to be much more than that. You'll have to excuse me but the death of Bitcoin talk has got to be an exaggeration. I'm sorry, I don't mean to offend, but that has to be an exaggerated assertion. If you are in fact right about the scalability concerns, Bitcoin is surely doomed. Malicious third parties will seek to corrupt the network, and they certainly won't seek out amiable terms with Bitcoin developers. One last thing. I feel you're really underestimating system adminstrators who are dedicated to Bitcoin. Realistically, unless I'm wrong and your C++ ultimate blockchain compression will flip the Bitcoin-QT user experience upside down, system adminstrators or perhaps philanthropic users who are sold done-for-you services are going to be the only class of users capable of running full nodes. This has implications on network topology, for better or worse. Bitcoin isn't dying, at least I hope not. But Bitcoin-QT may in fact be systematically losing market share to competing wallets. And for good reason. Users aren't used to software that requires a blockchain to function. The existence of a blockchain is 100% weird to the vast majority of computer users, who have grown to expect Facebook and Twitter to work instantly with no questions asked. Most people have no interest in the blockchain. The people who require a local blockchain (and not one that is for example reachable over Tor), can be serviced with done-for-you automated server setup solutions and whatnot. I suspect Satoshi foresaw this very early on. |
|
|
|
|
The Kivy GUI tries to keep pace with the spesmilo/electrum master branch at all times, which has implications on design and code. Charles' design is quite a departure from the one existing, and this is an ambitious project. Development has been mostly a one-person taskforce so far (akshay @http://kivy.org/#aboutus).
We have a tablet design as well. I wouldn't expect the APK to be production ready for several months, but it will be buildable and testable well before then. We still need to test it extensively on real-world devices and iterate on the code and design.
|
|
|
|
You may want to give Shamir's Secret Sharing Scheme a look. $ electrum getseed
{
"mnemonic": "flicker determine hand lot slowly world busy find character vain roam gift",
"seed": "168c6cdde03ce18aebc73e139b10b0b7",
"version": 4
}
$ ssss-split -t 2 -n 2
Generating shares using a (2,2) scheme with dynamic security level.
Enter the secret, at most 128 ASCII characters: flicker determine hand lot slowly world busy find character vain roam gift
Using a 592 bit security level.
1-c13342dec5abc18db404094767c9e4900a0c28e4792e3e8f3af3227159af1bcb7df38e7e74a638293fd0b644a1515c477c25451b152bf9ffaa192f52620f19949db9b2a82b6617726340
2-4c41df29db5f35d873039d71983b67b96b9a856fbc83ba23c9f9b33980ebf804f791edcb955e23a6aa8f8cdd8f4e887da4a56caa0b02f4bafff38d26b4e60b18cdc50210c81d03497586
ssss-combine -t 2
Enter 2 shares separated by newlines:
Share [1/2]: 1-c13342dec5abc18db404094767c9e4900a0c28e4792e3e8f3af3227159af1bcb7df38e7e74a638293fd0b644a1515c477c25451b152bf9ffaa192f52620f19949db9b2a82b6617726340
Share [2/2]: 2-4c41df29db5f35d873039d71983b67b96b9a856fbc83ba23c9f9b33980ebf804f791edcb955e23a6aa8f8cdd8f4e887da4a56caa0b02f4bafff38d26b4e60b18cdc50210c81d03497586
Resulting secret: flicker determine hand lot slowly world busy find character vain roam gift
Make some QR codes. function qrshow() { qrencode -s 10 "$1" -o - | display - ; }qrshow 1-c13342dec5abc18db404094767c9e4900a0c28e4792e3e8f3af3227159af1bcb7df38e7e74a638293fd0b644a1515c477c25451b152bf9ffaa192f52620f19949db9b2a82b6617726340
qrshow 2-4c41df29db5f35d873039d71983b67b96b9a856fbc83ba23c9f9b33980ebf804f791edcb955e23a6aa8f8cdd8f4e887da4a56caa0b02f4bafff38d26b4e60b18cdc50210c81d03497586
|
|
|
|
Another interesting project along these lines is DataHaven.NET. The developers recently created a currency-based marketplace for P2P encrypted storage, and have stated they're interested in integrating Tahoe-LAFS. However, it's not clear how they'll accomplish this. I've been experimenting with integrating Tahoe with Electrum for syncing plugin data. It's not intended to become a general data storage solution, but it would greatly benefit from there being an accounting or quota system built into Tahoe, as suggested ITT. I figure the wallet storage grid could be volunteer driven in the short-term until something is worked out. Still, my concern is with backing up Tahoe directory writecaps, of the form: URI:DIR2:65sm34olspfc5msodmptuckpne:yrpwyrha3sqlx5qst3w7l724ebbqyotobsjaoyi7pamt52xrfo5q The above URI is the key to your files stored in Tahoe almost like a Bitcoin private key is the key to your stored Bitcoin. You can't afford to lose it. The following bash function hex encodes the Tahoe writecap then passes it through Electrum's mnemonic system. The number of words generated is large but manageable. In cases where only temporary storage space on a grid is needed, the number of words may be irrelevant. #!/bin/bash
# -----------------------------------------------------------------------------
# LAFSify: derive an Electrum wallet from any given Tahoe-LAFS writecap
#
# requires expect, hURL, and jq
# https://github.com/atweiden/dotfiles/blob/master/_functions.d/functions/lafsify.sh
# -----------------------------------------------------------------------------
function lafsify() {
echo -n 'Enter your Tahoe-LAFS writecap: '; read WRITECAP
SEED=$(hURL -s --no-color --HEX $WRITECAP)
expect <<EOF
spawn electrum -w electrum-lafs.dat restore -o -C
expect "Password*" {
send "\r"
}
expect "fee*" {
send "\r"
}
expect "gap*" {
send "\r"
}
expect "seed*" {
send "$SEED\r"
}
expect eof
EOF
MNEMONIC=$(electrum -w electrum-lafs.dat getseed -o | jq -M '.mnemonic')
echo "Your Tahoe-LAFS writecap: $WRITECAP"
echo "Your resulting Electrum wallet seed: $SEED"
echo "Your resulting Electrum wallet mnemonic: $MNEMONIC"
}
function unlafsify() {
echo -n 'Enter your Electrum-LAFS mnemonic: '; read MNEMONIC
expect <<EOF
spawn electrum -w electrum-lafs.dat restore -o -C
expect "Password*" {
send "\r"
}
expect "fee*" {
send "\r"
}
expect "gap*" {
send "\r"
}
expect "seed*" {
send "$MNEMONIC\r"
}
expect eof
EOF
SEED=$(electrum -w electrum-lafs.dat getseed -o | jq -M '.seed')
WRITECAP=$(hURL -s --no-color --hex $SEED)
echo "Your starting Electrum wallet mnemonic: $MNEMONIC"
echo "Your starting Electrum wallet seed: $SEED"
echo "Your resulting Tahoe-LAFS writecap: $WRITECAP"
}
Using URI:DIR2:65sm34olspfc5msodmptuckpne:yrpwyrha3sqlx5qst3w7l724ebbqyotobsjaoyi7pamt52xrfo5q ... we get the 57-word mnemonic: "knee drink survive keep glove story existence brown sunlight jump suddenly slide hate gun group thorn curve family been energy squeeze brain visit strain passion spill driver take pierce end sway unable wrinkle youth grey forgive dirty tough impossible ship throne born need suddenly march reason caress moan carve drive soar shirt team weary began movie string" Running it backwards works as well. The more interesting aspect of this is it gives each Tahoe writecap its own deterministic Bitcoin wallet. It's also possible to make a simple brainwallet with it, but with Electrum you get a fully deterministic wallet with more features. Assuming the tahoe-client is running on a trusted local device, it may be possible for the writecap to autonomously negotiate for space in the storage grid to which it belongs. In particular, because the writecap is self-aware of its own Electrum seed, it could in theory create and authorize a micropayment channel with the tahoe grid. There are many workable variations to this approach. Only the user, and the machine controlled by the user, would know the Electrum wallet seed, because the seed would be the writecap. The writecap would need to stay a secret, but if so, the user could pay for a storage subscription by transferring coins into the writecap wallet. Payment is an entirely separate issue. Fundamentally, giving a person 57 words to write down or memorize, then ensuring him that his writecap will always be around with his files, regardless of what needs to happen on the server side, could be an issue for those seeking reliable long-term storage. I'm not clear on what happens if the grid introducer must be moved or replaced, or if this too could happen autonomously. Maybe it's possible to run an "ongoing" grid of some kind. Maybe the grid is created with X introducer.furl but later changes to Y introducer.furl, and all previously participating storage-node operators would update their node to point to Y introducer.furl. I don't know enough about Tahoe to say whether this negates the location of previously-created writecaps or if this is even a concern. |
|
|
|
|
I've encountered this problem numerous times with old coins, but I've always been able to send regardless. I'm thinking this section is in need of an FAQ.
I suspect the issue may have to do with each Bitcoin wallet containing a unique set of unspent outputs. We could conceivably work around this on the client by forcing Electrum users to select higher than average fees or forcing prioritization of larger unspent outputs, but the way it works currently, users have more control over how coins are spent.
In any case, if your wallet ever throws this error, consider taking the following two steps:
1. In the Receive tab (expert mode on), right-click on an address with a larger number of coins in it, and click "Prioritize". Resend.
I'd estimate just doing step #1 has worked for me over 75% of the time.
2. If step #1 fails, *increase the fee*. Resend.
You should be okay. I don't think this is overly costly in terms of time or money, but we could conceivably handle the error in the GUI more gracefully, so that users aren't left with an indecipherable error code without any hint as to how they may work around it. A link to an FAQ at the least may help. I've been meaning to come up with one myself. Lots more documentation is needed. A significant amount of work has gone into the upcoming major release, and the Electrum community has really been innovating as of late on all aspects of the client.
Again, I suspect this "type -22" issue is encountered because each Electrum wallet history is unique. If you run Linux or Mac, on the command line you can check your wallet's unspent output tree for yourself by running `electrum listunspent`. You may find that your wallet has a higher number of low-value unspent transactions. You should be able to work around this in the GUI by either increasing the fee or prioritizing an address with a larger unspent transaction 'attached to it'.
I profusely apologize if this error cost you a trade. It should be an avoidable, uncommon annoyance now that you know how to work around it.
|
|
|
|
What is your operating system, and what version of electrum are you using? Some things you can try (if not already tried): - right-click on an address in the receive screen, prioritize it - open/close wallet - connect to a new server - restore from seed - increase the fee If you've tried all of the above, but you're still receiving this error, you can manually create, sign and send raw transactions with the electrum CLI as follows (on Linux, experts only): [live01@Archey ~]$ electrum -w wallet.dat listunspent
[
{
"address": "1AwViD7ewnVVrzt58ffQdheyTxMGhAshJ6",
"index": 0,
"raw_output_script": "76a9146d078f704c400f1840d02f4239ea8f40ce5a847488ac",
"tx_hash": "cfed2aac04b2823a679d5d5956462b086ac8d47252d0a5506f9b8d5172d99f75",
"value": "4"
}
]
[live01@Archey ~]$ electrum -w wallet.dat createrawtransaction '[{"txid" : "cfed2aac04b2823a679d5d5956462b086ac8d47252d0a5506f9b8d5172d99f75","vout":0}]' '{"34PTJeM3gtGSk3fqAJ4iWcEsbip46cbDVw":0.001,"1MbbbLkwLUvP4hXiDLE1Ma42sz9T3J89TG":3.9988}'
{
"complete": false,
"hex": "0100000001759fd972518d9b6f50a5d05272d4c86a082b4656595d9d673a82b204ac2aedcf0000000000ffffffff02a08601000000000017a9141d9613bb16091ab2876c829e6bd5f56bed14b9ed8740afd517000000001976a914e1ed88cdd3ff3eead6ebffca4493465b44db983a88ac00000000",
"input_info": "[{\"redeemScript\":null,\"signatures\":null,\"vout\":0,\"txid\":\"cfed2aac04b2823a679d5d5956462b086ac8d47252d0a5506f9b8d5172d99f75\",\"KeyID\":null,\"pubkeys\":null,\"scriptPubKey\":null}]"
}
[live01@Archey ~]$ electrum -w wallet.dat signrawtransaction '0100000001759fd972518d9b6f50a5d05272d4c86a082b4656595d9d673a82b204ac2aedcf0000000000ffffffff02a08601000000000017a9141d9613bb16091ab2876c829e6bd5f56bed14b9ed8740afd517000000001976a914e1ed88cdd3ff3eead6ebffca4493465b44db983a88ac00000000'
Password:
{
"complete": true,
"hex": "0100000001759fd972518d9b6f50a5d05272d4c86a082b4656595d9d673a82b204ac2aedcf000000008b483045022100a8065915b3ad1fa3e41db8d06cecdc11a938671369707e2ee390c1452eb930aa02202dde6b18a6c9f54497ef719784feb9e0a8cb5fc4007ac4f40c5dc73bb3cb6a130141045ce62c5a778c083f623e720e99e00e56235578d22c4b7cebec5c42d4cf86d1b8aa5af0f1f5846e899c98605cbad41a4161d200ce929db5e867977912c2415340ffffffff02a08601000000000017a9141d9613bb16091ab2876c829e6bd5f56bed14b9ed8740afd517000000001976a914e1ed88cdd3ff3eead6ebffca4493465b44db983a88ac00000000"
}
[live01@Archey ~]$ electrum -w wallet.dat sendrawtransaction 0100000001759fd972518d9b6f50a5d05272d4c86a082b4656595d9d673a82b204ac2aedcf000000008b483045022100a8065915b3ad1fa3e41db8d06cecdc11a938671369707e2ee390c1452eb930aa02202dde6b18a6c9f54497ef719784feb9e0a8cb5fc4007ac4f40c5dc73bb3cb6a130141045ce62c5a778c083f623e720e99e00e56235578d22c4b7cebec5c42d4cf86d1b8aa5af0f1f5846e899c98605cbad41a4161d200ce929db5e867977912c2415340ffffffff02a08601000000000017a9141d9613bb16091ab2876c829e6bd5f56bed14b9ed8740afd517000000001976a914e1ed88cdd3ff3eead6ebffca4493465b44db983a88ac00000000
Connected to electrum.pdmc.net:50002
"be96b4426ca9ecff46a45c90f2ffbd12af5ea42c590180d309a5958a1327fa50"
"{u'message': u'TX rejected', u'code': -22}" is an annoyance, but I've always been able to get around it by playing with the GUI. I've never had to resort to the CLI, except when guiding Macbookers through this process, as they can't seem to prioritize addresses from the GUI. |
|
|
|
|
IME, Linden Labs was rather uncooperative about lifting my BTC/L$ trading limits. At least for me, this wasn't a reliable way to acquire crypto.
|
|
|
|
|
