Have you conceded using the Stratum protocol? http://stratum.bitcoin.cz/So instantly on first load Armoury, can be functional as a Bitcoin wallet... Then it could start loading the Bitcoin chain in the background, and eventually offering the hosing the stantum protocol to other Armoury (and electrum and any other thin client). It would be best if the Armoury could connect to 10 or 20 different other thin Stratum servers, so one bad server won't be able to scam. I have not decided how to do it, yet, but I know what I want: (1) Even before a networking-independent solution, I plan to have Armory insta-load, but into a reduced-functionality interface. Then the blockchain stuff can load in the background, and unlock those interface elements when it's done. The user will be able to do wallet management while that is happening. (2) I'm not going to rely on a separate network of servers. Accessing the Bitcoin network as it was originally intended offers me the highest level of security and reliability, and that's worth it even if it's inconvenient. I see too many issues relying on an out-of-band network of servers that could be compromised or modified underneath me. I'm not saying there's anything wrong with an overlay network. But for standard blockchain operations, I want to rely on the BTC network as it was originally designed. (3) However, I will likely use an existing, battle-hardened codebase to implement the peer discovery, networking protocol and full chain verification. I'm still undecided whether that will be some modification of bitcoind, libcoin or libbitcoin. Recommendations are welcome. Can I use patched Bitcoin Clients, like coderrr's, with Armory?
I've never tried it, but there's no reason it wouldn't work. As long as it runs on the default bitcoind port and implements the same networking protocol, it should be fine. |
|
|
|
So how much profit has satoshidice made so far?
I will tell you it's a negative number so far which has totally ruined my week  etotheipi - I'll have the developer check on your info, thank you for the analysis. Erik, Sorry for being out of the loop, but are you part of SatoshiDice.com? I have no idea who's running it, I just know all the transactions are public and it's "easy" to collect the statistics. And I like statistics  It looks like the site is down about 80 BTC total since it started. Though, that number seems to fluctuate significantly -- statistically speaking it takes a long time for a 1% edge to prevail over the statistical variance of the game and 80 BTC is small compared to the 18,500 BTC wagered so far... I am curious what happened to that 1% of unreturned transactions. In case you want it, I posted the list of all unreturned transactions to my public dropbox folder. |
|
|
|
Just for reference (sorry Stephen), I started doing my own stats on SatoshiDice.com using Armory's blockchain tools. It appears that 1% of transactions are not returned, but even without those the stats look fairly reasonable so far. In fact, SatoshiDice.com has lost money so far... The latest data (as of this post) is copied below, but I'm updating this thread daily. Results: 2012-May-12 10:59pm
Address Target Should Win | #Bets | Win | Lose | Refunds | Accounted-for
----------------------------------------------------------------------------------------------------------------------
1dice1e6p 1 0.00002 | 2439 | 0 (0.00000) | 2346 (1.00000) | 92 (0.03922) | (1.000)
1dice1Qf4 2 0.00003 | 106 | 0 (0.00000) | 88 (1.00000) | 16 (0.18182) | (0.981)
1dice2pxm 4 0.00006 | 643 | 0 (0.00000) | 631 (1.00000) | 10 (0.01585) | (0.997)
1dice2vQo 8 0.00012 | 85 | 0 (0.00000) | 71 (1.00000) | 12 (0.16901) | (0.976)
1dice2WmR 16 0.00024 | 83 | 0 (0.00000) | 73 (1.00000) | 7 (0.09589) | (0.964)
1dice2xkj 32 0.00049 | 62 | 0 (0.00000) | 54 (1.00000) | 5 (0.09259) | (0.952)
1dice2zdo 64 0.00098 | 312 | 0 (0.00000) | 302 (1.00000) | 7 (0.02318) | (0.990)
1dice37Ee 128 0.00195 | 590 | 0 (0.00000) | 583 (1.00000) | 2 (0.00343) | (0.992)
1dice3jkp 256 0.00391 | 96 | 1 (0.01163) | 85 (0.98837) | 4 (0.04651) | (0.938)
1dice4J1m 512 0.00781 | 359 | 3 (0.00847) | 351 (0.99153) | 1 (0.00282) | (0.989)
1dice5wwE 1000 0.01526 | 441 | 7 (0.01602) | 430 (0.98398) | 0 (0.00000) | (0.991)
1dice61SN 1500 0.02289 | 266 | 5 (0.01901) | 258 (0.98099) | 0 (0.00000) | (0.989)
1dice6DPt 2000 0.03052 | 317 | 8 (0.02556) | 305 (0.97444) | 1 (0.00319) | (0.991)
1dice6gJg 3000 0.04578 | 275 | 11 (0.04059) | 260 (0.95941) | 0 (0.00000) | (0.985)
1dice6GV5 4000 0.06104 | 265 | 11 (0.04198) | 251 (0.95802) | 0 (0.00000) | (0.989)
1dice6wBx 6000 0.09155 | 537 | 45 (0.08491) | 485 (0.91509) | 1 (0.00189) | (0.989)
1dice6YgE 8000 0.12207 | 720 | 94 (0.13128) | 622 (0.86872) | 0 (0.00000) | (0.994)
1dice7EYz 12000 0.18311 | 1065 | 214 (0.20170) | 847 (0.79830) | 0 (0.00000) | (0.996)
1dice7fUk 16000 0.24414 | 1395 | 321 (0.23094) | 1069 (0.76906) | 1 (0.00072) | (0.997)
1dice7W2A 24000 0.36621 | 3881 | 1506 (0.39026) | 2353 (0.60974) | 2 (0.00052) | (0.995)
1dice8EMZ 32000 0.48828 | 14008 | 6812 (0.48975) | 7097 (0.51025) | 10 (0.00072) | (0.994)
1dice97EC 32768 0.50000 | 12134 | 5852 (0.49555) | 5957 (0.50445) | 11 (0.00093) | (0.974)
1dice9wcM 48000 0.73242 | 5844 | 4229 (0.72851) | 1576 (0.27149) | 8 (0.00138) | (0.995)
1dice9wVt 64000 0.97656 | 1497 | 1454 (0.97912) | 31 (0.02088) | 7 (0.00471) | (0.997)
----------------------------------------------------------------------------------------------------------------------
| 47420 |
----------------------------------------------------------------------------------------------------------------------
Total Bets Made: 47420
Cumulative Wagers: 18277.28493525 BTC
Cumulative Rewards: 18336.91450091 BTC
Cumulative Fees Paid: 23.58400000 BTC
Cumulative Unreturned: 76.44369013 BTC
----
SatoshiDice Profit/Loss: -83.21356566 BTC
|
|
|
|
I dug a little deeper to find out if the unaccounted-for bets are a real issue with the SD service, or if it's a bug in my script. I got my script to print out the list of unaccounted-for bets and then I randomly selected 4 of them. Sure enough, block-explorer says those wagers have not been redeemed yet. (I doubt anyone cares about the full-list, but I can give it if you're interested): http://blockexplorer.com/tx/968a692ab98b1f275c635c76be003ab1db9740d0b62f338b270115342ca42f5bhttp://blockexplorer.com/tx/931fbfc921291aaa8a4cd3d26e71f513143ddcd3ae97da37ed6db1266a9058fdhttp://blockexplorer.com/tx/7719d3f8c1bacd64b8e38a76c6ab1d5f4071ecc06fce82f7409d6a4ec265504bhttp://blockexplorer.com/tx/fbb636d434b556cb1c6ae80e0e5a76eec05fb7c85ab7fffcf90fdb5b40b56987--The sum of all unaccounted-for wagers is 85 BTC. I didn't do statistics on how that 85 BTC was distributed, so it's tough to tell how much they should've statistically paid out on these 85 BTC. If they were all losing bets, SD would've paid out another 0.85 BTC. Upper limit cannot be investigated without more work... --I would hypothesize that for these 500 of 47,000 unrewarded bets, that they were paid out in another way. But my previous scanning watched for return tx to the first sending address of the wager transaction, and I got the same results. This means, that at least there was no automated payout. Luckily the number of these is low, so probably don't skew the statistics too much, except for the 1dice3jkp which is missing 6% of the bets! --I also rescanned just since block 179,000 to see if they have gone away (suggesting that it was an early bug in the service). That's not the case. There's still plenty of unaccounted-for bets in the last 800 blocks. -- Therefore, it seems that SatoshiDice occasionally doesn't return bets! I suppose it is possible that these bets are manually executed after a user does not get his payout and contacts the service. However, there's no way to know for sure. By the way, the cumulative wagers at the bottom do include these unrewarded wagers. The "Cumulative Rewards" is probably artificially low. SD is probably either slightly more red, or should be if they had to pay out on those unaccounted for bets. |
|
|
|
Finally! Computed total profit/loss for SatoshiDice. Looks like luck is not really working in their favor at the moment... Total Bets Made: 46518
Cumulative Wagers: 17681.71709911 BTC
Cumulative Rewards: 17830.07320735 BTC
Cumulative Fees Paid: 23.16950000 BTC
----
SatoshiDice Profit/Loss: -171.52560824 BTC
I forgot that all SatoshiDice bets are returned by spending the wager transaction, which is what I should've been searching for when scanning the blockchain. So I modified the script to search for wagers and then subsequent spends of those wagers...and I got the same results. Still a few that aren't accounted for, but those shouldn't substantially skew the results... I suppose it's possible that they were transactions lost during debugging before SD was officially released...? For now, I need to get back to Armory development. But I will keep this table/data updated daily, and eventually add confidence intervals and possibly localized statistics (last week, last 24H, etc). Possibly figure out how to start auto-updating... |
|
|
|
I am also leaning toward trying the Armory wallet app. I am looking into the paper wallet a little more too. ... I won't have any appreciable amount of bitcoins in my wallet until after that anyway so for now I'll see how it goes with the deletion, new download and maybe the Armory wallet.
For reference, when you create a new wallet with Armory, you can print a paper-backup with every address ever created by that wallet on one sheet of paper (it's 128 characters from which all private keys are generated). You technically don't have to print it, you can just copy it down by hand if you can't get the printer working. You can recover all of your funds at any time in the future if you have those 128 characters. (although if you import any keys, they have to be backed up separately...) Further, if you instead wanted to switch to another program, you can copy or print the individual private keys for each address you've used, which can then be imported into another application or service that supports importing addresses. I'm not sure if that's what people mean when they say "paper wallets". |
|
|
|
Thanks. I am doing this largely to learn as well as to create something functional. The images you have made a pretty nice. Would I be able to use them in my documentation? I do hope to build a nice documentation for my library.
Go ahead. Attribution is preferable, but I'm really just happy if other people get use out of them. Maybe I can save you the 2 days I spent battling endianness and the OP_CHECKSIG wiki page trying to figure out how the hell to implement it! |
|
|
|
I am leaning toward just deleting my all my bitcoin software including the wallet then redownloading them. I am also thinking about the Armory offline wallet. The way that is set up looks pretty good and definitely secure. No one could send anything out without getting a signature from my offline computer. Does anyone know anything about Armory? Can tracking the transaction tell me anything useful? From what I see it goes to the receive address which has 31 transactions for a total of 24.3 bitcoins all of which were immediately transferred. My 10.33 is in there.
I would advise re-installing your operating system. Any "respectable" virus has embedded itself in your OS, and there's no way to know if it's truly been purged. Sure, some A/V can get rid of certain viruses... But in my experience, it's actually easier and much more secure to just wipe your whole hard-drive and reinstall the OS. But I'm slightly biased ... I have done this so many times (for a variety of reasons, not usually viruses) that I can be back up and running like before the reinstall in one evening. Either way, there's a lot of peace of mind knowing that no virus can survive an OS reinstallation... Feel free to PM me if you have any questions about Armory. I'll be happy to help you get setup with it, or answer any questions you have about security or usage. (or ask the questions here, if you don't mind derailing your own thread ) P.S. -- Here's the official forum thread on Armory, though I haven't been updating this page much anymore. I've been trying to use the bitcoinarmory website more for such things... |
|
|
|
Fair enough. I was focusing on the case that you need to prove to a court that you are the original owner. It's just as easy to use one key as it is two keys for that initial blockchain injection which proves "Joe Schome < joe.shmoe@schmoeblog.com>" owned the key at least as early as <insert time here>. Regardless of a second key... The real issue is that most users don't actually do this, leaving open the possibility that someone steals your keys, and then does it themselves, claiming that you stole their keys and furnishing their "proof" to claim legal ownership. It's difficult to distinguish that situation from the normal situation where this succeeds. Therefore, I don't how this would be too useful right now, until it becomes so widely used that users are expected to use it. Otherwise, I like the idea. It could be done once per deterministic wallet, which could then be used to prove that you own every key in the wallet. If blockchain bloat was a problem, there could be a free service that collects such signatures, jams them into a merkle tree, and posts the root into a single tx so that minimal coins and kB are wasted for the timestamping. The service wouldn't even really have to be trusted, you just need to get the merkle tree and save it with your data and you can verify it yourself. This would be preferable to doing it yourself, since you might have reasons to be doing high-frequency timestamping, which costs nothing computationally, but could add up in fees/burnt coins and blockchain bloat. |
|
|
|
|
Why do you need to use the non-Bitcoin key for anything?
Why not just sign a message declaring your name, email, etc, using your Bitcoin private key, then hash160 that msg+signature, and send 0.0001 BTC to it using the blockchain as a timestamp server? The inclusion into a block is all that is needed for timestamping, and it still can't be produced by anyone except for the owner of the Bitcoin address.
|
|
|
|
I fully approve of this effort. Many told me that it was a waste of time to reimplement Bitcoin, but there's no better way to learn everything than to do it yourself. It's not always pleasant (especially that goddamned endianness!), but it is extraordinarily educational and rewarding by the time you do get it. I feel like anyone who's going to participate in serious discussions about protocol, client design/features, or contribute to any Bitcoin project at all, should have this kind of experience. I started about 10 months ago, and did a little bit of documentation as I went. I expect you'll find this useful https://bitcointalk.org/index.php?topic=29416.0Feel free to PM me if you have any implementation questions. I've been through just about all of it by now. Half of it in C++, half in Python... (though I never bothered with bignum/base58 in C++... I track everything by hash160 values and let Python deal with Base58 using its native bignum capability). |
|
|
|
Or use Armory Offline Wallets to keep your Bitcoins off the internet completely. It's designed to protect against exactly this... I just made an Armory-plus-all-dependencies bundle that will work out of the box on Ubuntu 10.04 without ever touching the internet. Especially good if you have an old laptop laying around with 256 MB of RAM. Disable the wifi & bluetooth & ethernet in the BIOS, install Ubuntu 10.04 32-bit with all defaults, and then copy this file on there and run the "Install_All_Armory.sh" script. Create your wallet, and make a watching-only copy to put on your internet-connected computer. Of course, you need Armory on the online computer, too, but it's not a problem if it is Windows, even if the offline system is Linux. For more information, there's an Offline Wallet Tutorial on my website. </spam> |
|
|
|
So how much profit has satoshidice made so far?
Good question! I'll add that to my script... as soon as I finish releasing Armory 0.76 (which will hopefully be tonight!) I will have to expand the script a little bit, to be able to determine transaction fees. But it can be done... |
|
|
|
I thought all reward transactions included the wager transaction as an input. Thus, if someone invalidated the wager by double-spending, they'd also invalidate the reward transaction. And thus it would be pointless.
But if I can double spend (e.g., Finney attack) to invalidate only my losing wagers, did I really lose? See: - http://bitcointalk.org/index.php?topic=77870.msg882919#msg882919It seems I'm a little late to that conversation. But it seems to me that the most basic attack for an arbitrary individual is simply trying to broadcast competing transactions at the same time. But if there's any chance for it to succeed, it has to be done right away before you know if you've won. Thus, you'd invalidate half of your losers and winners. Other attacks, while possible, are generally reserved to a select few people who have > 1% of mining power, and to bets that are significantly over the maximum bet rate right now and would not be worth it. On the other hand, I could see that the time delay could allow SatoshiDice to queue up a few transactions, and rearrange their ordering to try to maximize the number of losing bets made. They have pre-scripted, verifiable secrets, but there's no way to prove the order in which they received certain transactions. If this were the case, it would be reflected in the stats... Btw, I love the SatoshiDice concept. I really like the transparency of it, too. It's a very elegant, open setup that gives me confidence they are legit. But you don't know for sure until you do some hard number crunching P.S. -- I just updated the table. About 35k bets total as of midday May 10. And the stats looks fairly consistent with expectations... |
|
|
|
a quick basic question: would it be possible for any third party to alter these statistics if he was generating 1diceXXX vanity addresses and sending random transactions around?
My script uses the list of 24 addresses from satoshidice.com. I do not track all addresses that start with "1dice", only the ones from that site. So that's not an issue. |
|
|
|
But any transfer within the accepted range is a wager, and thus gets played and the return transaction created. I can''t think of anything further that this third party could do (or why) to mess with the site. (well, the Satoshi Dice site does describe other attack vectors, but they are precise and require double spending using Finney attack or other methods.)
I thought all reward transactions included the wager transaction as an input. Thus, if someone invalidated the wager by double-spending, they'd also invalidate the reward transaction. And thus it would be pointless. |
|
|
|
Easier access to the blockchain like this for reporting purposes will be very useful. Thank you for doing this!
Once I fill it up a little more (with localized statistics and confidence bounds), I might modify the version of Armory I'm running to leverage the already-loaded blockchain. That way, I can recalculate all the stats every 5 min and update a plot somewhere... Why? I don't know... because I'm a statistician and I can. I guess I spent of lot of months online playing poker, and spent time on the 2+2 forums doing similar analysis to try to identify players or phenomenon that were suspicious. I guess it's one way to keep the gambling sites honest... |
|
|
|
Here's the latest output:
Results: 2012-Jun-11 05:49pm
Address Target Should Win | #Bets | Win | Lose | Refunds | Accounted-for
----------------------------------------------------------------------------------------------------------------------
1dice1e6p 1 0.00002 | 3964 | 0 (0.00000) | 3810 (1.00000) | 153 (0.04016) | (1.000)
1dice1Qf4 2 0.00003 | 231 | 0 (0.00000) | 192 (1.00000) | 39 (0.20312) | (1.000)
1dice2pxm 4 0.00006 | 722 | 0 (0.00000) | 699 (1.00000) | 23 (0.03290) | (1.000)
1dice2vQo 8 0.00012 | 274 | 0 (0.00000) | 238 (1.00000) | 31 (0.13025) | (0.982)
1dice2WmR 16 0.00024 | 208 | 0 (0.00000) | 187 (1.00000) | 21 (0.11230) | (1.000)
1dice2xkj 32 0.00049 | 266 | 0 (0.00000) | 256 (1.00000) | 10 (0.03906) | (1.000)
1dice2zdo 64 0.00098 | 587 | 0 (0.00000) | 575 (1.00000) | 12 (0.02087) | (1.000)
1dice37Ee 128 0.00195 | 1477 | 0 (0.00000) | 1447 (1.00000) | 24 (0.01659) | (0.996)
1dice3jkp 256 0.00391 | 665 | 3 (0.00462) | 647 (0.99538) | 11 (0.01692) | (0.994)
1dice4J1m 512 0.00781 | 1018 | 7 (0.00694) | 1001 (0.99306) | 3 (0.00298) | (0.993)
1dice5wwE 1000 0.01526 | 1479 | 20 (0.01360) | 1451 (0.98640) | 1 (0.00068) | (0.995)
1dice61SN 1500 0.02289 | 1294 | 30 (0.02331) | 1257 (0.97669) | 3 (0.00233) | (0.997)
1dice6DPt 2000 0.03052 | 1042 | 31 (0.02998) | 1003 (0.97002) | 1 (0.00097) | (0.993)
1dice6gJg 3000 0.04578 | 1531 | 76 (0.04990) | 1447 (0.95010) | 5 (0.00328) | (0.998)
1dice6GV5 4000 0.06104 | 1034 | 65 (0.06341) | 960 (0.93659) | 2 (0.00195) | (0.993)
1dice6wBx 6000 0.09155 | 2644 | 235 (0.08912) | 2402 (0.91088) | 2 (0.00076) | (0.998)
1dice6YgE 8000 0.12207 | 2679 | 302 (0.11341) | 2361 (0.88659) | 0 (0.00000) | (0.994)
1dice7EYz 12000 0.18311 | 8531 | 1608 (0.18869) | 6914 (0.81131) | 2 (0.00023) | (0.999)
1dice7fUk 16000 0.24414 | 18771 | 4537 (0.24193) | 14216 (0.75807) | 3 (0.00016) | (0.999)
1dice7W2A 24000 0.36621 | 12379 | 4585 (0.37119) | 7767 (0.62881) | 21 (0.00170) | (1.000)
1dice8EMZ 32000 0.48828 | 152129 | 73941 (0.48665) | 77998 (0.51335) | 93 (0.00061) | (0.999)
1dice97EC 32768 0.50000 | 84005 | 41997 (0.50029) | 41948 (0.49971) | 30 (0.00036) | (1.000)
1dice9wcM 48000 0.73242 | 50569 | 37147 (0.73577) | 13340 (0.26423) | 18 (0.00036) | (0.999)
1dice9wVt 64000 0.97656 | 3421 | 3265 (0.97842) | 72 (0.02158) | 76 (0.02277) | (0.998)
----------------------------------------------------------------------------------------------------------------------
| 350920 |
----------------------------------------------------------------------------------------------------------------------
Total Bets Made: 350920
Cumulative Wagers: 146956.50238462 BTC
Cumulative Rewards: 147354.43403819 BTC
Cumulative Fees Paid: 176.23022500 BTC
Cumulative Unreturned: 121.09935596 BTC
----
SD Profit on Completed Bets : -695.26123453 BTC
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 1073735 : SatoshiDice Tx: 690349 (64.3%)
Blockchain MB: 453.9 : SatoshiDice Tx: 275.3 (60.7%)
I grab satoshidice.com (via urllib.urlopen(' http://satoshidice.com')) and pull out all 24 addresses and current odds, etc. Then, I scan the blockchain starting at block 175k, collecting all bets made to any of the 24 "1dice" addresses, and then look for transactions that spend the wager transaction (because Satoshi dice always spends the wager transaction to send rewards, which helps protect against double-spends). All bets are recorded as Win, Lose, or Refund. If a user sends more than the maximum bet, it will be refunded. That is a non-negligible number of the bets made, especially the 65000x bets. The percentages under "win" and "lose" are only for the subset of win/lose bets, i.e. win/(win+lose) and lose/(win+lose). Refunds are not counted except to fill int the "accounted-for" field which simply identifies how many bets there are in the blockchain that could be associated with reward/return payments. The script is using armoryengine.py to scan the blockchain for SatoshiDice bets and rewards, and then compute statistics. The exact code is at the bottom of sample_armory_code.py in the BitcoinArmory project. If you want to try running it yourself, you're going to have to check out the project and compile the CppBlockUtils library yourself. It's really not hard in Linux... it's really hard in Windows... |
|
|
|
I'm currently trying to write a program that connects multiple addresses to "entities". If there are 2 (or more) inputs used in a transaction, I assume that these belong to the same person. Atm all I want to do is to get a transaction and then get a list consisting of either ["Mined"] (if it was a coinbase) or the input address(es). ... getSenderAddrIfAvailable() however seems not to catch a lot of input addresses, compared to your "count all addresses" that just counts the txouts I get only a fraction. I already read the comment // Not all TxIns have sendor info. Might have to go to the Outpoint and get
// the corresponding TxOut to find the sender. In the case the sender is
// not available, return false and don't write the output but I'm kinda lost after calling txin.getOutPoint() - how do I then get to the OutTx object again and how do I know which of it's (possibly multiple) output addresses is the input address I'm looking for? I wrote a special method in the BlockDataManager specifically for this situation (and I use it all the time). It's because you can't always determine the identity behind a TxIn without actually retrieving the previous Tx that is being spent. Thus, you need the help of the BlockDataManager, because a Tx object knows nothing about other transactions! What you're looking for is this: theTxIn = tx.getTxInRef(i)
senderAddr20 = TheBDM.getSenderAddr20(theTxIn)
Method "getSenderAddrIfAvailable()" does exactly what it says: if it can deduce it from the TxIn, then it will return it. However, coinbase TxIns do not have that info (though it could usually be deduced using some fancy math, but I never got around to implementing that). |
|
|
|
I downloaded version 0.75.1 and 0.76 and I can't migrate my Bitcoin wallet. It was never touch by the Bitcoin client version 0.6.
With both version 0.75.1 and 0.76, when I click on the migrate button nothing happen...
Do I have to close the Bitcoin client before trying to migrate the wallet?
Thanks
Interesting. Admittedly, I haven't put much extra thought or effort into the migration since I realized that it's going to be of limited value until I can support 0.6.0 (compressed public keys). So I've kind of been neglecting it... Are you in Windows or Linux? If you are in Linux, you can help identify the problem by running it from the command line and observing the error output. python /usr/share/armory/ArmoryQt.py If not, then I guess I'll have to bump getting a "proper logging system" implemented up on the list of priorities. I'm not sure how to figure it out without... I recognize it's not the best option, but if you can always create new addresses and send coins to it. It's is a universal way to migrate funds between Bitcoin clients The new wallet format is on hold while the main devs sort out the new wallet details, and I have a couple high priority things to do before then, anyway. It might be a month before I can get to it... |
|
|
|
|
Show Posts
