 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
then send those coins to a watching only Armory wallet, then send those to an offline armory wallet?
Is that right?
That should be one step. Send it to the offline wallet, which will show up in the watching only version of the same wallet. |
|
|
|
It looks like it's unable to start ArmoryDB. Can you try running So that worked, it started building the DB. I then ran Armory and it's now scanning transactions. I'll follow up on whether the problems persist after it fully syncs. Weird. Edit: So it's still having problems starting ArmoryDB automatically. In the log it has this line: Executing popen: ['/usr/lib/armory/ArmoryDB', '--db-type="DB_FULL"', '--spawnId="snip"', '--satoshi-datadir="/home/user/.bitcoin/blocks"', '--dbdir="/home/user/.armory/databases"'] but when i do a whereis, it comes back with ArmoryDB: /usr/bin/ArmoryDB /usr/bin/X11/ArmoryDB |
|
|
|
2016-09-15 21:40 (ERROR) -- Traceback (most recent call last):
File "/usr/bin/../lib/armory/ArmoryQt.py", line 6635, in method_signal
method()
File "/usr/bin/../lib/armory/ArmoryQt.py", line 6672, in completeBlockchainProcessingInitialization
gotDB = self.startArmoryDBIfNecessary()
File "/usr/bin/../lib/armory/ArmoryQt.py", line 2198, in startArmoryDBIfNecessary
spawnId = TheSDM.spawnDB(TheBDM.armoryDBDir)
File "/usr/lib/armory/SDM.py", line 513, in spawnDB
launchProcess(pargs, **kargs)
File "/usr/lib/armory/armoryengine/ArmoryUtils.py", line 642, in launchProcess
return Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE, *args, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
2016-09-15 21:40 (INFO) -- ArmoryQt.py:5641 - Dashboard switched to "Scanning" mode Armory seems to hang on preparing the database. I'm not sure what it thinks is missing. All the files seem to be there. It looked like some of the files were missing when I was checking manually, but I've uninstalled/reinstalled using the deb files, reset the db and settings several times and everything seems to be there. Any ideas? |
|
|
|
The one I want to use is missing 4) Hide Used I would like to see empty but unused addresses but hide the empty used addresses. and make that dealt.
I've actually been wanting this feature too. I would find it immensely useful and it fits with not reusing addresses paradigm. Thirded, I was looking for just this feature just yesterday and was somewhat surprised it wasn't there for the reason mentioned above. |
|
|
|
By the way, you might have to use "Help"->"Rebuild and Rescan Databases". Some of the database behavior changed ever so slightly since 0.89.99.3. It may not be necessary, but I wouldn't be surprised if it cleared up any weird/buggy behavior in the app.
I did have a built database in my app data I was keeping around for when Armory was fixed. It looks like it decided to rebuild it automatically. The reason I know this aside from the progress bar starting at 0% is because my virtual disk was starting to get full and when I was checking to see if I was running out of space and a lot of space was suddenly available. Here are some stats in case you are interested. First run took 33 mins to sync to the network from 98% and the database took over an hour to rebuild the database (I wasn't able to finish timing it accurately). The second run took a little over 2 minutes to sync the 1 incoming block and scan the DB. I have 4 AMD cores at 4GHz allocated to the VM. I didn't see the memory usage go over 300 MB while I was watching it. I feel as though the Bitcoin sync was primarily network bound, but the database build & scan seemed like it might have been IO bound and benefited from residing in memory a bit more. At least the 4 cores were never running full tilt perhaps varying between 35%-65% across all 4. Then again, I'm not sure I trust task manager, it seems threads jumping across cores cause it to average out the utilization on the graphs. Looks like a good build for Win7 users, thanks again! |
|
|
|
Windows users!
Thanks again to goatpig. He made us a custom port of one of the leveldb DB dependencies and it appears it may have fixed the loading issues.
Looks good so far, it was great to see the splash screen come up. It's starting at 98% sync with the network now, I'll update my post if I run into any problems or have any additional comments. Thanks goatpig and Alan! |
|
|
|
I tried the updated package. The file you added is there, but still no dice. Thanks for the effort Alan. (CRITICAL) armoryengine.pyc:1041 - C++ block utilities not available.
(CRITICAL) armoryengine.pyc:1042 - Make sure that you have the SWIG-compiled modules
(CRITICAL) armoryengine.pyc:1043 - in the current directory (or added to the PATH)
(CRITICAL) armoryengine.pyc:1044 - Specifically, you need:
(CRITICAL) armoryengine.pyc:1045 - CppBlockUtils.py and
(CRITICAL) armoryengine.pyc:1049 - _CppBlockUtils.pyd
(ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 31, in <module>
File "armoryengine.pyc", line 1037, in <module>
File "CppBlockUtils.pyc", line 26, in <module>
File "CppBlockUtils.pyc", line 18, in swig_import_helper
File "_CppBlockUtils.pyc", line 12, in <module>
File "_CppBlockUtils.pyc", line 10, in __load
ImportError: DLL load failed: The specified module could not be found.
Error in sys.excepthook:
Traceback (most recent call last):
File "armoryengine.pyc", line 617, in logexcept_override
AttributeError: 'NoneType' object has no attribute '__excepthook__'
Original exception was:
Traceback (most recent call last):
File "ArmoryQt.py", line 31, in <module>
File "armoryengine.pyc", line 1037, in <module>
File "CppBlockUtils.pyc", line 26, in <module>
File "CppBlockUtils.pyc", line 18, in swig_import_helper
File "_CppBlockUtils.pyc", line 12, in <module>
File "_CppBlockUtils.pyc", line 10, in __load
ImportError: DLL load failed: The specified module could not be found.
FYI, there is a log file in the package which threw me for a bit of loop since it had some error lines that I thought were new. |
|
|
|
Windows Builds:
Try the MSVS 2012 redist, that's the only one I can think off that may be missing. This is the same issues as the WinXP builds I've distributed recently and I have to investigate the error on a clean install to find it out.
I installed the MSVS 2012 redist, which added "Microsoft Visual C++ 2012 Redistributable (x86) - 11.0.60610" as an entry to Programs and Features. Unfortunately, I still get the same error. Thanks for the suggestion goatpig. Is there also a .NET Framework that should be installed along side it? |
|
|
|
I just dumped a "standalone" version into dropbox. It should be exactly the same as the installed version, but it hasn't gone through the NSIS installer-builder process. I want to see if that makes a difference.
It was a nice thought, but the standalone version has the same error. One slightly odd thing about the standalone is it logs in both the User\App Data folder and the Standalone folder, but I think that may be normal. The Standalone log had a slightly more detailed stack.(CRITICAL) armoryengine.pyc:1041 - C++ block utilities not available.
(CRITICAL) armoryengine.pyc:1042 - Make sure that you have the SWIG-compiled modules
(CRITICAL) armoryengine.pyc:1043 - in the current directory (or added to the PATH)
(CRITICAL) armoryengine.pyc:1044 - Specifically, you need:
(CRITICAL) armoryengine.pyc:1045 - CppBlockUtils.py and
(CRITICAL) armoryengine.pyc:1049 - _CppBlockUtils.pyd
(ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 31, in <module>
File "armoryengine.pyc", line 1037, in <module>
File "CppBlockUtils.pyc", line 26, in <module>
File "CppBlockUtils.pyc", line 18, in swig_import_helper
File "_CppBlockUtils.pyc", line 12, in <module>
File "_CppBlockUtils.pyc", line 10, in __load
ImportError: DLL load failed: The specified module could not be found.
Error in sys.excepthook:
Traceback (most recent call last):
File "armoryengine.pyc", line 617, in logexcept_override
AttributeError: 'NoneType' object has no attribute '__excepthook__'
Original exception was:
Traceback (most recent call last):
File "ArmoryQt.py", line 31, in <module>
File "armoryengine.pyc", line 1037, in <module>
File "CppBlockUtils.pyc", line 26, in <module>
File "CppBlockUtils.pyc", line 18, in swig_import_helper
File "_CppBlockUtils.pyc", line 12, in <module>
File "_CppBlockUtils.pyc", line 10, in __load
ImportError: DLL load failed: The specified module could not be found.
[EDIT] Removing the redistributable and .NET Framework 4 Client Profile didn't have any impact. Is there any particular versions that should be installed? From what I understand about VS, it's normal to have multiple distributable versions installed and the app should select the appropriate one automatically. I don't know much about VS, so I could be totally wrong. |
|
|
|
|
I'm seeing the same error as "els", for Win7 Ultimate x64, also a VM with all Windows updates.
I have the following MS VS related entries listed in Programs and Features
Microsoft .NET Framework 4 Client Profile
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161
|
|
|
|
trying out the ArmorySetup-0.89.99.8-beta_win32 install on a virgin install of Win 7 Home Premium 64-bit (SP1 + all updates).
it installs fine, but when run it fails with logfile errors. anybody know if the _win32 means it won't work with 64-bit, or perhaps if i am missing some prerequisite installs? (i had an earlier testing version working on another instance of win7, where i get the same errors with this version).
The win32 means that it is built as a 32-bit application, but 64-bit windows can still run 32-bit applications. So far, I think most people have been testing the 32-bit app on 64-bit (and I've been using it on my 64-bit Win7 VM). If there's a problem, perhaps it has to do with installing different versions and jumping around. I would recommend removing it via control panel, and then remove all C:\Program Files\Armory and C:\Program Files (x86)\Armory. Then reinstall. There may still be a problem with the installer not deleting/overwriting everything. this is the same problem i reported to you by email a few weeks ago. i haven't been able to get it working since. i've tried uninstalling and removing the obvious files like the folder in Program Files and AppData\Roaming Data, but no dice. unfortunately I don't have any VM snapshots without Armory installed. i'm currently using the standalone edition (0.89.99.3) as a workaround since it still works just fine. |
|
|
|
The problem with QR codes is they aren't big enough. They're big enough for 95% of transactions, but the first time you have to move 1 MB across that channel, you'll be SoL. And you don't have control over it. If I know one of the addresses in your offline system, I can send you a couple 100 kB transactions, and effectively DoS your offline solution. QR codes can hold enough data. I've put some thought into this and have a working prototype. QR codes can hold up to 2KBs of data with standard readers. In practice, i expect a casual setup will be able to read 1KB QR codes. As far as data encoding goes, Base91 seems to be optimal for compatibility, so 364 bytes are available in an easily readable QR code. It's not high bandwidth by any means, but more than fine for today's usage. It may even be a feature for people using Armory now. I can see how audio is a good solution coming from people with DSP experience. I just like how QR codes are easy enough for most people to understand. I'm not sure I understand your point about DoS, the online computer will be creating the transaction, just use coin control to select non-DoS'd inputs. The 1 MB block limit will make DoS impractical for most until it's lifted. The blockchain will continue to have anti-DoS measures beyond the 1 MB block limit being lifted, so most users should be fine after that as well. QR code + Webcams:
+ QR codes are easy to generate
+ Plenty of existing software for scanning QR codes
+ Many laptops come with webcam, and can also be purchased inexpensively
- Requires manually moving cameras and screens around to get QR codes into view
- QR codes may not hold enough data: may need to use multiple codes
- Need to design webcam-based UI, with feedback and possible UI for flipping&scanning multiple QR codes
- Webcam support on all platforms is flaky (but it could be up to the user to get their webcam supported) In my prototype I just use screen reading, no need to deal with drivers. I'm sure adding direct web cam capture capabilities you could push the QR codes to 2 KB. It's just that JMF is not a Java library I look forward to working with. Multiple QR codes are not really a problem, in my prototype I allocated space to store information about the payload. Once you setup cameras in good positions it's easy enough to cycle through QR codes. You can easily read a QR code in under a second. It's easy enough to automatically split the data and re-assembles data to/from QR codes. Here are some numbers showing how I handle payloads up 30 KB: 16 base91 bytes in metadata total (1 byte each for block index and count), leaves 1008 bytes for data base 91 vs base 256 efficiency is a little over 35% that gives 358 bytes of data per 1KB QR code up to 91 QR codes can be created for a single payload containing 30 KB of data I'm sure by reworking the protocol a bit I could get it close to the limits of QR code technology and whatever users are willing to put up with. |
|
|
|
|
I've done some work for using QR codes to transfer data between computers specifically since I have moved to Armory. It is a Java based application, so it probably won't work well on a RPi with so little RAM. The source is out there on the interwebs, but I haven't fully thought out what license I'd like to use. If there is an increasing interest in it, I'll work through those issues so people can use it/build on top of it.
That said, I'm not convinced a hardened version of it would stand up to a persistent attacker. At the end of the day you're going to end up using a library or re-inventing the wheel and either one will have it's own set of vulnerabilities to side-channel attacks. I believe it to be safer than USB since there is no bootability issues and it is hopefully less likely to "auto-play". It also gives you a lot more control of how much/when data is transmitted or received and you can verify the payload against a third party device if you are paranoid.
|
|
|
|
Ripple had a seat on the 'alternate crypto-currency roundtable at the 2013 conference. I didn't see anyone holding a gun to their heads. "Ripple" is a system for managing and tracking account balance. It contains "XRP", which is a built in crypto-currency. It's not quite accurate to say that "Ripple is an alt coin" because it is more than that. However, it might be correct to say that "XRP is an alt coin." But calling Ripple an alt-coin is to ignore all of its other functionality, which in my opinion is a mistake. XRP threads go in Alt Currencies. Ripple threads go in Service Discussion. Easy. Now you know where to move your two threads. Thanks. |
|
|
|
|
Do we really need 6 topics about Ripple in the main forum? Namecoin only has one and I have way more respect for it than the ripple guys trolling the trolls. I motion that a mod move all ripple threads be moved to Service Discussion/Alt. Currencies as appropriate.
|
|
|
|
Looks like maven would not build the right path for tests, since it can not load the log config. This could be also the explanation for not picking up the right security provider (bouncy castle). You likely have some unique environment or build of maven. Local hosted repositories or patched?
Or you are running into Windows unable to deal with paths longer than X byte or paths with space in it or similar.
General suggestion:
Install some unix based operating system before trying to build software.
i find your suggestions a bit dissatisfying from a build perspective. You are using platform independent language and a platform independent build stack and yet you are suggesting your actual build may in fact be platform dependent. I understand you have other priorities bringing up the code to a high level of quality, but you should be in the frame of mind where your code and build will be platform independent at some point. PRab swapping out versions of protoc is a perfect example of something Maven is supposed to unequivocally disambiguate. At a casual glance, everything else in the build is looks good, which is why build issue a bit confusing. I did do some research the other day, and I can see you are including protoc in your build as it has been recommended in various forums. My main issue is that the recommendation is incomplete (some posts even acknowledge this), which is why PRab and I are unable to reproduce your build without a non-trivial amount of effort. I feel I can contribute to helping you create a platform independent build or at least a clearer build path, so I will try to help you to that end. I'll need to find some more time to look into this and will contact you if I find I need any more information. |
|
|
|
@PRab If you just want more scroll back you have a few options: -change the command prompt properties in the title bar and increase the "screen buffer height" -pipe it out to a file, i don't know what mvn goals you are using so these are just examples "mvn clean package -l mvn.log" or "mvn clean package > mvn.log", unfortunately you can only redirect output and won't see the output in the CLI -use a proper IDE like Eclipse or IntelliJ CE which should give you as much scroll back as you need and code URLs I haven't tried figuring out what version of protoc he's using either, which is where I'll have to turn my attention to grau @grau I have some experience as a build manager and going to say "bad grau, bad", repeat after me "i must not include implicit external dependencies in maven builds". In maven you must be explicit in your pom files in such situations. That is the price you pay when including such dependencies, whether you use maven or something else. If you can't include it due to licensing or any other reason, use a stub pom that declares what version you are using and a link to any licensing terms and/or where to get it. It's painful, but less painful than another developer trying to read your mind. Here's the default log level error I get: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (compile-protoc) on project bitsofproof-server-api: An Ant BuildException has occured: Execute failed: java.io.IOException: Cannot run program "protoc": CreateProcess error=2, The system cannot find the file specified -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException Also, seeing an ant-run makes me a sad panda, but it's adequate if it's not causing an build problems. |
|
|
|
Except it isn't just me, there are hundreds of users (and owners of bitcoin) like me, who signed on to a system that we thought would have LOWER relative costs to verify in the future. That one day every, even the cheapest computer, could become a full-node.
That may well be, but what does that have to do with the network management policy that currently requires blocks be less than 1MB? I silently read the forums daily and only decided to post more recently when some vocal people decided that this network management policy should be set in stone when people started asking "should we increase the limit"? The network management policy is very unlike all the other "fixed" points that make Bitcoin. It only extends Bitcoin's capability while hopefully not exposing Bitcoin to the attacks retep identified. I'm normally happy to stay on the sidelines and watch what solutions people come up with. I like to hear some thought and pause about increasing the limit, I'm a bit disturbed that anyone seriously thinks it should be fixed and that aspect of Bitcoin is perfect just the way it is. The amount of thought that went into that limit was clearly crude and haphazard compared to all the other fixed points. By all means the community needs to explore why it needs to change, what changes need to be made, how the changes will be implemented and when the network will accept the change. I feel that anyone that seriously explores those topics will see there will be a need for a change. Maybe they will conclude that we won't need to see that change in anyone's lifetime, but I would like to see some better evidence on why they think that. Going back to your example for the moment, I don't think the goal is necessarily valid. Assuming it is though, even the cheapest computers today can handle being a full node indefinitely even with a block size increase. The only question is how high can it go if that is the goal. Bitcoin can always choose to make trade-offs between things like fast, cheap, and good. Even if we choose all three, there is still room to increase the limit. I would hope we would trade-off a little bit off the cheap side, and increase network requirements a bit more than others might like, but I can live with modest changes if the reasoning has legs. Regardless, I want the decision to be continuously re-evaluated like every other part of Bitcoin. It is hard to understand how anyone can want Bitcoin to stay in the dark ages forever. Anyone that says it changes the social contract hasn't been paying enough attention to all the other changes that have been happening to the code base that makes the social contract. This change should be less controversial than P2SH or overflow bug. Software is meant to evolve and Bitcoin already has. Open Transactions is fine, but please do not conflate what it does with the block size limit and why it is there. Anyone can use whatever version of Bitcoin they want. I hope you've never upgraded. I'm sure it will continue to work just fine like all the other alt chains, until the 32-bit time stamp issue runs its course. The Bitcoin you are using now will look like a quaint dinosaur in 50 years. The "real" Bitcoin will be whatever everyone agrees to use. |
|
|
|
All you're saying is that to be successful the userbase just needs to grow by an order of magnitude, which is exactly what one would predict if the demand for transactions is exceeding what 1 MB blocks can provide.
He is also saying his fork will continue to exist regardless. That's fine, he can use his inconsequential fork as long as he has another node to connect to (even if it is his own). He can also use Open Transactions he is selling as a solution all he likes too. I suspect most of us will not support a fork that doesn't scale to its potential. Zealotry is not a good reason to keep a crude network management rule that has served its purpose and was meant to be improved. Much of the protocol was meant to be upgraded and replaced as needed. The 1MB limit increase will likely be the second improvement of many. The first as I understand it is block V2, which is still phasing in. Others like the hashing and key algorithms appear to be fine for the foreseeable future and probably all our lifetimes, but they will change eventually if bitcoin doesn't die. The txn limit is actually much lower than 7 tps if bitcoin ever sees significant usage of any of it's coolest features, like smart contracts. |
|
|
|
S.Dice is essentially micro-transactions. Increasing the block size to support micro-transactions is absolutely the wrong idea. Bitcoin cannot be built around micro-transactions.
what you are really saying here is: S.Dice are transactions. Increasing the block size to support transactions is absolutely the wrong idea. Bitcoin cannot be built around transactions. Most people around here are thinking about transactions incorrectly. I'm going to single out Jeff in passing because he is a core-dev that has only gone from one extreme to another. Bitcoin is not built to support micro-transactions and this is evident from the way transactions must propagate and all the economic incentives that support the auditing of transactions. What is not evident is what a "micro" transaction really is in the context of Bitcoin. I think fundamentally a micro transaction in Bitcoin is a transaction or perhaps a tx out that is not worth propagating or auditing. Technically it is very hard to argue S.Dice is a micro transaction otherwise it would be impossible to propagate or audit. Economically it is not so clear cut, but there is a market for auditing S.Dice transactions, so I would say economically it is not a micro transaction. You can say that S.Dice is subsidized by the block reward, but take the reward away and it almost the only incentive to audit other transactions. Thus, S. Dice will not truly be a micro transaction in the context of Bitcoin until it is impossible to transact on the Bitcoin network. When that will happen will be determined entirely on network management. Bitcoin never promises to support micro transactions as I've outlined it nor is it built for that. Bitcoin is a payment network. From a network management point of view S.Dice is a problem because of the spammy messaging, but otherwise the transactions are just as valid as any other on the network. My network management suggestion to S.Dice would be to include the messaging component as part of the bet so the messaging output would be limited to the size of the minimum bet, which should follow whatever the network can support. Integrations with wallets such as blockchain.info could just hide the messaging component of the bet to make it user friendly, done correctly it could even be used to collect any dust it has already created. Perhaps it is also worth considering not using a messaging component for most S.Dice bets as it has already established a reputation and messaging could be implemented as an optional value-added service rather than a default operating mode. |
|
|
|
|
