|
I responded to your ticket. I'm fairly sure Core mobile runs only a lite wallet, so it's to be expected it doesn't support arbitrary utxo lookups.
|
|
|
|
|
Unrelated issue. Submit a log file.
|
|
|
|
|
Sweeping creates a wallet, imports the privates key in them, scans the keys then creates a transaction to send these coins to your wallets. You are not getting to the point where you receive the funds. You will have to submit a log file.
|
|
|
|
|
Do you have a transaction hash?
|
|
|
|
|
0.92.3 should work on x86. The other versions are x64 only.
|
|
|
|
|
1) etotheipi loves Python
2) Decent cross platform support
3) All mission critical and crypto code is in C++ (the backend)
4) C++ is more powerful than Python but also more demanding to code with. Doesn't warrant developing the frontend and GUI with.
As for why Python and not another top layer language for the frontend, refer to 1)
P.S: if it was up to me it would all be in C++ but I'm a hateful sociopath, so don't take my opinion seriously =)
|
|
|
|
With respect for chain of command, it's been quite a few days now.... Mac users everywhere would be very much appreciated if there was at least one last officially compiled binary update to take care of the high/low-S patch
...Please consider elevating the priority of this request...
No. I will not escalate anything because even though I reviewed the code, I do not build on Macs thus I cannot test the code at all. My review was merely to make sure nothing was fishy with the change. I informed etotheipi of my opinion on the content of this PR, but I won't press that matter any further because I do not have experience with OSX builds, so I cannot make an informed decision. If I could say "I tested it, it works and I approve of this change", things would be different, but I can't. Development is a lot simpler when people stick to their specialty. |
|
|
|
This sounds great! Let's do it!
Take it easy, we're not at this point yet. Ideally Armory can continue to exist as a business and put out an open source version at the same time. |
|
|
|
|
yeah someone will deal with your ticket.
|
|
|
|
Start Armory, go to File -> Export Log File. Create a support ticket ( https://support.bitcoinarmory.com) and attach it there with an explanation of what is going on. |
|
|
|
Yes, but we need to clarify the exact method. One-time fee for unlimited and forever access or subscription based.
You can't really sell OSS. Whichever way you look at it this model defeats conventional payment methods. Yes, but only toward a crowdfunding style fund that releases open-source code freely to all once a target is reached...
This is the only sane way of doing this. Ideally I would like it to be community driven too. Users put together a list of features they want, devs give them a time estimate and they agree on target for each feature. Another revenue stream would be plugins. Say an exchange wants to integrate with us to manage coins straight from our GUI. They pay us to develop the plugin, release it to their customers and we get a one time commission per user. All that being said, our real calling is still with enterprise customers and support contracts. Whichever way you look at it, our open source version is really for showcasing and testing/reviewing the code base. Not much revenue to get there. What other, new feature would you love?
- I would pay good money for a full-Armory-compatible hardware wallet ("Trezor + multiple Armory wallets")
- Connect my local Armory to my server where the 2 blockchains are stored and updated
Ente
I played around with Ledger on our BIP32 branch. Trezor is definitely easier to implement. I'm currently working on the litenode interface. What features would be must-have, or no deal?
- Offline signing
- Fragmented backup
- No central [Armory] server has my IP or personal info
- Open source
It makes no sense to keep any non enterprise specific features off the free version. Personally I think we should open source everything. Makes for better publicity than we got actually. We have over a year of enterprise solution development and essentially no one that version even exists, let alone what's in it. |
|
|
|
|
I wouldn't mess with unsupported packages. You should change the code as instructed instead. It's not critical to catch the exact exception since it will return False as a result.
|
|
|
|
It fails to import error from psutil. I'm guessing the version of the package you got is old or maybe that class was deprecated. Replace except psutil.error.NoSuchProcess:
with That ought to fix it. |
|
|
|
Did you install psutil? This is the list of Python packages you need to run Armory: pyqt4-dev-tools python-qt4 python-dev python-twisted python-psutil
|
|
|
|
Yes, these are all completely benign warnings. There is a straight forward explanation for every one of these. The forward declaration one is kinda silly but then again, you'd rather it warns you about that than not. Same with nested struct. SWIG users should know these get ignored, plus that's the point of a nested struct anyways, to be used internally by the class. The typecheck error is a bit more complicated. If you look at the code SWIG outputs, you'll understand what the warning actually means. This is the SWIG wrapper for BtcWallet::BtcWallet(BlockDataViewer*, BinaryData) ( https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/BtcWallet.h#L78) SWIGINTERN PyObject *_wrap_new_BtcWallet__SWIG_0(PyObject *SWIGUNUSEDPARM(self), PyObject *args) {
PyObject *resultobj = 0;
BlockDataViewer *arg1 = (BlockDataViewer *) 0 ;
BinaryData arg2 ;
void *argp1 = 0 ;
int res1 = 0 ;
PyObject * obj0 = 0 ;
PyObject * obj1 = 0 ;
BtcWallet *result = 0 ;
if (!PyArg_ParseTuple(args,(char *)"OO:new_BtcWallet",&obj0,&obj1)) SWIG_fail;
res1 = SWIG_ConvertPtr(obj0, &argp1,SWIGTYPE_p_BlockDataViewer, 0 | 0 );
if (!SWIG_IsOK(res1)) {
SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "new_BtcWallet" "', argument " "1"" of type '" "BlockDataViewer *""'");
}
arg1 = reinterpret_cast< BlockDataViewer * >(argp1);
{
if(!PyString_Check(obj1))
{
PyErr_SetString(PyExc_ValueError, "Expected string argument!");
return NULL;
}
arg2 = BinaryData((uint8_t*)PyString_AsString(obj1), PyString_Size(obj1));
}
{
try
{
{
SWIG_PYTHON_THREAD_BEGIN_ALLOW;
result = (BtcWallet *)new BtcWallet(arg1,arg2);
SWIG_PYTHON_THREAD_END_ALLOW;
}
}
catch (std::exception& e)
{
SWIG_exception(SWIG_RuntimeError, e.what());
}
}
resultobj = SWIG_NewPointerObj(SWIG_as_voidptr(result), SWIGTYPE_p_BtcWallet, SWIG_POINTER_NEW | 0 );
return resultobj;
fail:
return NULL;
}
As you can see, arg1 goes through a typecheck before being casted to BlockDataViewer* res1 = SWIG_ConvertPtr(obj0, &argp1,SWIGTYPE_p_BlockDataViewer, 0 | 0 );
if (!SWIG_IsOK(res1)) {
SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "new_BtcWallet" "', argument " "1"" of type '" "BlockDataViewer *""'");
}
arg1 = reinterpret_cast< BlockDataViewer * >(argp1);
arg2, however, gets no typecheck: arg2 = BinaryData((uint8_t*)PyString_AsString(obj1), PyString_Size(obj1));
You can find the reason for this difference in argument handling in our SWIG instruction file: https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/CppBlockUtils.i#L93/* Convert Python(str) to C++(BinaryData) */
%typemap(in) BinaryData
{
if(!PyString_Check($input))
{
PyErr_SetString(PyExc_ValueError, "Expected string argument!");
return NULL;
}
$1 = BinaryData((uint8_t*)PyString_AsString($input), PyString_Size($input));
}
In the case of BlockDataViewer (and most other classes in our codebase), we let SWIG do the wrapping by default. With BinaryData, we enforce an explicit conversion, from and to Python strings, because this is what we need that object for. |
|
|
|
|
I've reviewed the code. Looks kosher (I'm no OSX specialist). I'll drop a word to etotheipi. I won't merge it in myself, because chain of command.
|
|
|
|
I would think imagine that it can be connected to an spv node since armory's full node functionality is from bitcoin core. If you had an spv node that acted like bitcoin core, I think it should work.
Currently Armory expects access to raw block data as saved by Core, via a folder path. 0.93 expects full history so it can't deal with anything short of the entire blockchain. 0.94 could run off the UTXO set, if there is a node implementation that offers that. You won't have the history, but you will see your balance and be able to spend. I am in the process of migrating the database interface from SWIG to a plain HTTP, so that upcoming change will allow you to connect several lite clients to a single server. Since it's HTTP, we could even have a HTML GUI in the future. |
|
|
|
That's pity. This begs the question:
Can I copy my existing 56 GB data for Bitcoin Core and 49 GB data for Armory from my Mac to Linux and continue using it seamlessly? Downloading the whole thing again just because I moved to Linux would be very painful for me.
You should be able to. |
|
|
|
|
Show Posts
