PS: at /building page at your site there are some blocks with code and there are something wrong with CSS so I decided that there are pictures or js mouse copy/paste disabling code and type most of the codes manually and only at last moment understood that it is selectable and right-mouse-button-clickable  I'm not familiar with gh-pages, Andy Chow contributed that part, I'll try to look into it too. |
|
|
|
@goatpig, maybe the best would be if you set up fresh Win10 machine in VM, install VS 2022 and from that moment record a video of all steps building ArmoryQT? It will be much more speaking and less time consuming for all. You can even record video without any sounds, just what you're doing, whats happening and a final positive result. When I will have opportunity then I can write text instructions based on your record and give it to you to place to your site. PS: at /building page at your site there are some blocks with code and there are something wrong with CSS so I decided that there are pictures or js mouse copy/paste disabling code and type most of the codes manually and only at last moment understood that it is selectable and right-mouse-button-clickable I'm abroad to be the best man at my brother's wedding, I'm nowhere near my work setup. You'd have to wait until Im back in late March to deliver that. |
|
|
|
Oddly enough it's easier to build on Windows these days cause it doesn't come with a native python install. Ubuntu moved on from py2, which makes life harder. Win 10 22H2 - I have installed MSVS 2022 and unsure it is possible/good for OS to install MVSE 2013U3, don't want to crack fine tuned machine. You should be able to import a msvs 2013 project into 2022, it will offer you to convert it, which you should agree to. Then you need to get it to build, that's the worst part actually. NSIS 3.0+ - nsis-3.08-setup.exe That's to create the installer, not super useful tbh. "Swig is not installed like the other packages" - tried to unpack swigwin-3.0.2.zip and swigwin-4.1.1.zip then renamed swigwin-3.0.2/swigwin-4.1.1 dirs to swigwin, there are swig.exe inside it
swig.exe needs to be available in your PATH, that's all you need to do with that. Ok, digging again. To build v120 I need VS 2013. "Build tools VS 2013 is not enough, because no c++". Look for MSVC community, or VS code. MSVS is a bundle (think Office). You want the C++ IDE only, the rest isn't useful. |
|
|
|
|
Are you trying to build the dev branch or the latest stable release? Win or *nix? Pick one and I'll try to walk you througgh.
|
|
|
|
Correct. I think mobile phones cant replace hardware wallet features.
Phones TPM speak PKCS11. As long as you're willing write in the native language (Kotlin or Objective-C), and the TPM lists EC as a supported feature (they all do RSA but EC is present maybe 50% of the time?), then you can do hardware exponentiation and signing. Vaults on phones are "fairly" well implemented from my experience, the material is correctly enclaved to the binary that created the entry, and with the proper options at creation, it will never reveal the private data. Phones as a primary hardware wallet are useless, but as a secondary signer in a multisig scheme, why not? |
|
|
|
b. Most of them have been involved in the development of BTC almost since it's earliest days and still have rather tidy sums of the BTC they've acquired during that time so they are certainly not hurting for money. Hell, a few years ago Luke Jr. bragged about still having several thousand BTC ...
Let's not circulate the idea that Core devs are swimming in BTC. $5 wrenches and what not, you know. Also, wasn't there an instance where Luke lost all his coins? |
|
|
|
You can use pretty much any cipher. It's not restricted to ECB, CBC, or anything like that.
Hello It's not about restriction its about security & purpose of use. for example you can use most case aes-cbc-128 its simple and secure. but still there are case people use aes-ctr & aes-gcm Almost all AES(other then ECB mode) provide good security. There are also WhiteBox-AES CTR/CBC provide more security then standard. Block mode and cypher aren't the same thing. In search of someone who implemented AES encryption with the Rijndael -Algorithm. ("NIST" compliant)
Please write to me, thank you very much!
Is there a reason you want someone who can implement this vs using an existing library? |
|
|
|
|
There is a pretty straight forward solution to this, albeit a somewhat brutish one:
The Ordinal protocol sets out to identify single satoshis. It therefor generates outputs that are provably self-unspendable: their value isn't enough to cover for the fee to spend them. To redeem a 1 satoshi output, you would have to create a 0 fee tx, or bring in coins from another output.
If a majority of nodes reject these transactions, this whole ordinal idiocy goes tits up overnight. This can be done without any changes to consensus rules: set your node to a reasonably s/B fee rate. This would limit the propagation of these transactions in the mempool.
A stronger iteration of this approach would be a UASF where nodes would reject transactions that create such outputs. If 2/3rd of the nodes were to enforce such rule, this would force miners to upgrade their nodes as well, as they would rather stay on the main chain than mine ape jpegs. Then the damage can be undone by evicting these outputs from the mempool with a subsequent update.
In general, I'm not too worried. Ethereum has demonstrated that NFTs will move to the next chain down the road when fees get too high for data usage. In general the whole concept of NFTs on chain is dumb, as you need a centralized party to enforce consumption rules. I don't see this fad developing on chains with scarce block size as a consequence.
|
|
|
|
Does it matter that I installed bitcoin core first, downloaded the blockchain and then synced up? It's better to do it in that order. After that, I installed armory 0.96.5, but needed to change the path for armory to the d: drive after the initial install. I checked the status of the box "prune block storage" in bitcoin core, but that wasn't until after the initial installation. That's unfortunate, likely you have a pruned copy of the chain, that cannot be used as is by Armory, you would need to resync your node with the pruning off. How do I proceed? What checks do I run, which logs do you want posted in pastebin? Make sure you have a full chain with Core then start ArmoryQt. If you get pathing issues, try with ArmoryDB on its own. The useful log files are armorylog.txt and armorydb.txt. You can find them in your armory data dir (defaults to C:\Users\*yourusername*\AppData\Roaming\Armory). "target" is d:\armory\armoryqt.exe and "start in" is set to d:\armory. This won't do much for you. You installed armory in D:\ but that's at most 100MB of data. The database which takes several gigs will go to the default folder mentioned before. What you are trying to do is to get Armory (and Core) to save their data in the D:\ drive. This link will help you through that: https://btcarmory.com/docs/pathing |
|
|
|
Also, Armory won't prepare databases unless you allow bitcoin-qt.exe, ArmoryQt.exe, and ArmoryDB.exe access through any firewall setup you may have (including Windows).
None of these processes need to open a listen socket that allows connections from the WAN, I don't think relaxing firewall settings will do much here (unless you're running some intense SELinux variant). Certainly not an issue on stock Windows. |
|
|
|
interesting choice. I'm frankly suspicious of the way that all these javascript dialects are proliferating and eating everything like an army of king kong/godzilla/ghostbusters marshmallow men, but on the other hand, QT is going weird, gtk already went weird, and they're the only game(s) in town. I confess to knowing less than zero about javascript-ey thingys and widgets, but like every self-respecting opinionated asshole, I can tell you that I don't like it and that therefore it is bad.  . The 3 issues i see with Qt: - Qt5 will be EOL in 2025 - There are complaints about Qt6 licensing shenanigans - There aren't that many people who are experienced with pyqt. Qt is typically used with C++. This limits my opportunities: It's hard to find a pro to deliver on the kind of GUI elements I'd rather not deal with. Also, the qt GUI in Armory is straight up hardcoded into the python code files. This isn't very future proof. Cleaning that up would involve big rewrites, which is why changing graphical libs is on the table. For now I'm trying to hang by with what I got, but I'm warming up to the idea. |
|
|
|
excellent news. not the day job/stuck with pyQt part I'm legit considering paying someone to redo the GUI in flutter/dart. |
|
|
|
I believe that's in the works (@goatpig ?) in Armory 0.97.
It works in 0.97. I need to add taproot support and update the lib to support v1 segwit addresses. I'm stuck with day job and UI elements atm =(. |
|
|
|
Does Armory wallet support any type of SegWit?
One of my clients did a transaction and saw a BlockStream message indicating he could save 40%+ using Segwit-Bech32 or 30%+ using SegWit-P2SH. If there's a way to leverage SegWit with 0.96.5 then I'd like to direct him to do so.
0.96.5 can: - generate and pay to P2SH-P2WPKH addresses (nested segwit). - pay to bech32 addresses (native segwit). Your client cannot choose what address type he pays to. The recipient generates the address, and therefor the recipient has control over the type, not the payer. It is the payer who covers the network fees however. If your client has to pay people and wants to cut on network fees, he has to ask the recipients to provide a bech32 or a P2SH-P2WPKH address instead of a legacy P2PKH. If you client is receiving payments, he can use Armory to generate P2SH-P2WPKH addresses to reduce the fees his counterparties have to pay. |
|
|
|
This is what happens in code ( https://github.com/goatpig/BitcoinArmory/blob/master/qtdialogs.py#L4154): LOGINFO('***Completely deleting wallet')
os.remove(thepath)
os.remove(thepathBackup)
self.main.removeWalletFromApplication(wltID)
self.main.statusBar().showMessage( \
self.tr('Wallet %1 was deleted!').arg(wltID), 10000)
It asks the operating system to delete the file on disk (and its backup). This is a soft deletion. From the perspective of the OS, it will mark the relevant sectors as unused on disk and the data will remain there until the sectors are reused. With SSDs, since they spread data across cells to increase IO speeds, they also have a built in garbage collector that actively reclaims unused sectors, meaning the likelyhood someone will be able to recover the files months from now if the SSD sees usage is very small (even if it's far from maxing its storage capacity). For a HDD, it's the opposite. You could likely recover the files years in the future if you didn't actively try to wipe the data. The newer code makes a point of writing jibberish in the sectors before deleting the file in an attempt to make the data irretrievable. There is no guarantee this works across all OS and hardware. If you want a guarantee your data is wiped, you can use dedicated software to that avail. |
|
|
|
But the addresses are not unused, they were used.
Armory detects address usage in 2 ways: - If it has been explicitly requested by the user - If the has history. To detect history, Armory needs access to the blockchain, which I suspect you didn't setup. With that in mind, you should simply grab the set of private keys from all addresses in the wallet, used and unused. This will cover your case and avoid you setup woes. |
|
|
|
|
You do not need for the addresses to show to extract the private keys, likely the GUI is set to hide unused addresses.
|
|
|
|
|
Ah sorry, didn't realize this was related to an old thread.
|
|
|
|
|
There is something listening on the ArmoryDB port. Look for processes listening on localhost:9001 or localhost:9050. Kill them and try again.
|
|
|
|
|
Show Posts
