Armory - Discussion Thread - page 183.

Gladamas

sr. member

Activity: 294

Merit: 250

Bitcoin today is what the internet was in 1998.

Quote from: etotheipi on July 07, 2012, 12:20:25 AM

Quote from: Gladamas on July 07, 2012, 12:10:48 AM

Ah, I forgot to mention, every time I start an Armory instance that crashes later, it won't receive (show or give any indication of) a new transaction coming to one of its Bitcoin addresses. The transactions are in the blockchain but won't show up. I forgot if it ahows the correct block number or not, though. Perhaps the crash occurs when Armory receives a second transaction (after the first that it didn't show?) Just a WAG.

Do you mean, "when Armory is getting ready to crash, it no longer shows any new transactions until you restart?"

That is correct. When I start an Armory instance, it either will crash later or it won't crash later. If I start an Armory instance that will crash, then it won't record any received (to-my-wallet) transactions in the ledger. I'm not sure if restarting works or not.

Quote from: etotheipi on July 08, 2012, 10:49:28 AM

@ Gladamas

FYI, my Win7-64bit VM with 2GB of RAM and Bitcoin-Qt 0.6.3 has had Armory open for 2 days and has not crashed yet. So, unless there is a specific trigger someone can point me to, I'm going to have to let this bug through for now. Please let me know more details about the crashing, and hopefully I'll find a way to replicate it in the future.

However, I'm very close to a 0.82.1 version with full logging. This will improve the situation a lot, since every crash can now be accompanied by a full log file of every informational message and error message, without the user even doing anything. I will hopefully have that out tonight, and those of you experiencing crashes will only have to send me your armorylog.txt file after the crash.

Thank you, I will give you whatever information I can if I have any. I haven't noticed any particular trigger but that log-file should help.

Say you open a window that lists all of your private keys (export keys function.) Will Armory record those keys in the log-file? If you send BTC to someone, will it log the transaction amount/etc. in the log-file?

Thank you for you work on this!

BadBitcoin (James Sutton)

donator

Activity: 452

Merit: 252

Raoul Duke

legendary

Activity: 1358

Merit: 1002

When I mentioned fixed withdrawal addresses is because the services don't allow to change them, not because I'm attached to them.
There is a way for those service owners to change them, I'm just sure most will not do it easily when asked to because they used fixed withdrawal addresses for security reasons.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Raoul Duke on July 08, 2012, 12:13:59 PM

I can tell you that I use mostly Bitcoin-qt because I can't import the wallet to Armory. If I could I would start using Armory to manage multiple wallets, one of them being my Bitcoin-qt wallet, which has about 4000 addresses in there, being some of them fixed withdrawal addresses from services I use and which I have no way to change.
So, instead of using Armory and switching back to Bitcoin-qt to manage my main wallet, I just use Armory for cold storage and nothing else.

With all that said, you are losing by not importing those wallets. Losing on beta testers, at least. Wink

Fair enough. I hadn't considered fixed withdrawal addresses. I mean, they really shouldn't be "fixed", there is a way to change them... but I recognize the inconvenience to the user. That's in the category of "attached to addresses", but I underestimated the level of "attachment" that some folks have to their Bitcoin-Qt addresses.

On that note, my warning is still valid:

(1) Some keys (like vanitygen, or pre-0.6.0 addresses) can still be imported. Please be careful when doing this. Locked coins are recoverable, but it's going to be a pain in the ass to fix it. If you are running in both programs, do not spend from two different programs/wallets using the same address without waiting for a couple confirmations in between.
(2) Even if you do have an attachment to Bitcoin-Qt addresses, I would not think about migrating unless you are ready to go 100%. I recommend creating a new Armory wallet, send it some coins, and experiment with that. At some point, you may decide it's worth the effort to change receiving addresses (email people, change service settings, etc) to use your new wallet. Because 0.6.X support just cannot happen in the next month or two...

Raoul Duke

legendary

Activity: 1358

Merit: 1002

I can tell you that I use mostly Bitcoin-qt because I can't import the wallet to Armory. If I could I would start using Armory to manage multiple wallets, one of them being my Bitcoin-qt wallet, which has about 4000 addresses in there, being some of them fixed withdrawal addresses from services I use and which I have no way to change.
So, instead of using Armory and switching back to Bitcoin-qt to manage my main wallet, I just use Armory for cold storage and nothing else.

With all that said, you are losing by not importing those wallets. Losing on beta testers, at least. Wink

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: BadBitcoin (James Sutton) on July 08, 2012, 11:22:11 AM

can't wait to use this! However the non importing feature from wallets in 0.6.XX makes this distro completely useless for me, any ETA on when the new version supporting 0.6.2 will be released?

First of all, it's going to be a little while. I need a new wallet format. Read a few messages back in this thread for more info.

Second of all, why is this such a dealbreaker for folks? I'm not looking down on anyone for this, I just don't understand why this feature is so critical -- in fact, it's going to cause so many problems for people I don't even want to do it. Bitcoin-Qt is especially not suited for multiple programs using the same addresses at the same time -- users will end up with locked coins and incorrect balances and it's really difficult to fix.

(1) Even if you can import your whole bitcoin-qt wallet, only the exact addresses you import will be useful. All new addresses produced by Armory and Bitcoin-qt will be different. This is one reason that, if you are going to import any Bitcoin-qt addresses, you should import all of them and then remove the wallet from Bitcoin-qt.
(2) If you're dealing with Vanitygen addresses: those are in the correct format already, so there's not problem there.
(3) If you're not sure yet whether you want to make the move, then you shouldn't be migrating anything. Please just create a new Armory wallet and move some/all of your coins to it. Move them back if you don't like Armory. So much heartache can be avoided this way.

I know that some people are attached to some of their addresses and that's why some people must have a migration feature. And some users want to be able to migrate your keys from an offline wallet without bringing it online. Those are two reasons that wallet migration should be a dealbreaker, but I thought it was a small percentage of users. What other reasons are there?

I am seriously frustrated, because I feel like migration feature is going to cause endless heartache and customer-support issues (locked coins are always a crisis). I just want to know why people are requesting this feature, and make sure that users who actually should not be using the migrate feature anyway, aren't passing up Armory because it's not there. (it sounds like I'm going to have to add all sorts of warnings to the program, akin to what I just warned in this post)

BadBitcoin (James Sutton)

donator

Activity: 452

Merit: 252

can't wait to use this! However the non importing feature from wallets in 0.6.XX makes this distro completely useless for me, any ETA on when the new version supporting 0.6.2 will be released?

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

@ Gladamas

FYI, my Win7-64bit VM with 2GB of RAM and Bitcoin-Qt 0.6.3 has had Armory open for 2 days and has not crashed yet. So, unless there is a specific trigger someone can point me to, I'm going to have to let this bug through for now. Please let me know more details about the crashing, and hopefully I'll find a way to replicate it in the future.

However, I'm very close to a 0.82.1 version with full logging. This will improve the situation a lot, since every crash can now be accompanied by a full log file of every informational message and error message, without the user even doing anything. I will hopefully have that out tonight, and those of you experiencing crashes will only have to send me your armorylog.txt file after the crash.

@ kuzetsa

Are you waiting for address migration to try out Armory at all? I highly recommend, even if migration was working, that you still create new addresses and send coins to them instead of importing just a couple addresses. When you "migrate" addresses to Armory, you should really stop using those addresses in bitcoin-qt. It really needs to be all-or-nothing. This will avoid lots of issues with maintaining the same address in multiple programs (coins can get locked, and balances will be incorrect in both programs). This is not an Armory limitation, it's an issue with Bitcoin-Qt which assumes no other program is using the same addresses.

Until then, you should create a new Armory wallet, send some coins to it, and if you want to go back, just send the coins back to your Bitcoin-Qt wallet.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: kuzetsa on July 07, 2012, 10:45:36 PM

Quote from: etotheipi on July 07, 2012, 10:08:36 PM

Quote from: kuzetsa on July 07, 2012, 09:42:33 PM

... migration from official latest (stable) satoshi client...

Oh, I need to add a warning about this. Private keys from Bitcoin-Qt version 0.6.0 and newer cannot be imported into Armory!. It's because they use "compressed public keys" which Armory doesn't support yet. I suspect that the key you tried to import was one of these compressed keys...

Yes. I think so --- Latest Bitcoin-Qt version: 0.6.3... which also includes the CLI version, bitcoind

... the command I used to grab my private key was one I issued via bitcoind.

suspect that bitcoind, apparently, uses the same format as bitcoin-qt and I guess that's just as incompatible.

I'd really like the option to be able to migrate to armory, at least to test a few things. Do you have any estimate for how long it would take to add support for the CURRENT private key format (0.6.x and newer) used in the official client?

I have a completely new wallet format in the works that will be able to support these private keys. It will have a plethora of other advantages (such as, it was developed by the Bitcoin-Qt devs to go into version 0.8.0 or something, so Armory will be natively compatible). However, this new format is going to take a while, because Armory wallet-handling code requires the utmost stability, and it requires testing up the wazoo. It may be a couple months before I can actually finish the implementation and confirm its stability.

And even if I wanted to make it highest priority right now, I also have to wait until the Bitcoin-Qt devs agree on the precise specification for the wallet algorithms, and I don't think that's been done yet. That's a variable I can't really control. And it is way too much work to re-do the wallet format just for compressed public keys.

So... I wouldn't hold your breath Undecided

kuzetsa

sr. member

Activity: 369

Merit: 250

Quote from: etotheipi on July 07, 2012, 10:08:36 PM

Quote from: kuzetsa on July 07, 2012, 09:42:33 PM

... migration from official latest (stable) satoshi client...

Oh, I need to add a warning about this. Private keys from Bitcoin-Qt version 0.6.0 and newer cannot be imported into Armory!. It's because they use "compressed public keys" which Armory doesn't support yet. I suspect that the key you tried to import was one of these compressed keys...

Yes. I think so --- Latest Bitcoin-Qt version: 0.6.3... which also includes the CLI version, bitcoind

... the command I used to grab my private key was one I issued via bitcoind.

suspect that bitcoind, apparently, uses the same format as bitcoin-qt and I guess that's just as incompatible.

I'd really like the option to be able to migrate to armory, at least to test a few things. Do you have any estimate for how long it would take to add support for the CURRENT private key format (0.6.x and newer) used in the official client?

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: kuzetsa on July 07, 2012, 09:42:33 PM

Quote from: etotheipi on July 04, 2012, 11:35:39 PM

Armory 0.82-alpha Testing Release!

No joke: Tons of new features and polishing! After having spent so much time on the new blockchain engine...

This is my first attempt at using armory. migration from official latest (stable) satoshi client is not going so well for me, sadly:

Code:

>>> bitcoind help dumpprivkey
dumpprivkey 
Reveals the private key corresponding to .

Oh, I need to add a warning about this. Private keys from Bitcoin-Qt version 0.6.0 and newer cannot be imported into Armory!. It's because they use "compressed public keys" which Armory doesn't support yet. I suspect that the key you tried to import was one of these compressed keys.

There is a warning about that when you try to migrate your entire Bitcoin-Qt wallet, and I need to add one here. I forgot that some users manually pull private keys out of their Bitcoin-Qt wallet...

For now you'll just have to wait for compressed public key support (might be a couple months), or just create a new address in Armory and send some funds to it. I recommend that anyway, because sharing private keys between apps can cause all sorts of weird problems...

Sorry for the inconvenience!

kuzetsa

sr. member

Activity: 369

Merit: 250

Quote from: etotheipi on July 04, 2012, 11:35:39 PM

Armory 0.82-alpha Testing Release!

No joke: Tons of new features and polishing! After having spent so much time on the new blockchain engine...

This is my first attempt at using armory. migration from official latest (stable) satoshi client is not going so well for me, sadly:

Code:

>>> bitcoind help dumpprivkey
dumpprivkey 
Reveals the private key corresponding to .

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Gladamas on July 07, 2012, 12:10:48 AM

Ah, I forgot to mention, every time I start an Armory instance that crashes later, it won't receive (show or give any indication of) a new transaction coming to one of its Bitcoin addresses. The transactions are in the blockchain but won't show up. I forgot if it ahows the correct block number or not, though. Perhaps the crash occurs when Armory receives a second transaction (after the first that it didn't show?) Just a WAG.

Do you mean, "when Armory is getting ready to crash, it no longer shows any new transactions until you restart?" Someone else was able to get some debugging output for me that is useful. It sounds like the crashes may be related (his crash definitely would cause the same behavior). Please post more info if you get any more. I need to crash my own Armory instance!

Gladamas

sr. member

Activity: 294

Merit: 250

Bitcoin today is what the internet was in 1998.

Quote from: etotheipi on July 07, 2012, 12:00:58 AM

Quote from: etotheipi on July 06, 2012, 12:11:39 PM

Quote from: Gladamas on July 06, 2012, 11:45:31 AM

Hey etotheipi, thanks for your work on Armory. Grin

I love the new features.

Every so often Armory crashes after running for a couple of hours. I'm not sure if this is my computer's fault, or a bug in the software. I am mining for BTC (on the GPU) and LTC (on the CPU) on the same computer.

...

While I work on updating 20k lines of python code with proper logging calls, I'll load up Armory in my Windows VM and leave it running to see if I can replicate the behavior in the debugger.

So I loaded Armory in my Win7-64bit VM with 2GB of RAM in online mode. I executed one transaction, then went to my development desktop and forgot about it. 7 hours later, no crash. Anyone who is experiencing this crash have any hints about what I can do to trigger it? Are you doing anything before it crashes? This is going to be a tough bug without any way to replicate it!

Ah, I forgot to mention, every time I start an Armory instance that crashes later, it won't receive (show or give any indication of) a new transaction coming to one of its Bitcoin addresses. The transactions are in the blockchain but won't show up. I forgot if it ahows the correct block number or not, though. Perhaps the crash occurs when Armory receives a second transaction (after the first that it didn't show?) Just a WAG.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: etotheipi on July 06, 2012, 12:11:39 PM

Quote from: Gladamas on July 06, 2012, 11:45:31 AM

Hey etotheipi, thanks for your work on Armory. Grin

I love the new features.

Every so often Armory crashes after running for a couple of hours. I'm not sure if this is my computer's fault, or a bug in the software. I am mining for BTC (on the GPU) and LTC (on the CPU) on the same computer.

...

While I work on updating 20k lines of python code with proper logging calls, I'll load up Armory in my Windows VM and leave it running to see if I can replicate the behavior in the debugger.

So I loaded Armory in my Win7-64bit VM with 2GB of RAM in online mode. I executed one transaction, then went to my development desktop and forgot about it. 7 hours later, no crash. Anyone who is experiencing this crash have any hints about what I can do to trigger it? Are you doing anything before it crashes? This is going to be a tough bug without any way to replicate it!

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Gladamas on July 06, 2012, 11:45:31 AM

Hey etotheipi, thanks for your work on Armory. Grin

I love the new features.

Every so often Armory crashes after running for a couple of hours. I'm not sure if this is my computer's fault, or a bug in the software. I am mining for BTC (on the GPU) and LTC (on the CPU) on the same computer.

This is the not the first report of this behavior, so this must be a real bug in the software. But it must be a Windows thing, because I've had 0.81 open in Linux for days without issue.

Unfortunately, these types of crash reports are really not very useful. I really need the console output from Armory to be able to figure out what happened (which is not available without running Armory from the console). As such, I'm currently implementing a proper logging system, to go into ... 0.82? Probably 0.82.1. Then when Armory crashes, there will be an armorylog.txt file that you can send me. I've been procrastinating on this for months, but now I think it's finally time to do it.

While I work on updating 20k lines of python code with proper logging calls, I'll load up Armory in my Windows VM and leave it running to see if I can replicate the behavior in the debugger.

Hey, at least it works for a couple hours before crashing! It's obviously not convenient, but it sounds like you still have access to all the features...

Glad to see folks like the new features

Gladamas

sr. member

Activity: 294

Merit: 250

Bitcoin today is what the internet was in 1998.

Hey etotheipi, thanks for your work on Armory. Grin

I love the new features.

Every so often Armory crashes after running for a couple of hours. I'm not sure if this is my computer's fault, or a bug in the software. I am mining for BTC (on the GPU) and LTC (on the CPU) on the same computer.

Event log comes up with this:

Code:

Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x4918017b
Faulting module name: _CppBlockUtils.pyd, version: 0.0.0.0, time stamp: 0x4ff50abe
Exception code: 0xc0000005
Fault offset: 0x00000000000a39ef
Faulting process id: 0x1164
Faulting application start time: 0x01cd5a6d0d14fe31
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
Report Id: 75200608-c77e-11e1-a8ef-93d7bbd34ded

The Windows Error Reporting application event (I'm using Windows 7):

Code:

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: Armory.exe
P2: 0.0.0.0
P3: 4918017b
P4: _CppBlockUtils.pyd
P5: 0.0.0.0
P6: 4ff50abe
P7: c0000005
P8: 00000000000a39ef
P9: 
P10: 

Attached files:

These files may be available here:
C:\Users\MyUserName\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Armory.exe_17736f5f7992b413af3ee23807d87bc0ecdeb4_0ad37763

Analysis symbol: 
Rechecking for solution: 0
Report Id: 75200608-c77e-11e1-a8ef-93d7bbd34ded
Report Status: 0

And that log file (AppCrash_Armory.exe_17736f5f7992b413af3ee23807d87bc0ecdeb4_0ad37763\Report.wer):

Code:

Version=1
EventType=APPCRASH
EventTime=129860617767953251
ReportType=2
Consent=1
ReportIdentifier=75200609-c77e-11e1-a8ef-93d7bbd34ded
IntegratorReportIdentifier=75200608-c77e-11e1-a8ef-93d7bbd34ded
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=Armory.exe
Sig[1].Name=Application Version
Sig[1].Value=0.0.0.0
Sig[2].Name=Application Timestamp
Sig[2].Value=4918017b
Sig[3].Name=Fault Module Name
Sig[3].Value=_CppBlockUtils.pyd
Sig[4].Name=Fault Module Version
Sig[4].Value=0.0.0.0
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=4ff50abe
Sig[6].Name=Exception Code
Sig[6].Value=c0000005
Sig[7].Name=Exception Offset
Sig[7].Value=00000000000a39ef
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.1.7601.2.1.0.256.1
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=fd77
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=fd7767716b21017df8015d0bbdcae485
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=afa7
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=afa78d5f00a4b18cae89752474a7c6b7
UI[2]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
UI[3]=Armory.exe has stopped working
UI[4]=Windows can check online for a solution to the problem.
UI[5]=Check online for a solution and close the program
UI[6]=Check online for a solution later and close the program
UI[7]=Close the program
LoadedModule[0]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\Windows\system32\kernel32.dll
LoadedModule[3]=C:\Windows\system32\KERNELBASE.dll
LoadedModule[4]=C:\Windows\system32\USER32.dll
LoadedModule[5]=C:\Windows\system32\GDI32.dll
LoadedModule[6]=C:\Windows\system32\LPK.dll
LoadedModule[7]=C:\Windows\system32\USP10.dll
LoadedModule[8]=C:\Windows\system32\msvcrt.dll
LoadedModule[9]=C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\MSVCR90.dll
LoadedModule[10]=C:\Windows\system32\IMM32.DLL
LoadedModule[11]=C:\Windows\system32\MSCTF.dll
LoadedModule[12]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\PYTHON27.DLL
LoadedModule[13]=C:\Windows\system32\ADVAPI32.dll
LoadedModule[14]=C:\Windows\SYSTEM32\sechost.dll
LoadedModule[15]=C:\Windows\system32\RPCRT4.dll
LoadedModule[16]=C:\Windows\system32\SHELL32.dll
LoadedModule[17]=C:\Windows\system32\SHLWAPI.dll
LoadedModule[18]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\_hashlib.pyd
LoadedModule[19]=C:\Windows\system32\CRYPTSP.dll
LoadedModule[20]=C:\Windows\system32\rsaenh.dll
LoadedModule[21]=C:\Windows\system32\CRYPTBASE.dll
LoadedModule[22]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\PyQt4.QtCore.pyd
LoadedModule[23]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\QtCore4.dll
LoadedModule[24]=C:\Windows\system32\ole32.dll
LoadedModule[25]=C:\Windows\system32\WS2_32.dll
LoadedModule[26]=C:\Windows\system32\NSI.dll
LoadedModule[27]=C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\MSVCP90.dll
LoadedModule[28]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\sip.pyd
LoadedModule[29]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\PyQt4.QtGui.pyd
LoadedModule[30]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\QtGui4.dll
LoadedModule[31]=C:\Windows\system32\COMDLG32.dll
LoadedModule[32]=C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_a4d6a923711520a9\COMCTL32.dll
LoadedModule[33]=C:\Windows\system32\WINMM.dll
LoadedModule[34]=C:\Windows\system32\WINSPOOL.DRV
LoadedModule[35]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\_socket.pyd
LoadedModule[36]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\_ssl.pyd
LoadedModule[37]=C:\Windows\system32\NLAapi.dll
LoadedModule[38]=C:\Windows\system32\napinsp.dll
LoadedModule[39]=C:\Windows\system32\pnrpnsp.dll
LoadedModule[40]=C:\Windows\System32\mswsock.dll
LoadedModule[41]=C:\Windows\system32\DNSAPI.dll
LoadedModule[42]=C:\Windows\System32\winrnr.dll
LoadedModule[43]=C:\Program Files\Bonjour\mdnsNSP.dll
LoadedModule[44]=C:\Windows\system32\Iphlpapi.DLL
LoadedModule[45]=C:\Windows\system32\WINNSI.DLL
LoadedModule[46]=C:\Program Files\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL
LoadedModule[47]=C:\Windows\system32\PSAPI.DLL
LoadedModule[48]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\win32api.pyd
LoadedModule[49]=C:\Windows\system32\VERSION.dll
LoadedModule[50]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\POWRPROF.dll
LoadedModule[51]=C:\Windows\system32\SETUPAPI.dll
LoadedModule[52]=C:\Windows\system32\CFGMGR32.dll
LoadedModule[53]=C:\Windows\system32\OLEAUT32.dll
LoadedModule[54]=C:\Windows\system32\DEVOBJ.dll
LoadedModule[55]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\pywintypes27.dll
LoadedModule[56]=C:\Windows\system32\secur32.dll
LoadedModule[57]=C:\Windows\system32\SSPICLI.DLL
LoadedModule[58]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
LoadedModule[59]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\twisted.python._initgroups.pyd
LoadedModule[60]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\_bsddb.pyd
LoadedModule[61]=C:\Windows\system32\uxtheme.dll
LoadedModule[62]=C:\Windows\system32\dwmapi.dll
LoadedModule[63]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\_ctypes.pyd
LoadedModule[64]=C:\Program Files (x86)\Armory\Armory Bitcoin Client\win32process.pyd
LoadedModule[65]=C:\Windows\System32\wshtcpip.dll
LoadedModule[66]=C:\Windows\system32\CLBCatQ.DLL
LoadedModule[67]=C:\Windows\System32\wship6.dll
LoadedModule[68]=C:\Windows\system32\rasadhlp.dll
LoadedModule[69]=C:\Windows\System32\fwpuclnt.dll
LoadedModule[70]=C:\Windows\system32\spool\DRIVERS\x64\3\UNIDRV.DLL
LoadedModule[71]=C:\Windows\system32\spool\DRIVERS\x64\3\UNIDRVUI.DLL
LoadedModule[72]=C:\Windows\system32\spool\DRIVERS\x64\3\hpzuiw72.dll
LoadedModule[73]=C:\Windows\system32\ATL.DLL
LoadedModule[74]=C:\Windows\system32\MSIMG32.dll
LoadedModule[75]=C:\Windows\system32\spool\DRIVERS\x64\3\hpz3rw72.dll
LoadedModule[76]=C:\Windows\system32\mscms.dll
LoadedModule[77]=C:\Windows\system32\USERENV.dll
LoadedModule[78]=C:\Windows\system32\profapi.dll
LoadedModule[79]=C:\Windows\system32\spool\DRIVERS\x64\3\hpfiew71.dll
LoadedModule[80]=C:\Windows\system32\RpcRtRemote.dll
FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=Armory.exe
AppPath=C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: Btc4Domains on July 06, 2012, 12:41:38 AM

Hey Alan, got a feature request from some up and coming new generation users Wink

Asked the kids the other day if they wanted to move their fiat savings and put it into bitcoin - they instantly lit up and all said YES! Ok I said, I'll create you each a wallet.. Very first question to come back at me was.. 'Can I have a pink one?'

LOL!

Btc4Domains

vip

Activity: 99

Merit: 15

Hey Alan, got a feature request from some up and coming new generation users Wink

Asked the kids the other day if they wanted to move their fiat savings and put it into bitcoin - they instantly lit up and all said YES! Ok I said, I'll create you each a wallet.. Very first question to come back at me was.. 'Can I have a pink one?'

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Stephen Gornick on July 05, 2012, 02:26:57 AM

I hadn't looked at the URI produced. I just noticed the "forward compatability" section:
- http://en.bitcoin.it/wiki/BIP_0021#Forward_compatibility

Specifically:
"Variables which are prefixed with a req- are considered required.".

So I suppose the URI could be fully compliant without doing anything special.
"Some future version that has variables which are (currently) not understood but not required and thus valid:"

You're getting ahead of yourself. You're looking at the forward compatibility section that helps URI handlers recognize that they are outdated. The issue here is about what programs handle basic URIs and how do they handle them.

It's funny that the Bitcoin-Qt devs were part of the BIP 21 process, and apparently even implemented BIP 21 in Bitcoin-Qt, but disabled registering it with the OS for reasons I don't remember. As such, it's only supported by these alternative clients, but it is compatible between them because of BIP 21. And when Bitcoin-Qt enables it, it should then be a universal functionality.

However, I took into account that even when it is widely supported, it won't be 100%. That's why I added the line: "Use the following payment information if the link does not work on your system", and included the info as plaintext, so that it would accommodate all users. Even if their program supports links, they probably would like to glance at the payment info before switching to their Bitcoin app.

I had ideas to expand BIP 21 to support message signing, too, and that could be a separate BIP (so someone can say, "This merchandise was purchased using funds from address 1xYzQ3, please send your shipping address signed by that address"). But that's another topic altogether...

@ Molecular:

The change-address-behavior was inspired mostly by you (but there have been other requests made). The idea was that you can select to have change sent back to one of the input addresses, and then it will save that setting for future transactions so that you don't have to think about it after the first time. This means that if your wallet is made up of imported addresses, no new addresses will be created for change -- it will be recycled back into the imported addresses. I think that should solve the use case 100%. Please let me know if something is missing or not right about it...

Topic: Armory - Discussion Thread - page 183. (Read 521829 times)