assuming your priorities are aligned with mine  Try to take over the world? I think there's a quick fix to turn on LevelDB internal atomic ports |
|
|
|
|
Give me a couple days and I'll investigate to code in a WinXP environment. Just don't pull the plug yet!
Last but not least, I can port the atomic types and operations to WinAPI calls. That would let you compile in MSVS 2008/10 and would entirely go around the whole issue. This is the only part of the code that isn't backwards compatible with earlier compilers.
|
|
|
|
Unfortunately, I think the issue is that there are system DLLs being passed along with Armory that are not compatible with Windows XP, even though all the Armory code itself was compiled with the XP toolset. Unless goatpig has a recommendation for this, I'm not sure I see a way around it. I would have to compile directly on Windows XP, but you can't even get MSVS 2012 installed on XP.
Ugh.
I don't have anything on this. I have compiled simple code and successfully had it work on WinXP with this toolset before. I can't give you more info without looking at the behavior myself. I'll set up a WinXP guest at some point and give it a look. |
|
|
|
Stupid question: are you using a manually edited bitcoin.conf?
Goatpig, you hero. It was indeed a faulty conf file. Top detective work and shame on me! I'm actually relieved it was the .conf, I was running out of places to look at o.o |
|
|
|
|
Stupid question: are you using a manually edited bitcoin.conf?
|
|
|
|
Still doesn't work at all or even run on my Windows XP SP3 (32 bit) machine. Same errors.
Okay, I think lack of working on XP is expected. I don't have the right compiler installed for it. Maybe goatpig can repeat (for me, but also everyone who might want to compile it) what is needed to build with Windows XP support. I sounds like it's not hard, I just have to have the right packages installed on my windows machine. I think. On a Win Vista+ machine, download and install Microsoft Visual Studio 2012 express and Microsoft Visual C++ 2010 express. Grab the Armory source from Github, open BitcoinArmory.sln from the cppForSwig folder with MSVS2012. In Build > Configuration Manager, pick Release as the active configuration and Win32 as the active platform. Lastly, right click the BitcoinArmory_SwigDLL project in the Solution Explorer. Pick Properties at the very bottom. In Configuration Properties > General, change the line Platform Toolset from "Visual Studio 2012 (v110)" to "Visual Studio 2012 - Windows XP (v110_xp)" Edit A point I forgot to mention: You need to build every dependency with the winxp toolset, so do this step on every project =P /Edit Apply and close the properties window. Press F7 and let it build away. Note: You'll need Python installed in order to build. If you don't want to change path linking in the MSVS project, you'll have to install Python 2.7 in C:\Python27. Obviously you'll need all the Python related packages to run, afterwards. You'll also need pthread_win32: http://ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-9-1-release.zipExpand this archive in the cppForSwig folder. Don't forget to copy the dll into the same folder as ArmoryQt.py to run. I'll update the projects to support WinXP and pull request so that Alan can't have an excuse anymore =P |
|
|
|
|
If I remember correctly, the FIPS recommended way of building an EC private key was to take at least 1.5 times more entropy than the key bit length and modulo it by F. I would personally recommend that way too, as F (or whatever that parameter was called) is less than 2^256 for secp256k1.
|
|
|
|
Found something in the system log, I highly doubt it's useful though:
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x4918017b
Faulting module name: MSVCR90.dll, version: 9.0.30729.6871, time stamp: 0x4fee5fd5
Exception code: 0xc0000005
Fault offset: 0x000000000001eb58
Faulting process id: 0x236c
Faulting application start time: 0x01ceb32dbc0ff78a
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_08e717a5a83adddf\MSVCR90.dll
Report Id: f9dc5a43-1f20-11e3-bed3-b3f1323ecbdd
Faulting package full name:
Faulting package-relative application ID:
----
Fault bucket 88061050, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: Armory.exe
P2: 0.0.0.0
P3: 4918017b
P4: MSVCR90.dll
P5: 9.0.30729.6871
P6: 4fee5fd5
P7: c0000005
P8: 000000000001eb58
P9:
P10:
Attached files:
C:\Users\Paul\AppData\Local\Temp\WER370.tmp.WERInternalMetadata.xml
These files may be available here:
C:\Users\Paul\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Armory.exe_abdf3f4a8855c97060ca8a5768fca38af215b8f_1e0b09d9
Analysis symbol:
Rechecking for solution: 0
Report Id: f9dc5a43-1f20-11e3-bed3-b3f1323ecbdd
Report Status: 0
Hashed bucket: 344c16a80b0500e5ba6945f87cf7bb6f
Try reinstalling msvc9 64bit redist That or dl and install the free msvc 2010 express (make sure to install 64bit binaries) |
|
|
|
|
Why do you care for A? You can recalculate the public address with the private keys.
|
|
|
|
All requests must also include a special nonce POST parameter with increment integer. (>0)"
Haven't used that API but I suspect what they want you to do is to modify that nonce they sent you in some sort and return it to them (hint: add 1 to it maybe?) |
|
|
|
Anti dust measures added to Qt, maybe? |
|
|
|
OK... i switched to branch "testing" My OS is 64-bit ( Linux xxxxx 3.4.9-gentoo #5 SMP Sun Feb 19 13:41:22 CET 2013 x86_64 Intel(R) Core(TM)2 Duo CPU T9550 @ 2.66GHz GenuineIntel GNU/Linux) Now I see error on compilation: ar -cr libcryptopp.a xtr.o integer.o seed.o wake.o default.o skipjack.o osrng.o arc4.o gost.o hmac.o hex.o esign.o randpool.o sharkbox.o base32.o files.o dessp.o fips140.o eprecomp.o dsa.o polynomi.o winpipes.o vmac.o md2.o fipstest.o ccm.o simple.o queue.o xtrcrypt.o gf256.o cmac.o authenc.o idea.o oaep.o squaretb.o pkcspad.o emsa2.o sha.o network.o eax.o rijndael.o rc5.o square.o algparam.o elgamal.o zlib.o dh2.o camellia.o ecp.o adler32.o wait.o iterhash.o safer.o rc2.o gf2n.o ida.o shark.o md5.o shacal2.o ttmac.o tea.o serpent.o eccrypto.o ripemd.o gcm.o pubkey.o trdlocal.o salsa.o seal.o luc.o hrtimer.o crc.o tigertab.o mqv.o dh.o bfinit.o cryptlib_bds.o whrlpool.o rw.o cast.o tiger.o rng.o channels.o asn.o zinflate.o pssr.o misc.o mqueue.o rc6.o base64.o zdeflate.o basecode.o des.o blowfish.o blumshub.o ec2n.o dll.o gfpcrypt.o cryptlib.o algebra.o strciphr.o casts.o modes.o md4.o nbtheory.o socketft.o twofish.o tftables.o pch.o cbcmac.o rsa.o rdtables.o sosemanuk.o 3way.o gf2_32.o gzip.o rabin.o filters.o cpu.o
ranlib libcryptopp.a
make[2]: Opuszczenie katalogu `/xxxxx/BitcoinArmory/cppForSwig/cryptopp'
cd leveldb; make libleveldb.a; mv libleveldb.a ..
make[2]: Wejście do katalogu `/xxxxx/BitcoinArmory/cppForSwig/leveldb'
g++ -I. -I./include -fno-builtin-memcmp -pthread -DOS_LINUX -DLEVELDB_PLATFORM_POSIX -fPIC -O2 -DNDEBUG -c db/builder.cc -o db/builder.o
g++ -I. -I./include -fno-builtin-memcmp -pthread -DOS_LINUX -DLEVELDB_PLATFORM_POSIX -fPIC -O2 -DNDEBUG -c db/c.cc -o db/c.o
db/c.cc: In function ‘bool SaveError(char**, const leveldb::Status&)’:
db/c.cc:141:42: error: ‘_strdup’ was not declared in this scope
db/c.cc:145:42: error: ‘_strdup’ was not declared in this scope
db/c.cc: In function ‘char* leveldb_property_value(leveldb_t*, const char*)’:
db/c.cc:250:30: error: ‘_strdup’ was not declared in this scope
make[2]: *** [db/c.o] Błąd 1
make[2]: Opuszczenie katalogu `/xxxxx/BitcoinArmory/cppForSwig/leveldb'
mv: nie można wykonać stat na `libleveldb.a': Nie ma takiego pliku ani katalogu
make[1]: *** [libleveldb.a] Błąd 1
make[1]: Opuszczenie katalogu `/xxxxx/BitcoinArmory/cppForSwig'
make: *** [all] Błąd 2
"Błąd" mean "Error"  In the leveldb folder, there's is a file called c.cc. At the top of the file there's a line that looks like this: #define strdup _strdup delete that line or comment it out. |
|
|
|
The attack works by bribing miner to orphan certain blocks, it is not A against B but building coalitions to claim the bribe.
I think that the attack is technically valid but participating in it by any of the miner depends on if they are greedy, especially short term greedy. Accepting the bribe brings higher profit in short term, but diminishes the value of their coins and investment on the longer term, since it hurts credibility of the entire system.
I listed A against B scenarios because they are realistic. Your point is that if A wants to harass B, he can bribe third parties to his cause. My point is if A and B have equivalent resources, both A and B can perform the same bribe attack onto each other, which will nullify the attack and just cost each some extra BTC. Stepping out of that scenario, if A is huge compared to the network, A won't need to bribe any of the third parties to harass B. If A only has a small fraction of the hashing power within the network, then the attack can be mitigated in a way that it would increase its cost, which will most likely deter an attacker of such small size. Bottom line, the attack is technically feasible and but not economically viable. |
|
|
|
Is there the option to sign a transaction with a message, only readable for the receipient? (like in a bank transaction). It would make business much easier. It sounds like what you want isn't to sign a message but to encrypt it and attach it to the txn. In qt I just found the sign a message with your adress, but this looks like the opposite (also I don't know what's the sense of this option)
This is to prove you own an address on the chain (and thus its coins) |
|
|
|
|
This looks overkill to me. What realistic scenario is there that would implement this attack? Assume miner A is going after miner B:
1) If A and B have about the same hashing power (thus the same funds available to them), if A attacks B this way, B can simply return the attack in kind, nullifying it.
2) If A is a huge miner and thus dwarfs B, they don't need such sophistication. They can just refuse B's blocks at a lower cost (without implementing the attack) and simply overwhelm them by chaining a couple blocks. It is safe to assume the rest of the network doesn't want to be involved in such a feud and will quickly side with the big miner as they'd rather not waste processing power over a block they know has a high chance of being orphaned. At this point a monetary incentive is overkill, the big miner can simply rule by terror. This is why hash rate distribution is so important to the Bitcoin network.
3) If A has lots of funds but low hashing power, they're better off just purchasing hashing power that trying this move.
4) Leaves the last situation where A overpowers B, but isn't strong enough to sway the whole network their way. It then becomes a matter of endurance. How long can an attacker last, and how much is it going to cost in fees, realistically?
If I was a miner being attacked in this fashion, I'd make a list of all their coinbase addresses and simply ban all coins finding their origin in those coinbase txn. I will then gradually ban txn that are linked to this user, eventually compiling a black list of attacker controlled coins, mitigating the attack.
In return the attacker will use a large amount of txns to try and squeeze one in the blocks I'm mining. As long as I have not mined a block, they would have no way to know which of their txns have gone through my ban list, forcing them to maintain this approach for the rest of the attack, which would end in a drawn out, long term battle, with easily identifiable parties, which would further allow me to ban txns based on the node they originated from.
The more I mitigate the attack, the more expensive it gets on the attacker. This cost needs to be compared to the projected profitability to the attacker.
|
|
|
|
|
Some sort of transaction script could get it to work I guess:
To clear coins on current address one needs to
1) either wait x blocks to send to any address
2) or send them instantly to a predefined "safe" address under your control
Since you have to clear the script requirements of an output to redeem its balance, you can thus enforce transaction emitters to add this "spend in X blocks" rule. Other txns would be turned down by the network, unless they point directly to the safe address listed in the output's script.
Once the new txn is hashed into a block, the signed coins will be available until hashed block number +X is achieved, which gives you time to emit a direct txn to the safe address if needs be. Kind of a delayed double spend I guess. Should be implementable in the main chain at limited cost, just a matter of activating some script opcodes I think.
|
|
|
|
Looking at the pin list, it has 11 data connections and 2 for power/gnd.
That suggests it could be interfaced, since the pi has lots of GPIOs. There are 2 headers at either side, so maybe not very convenient.
I am not sure about drivers. However, it is probably possible to "bit-bash" the GPIO pins and do the SPI writes.
Writing an ASM driver for a single $12 piece of hardware? Ouch... |
|
|
|
#define strdup _strdup
This line is for the msvc11 build only. Sorry, it should be only defined for the Windows project: #ifdef _MSC_VER
#define strdup _strdup
#endif
|
|
|
|
|
Most likely an msvc11 build. Long story short, the tool used to build Armory for Windows doesn't natively creates .exe that can be run under WinXP. You'd have to select the specific build tool for XP to build XP compatible Armory. The task is simple, but that version of the binary is most likely not bundled in the package you got. You should ask for a WinXP build or build it yourself, although you'll need Win Vista or above to build it, since msvc11 needs .Net Framework 4.0, which is for Win 6.0 and above only
|
|
|
|
|
Show Posts
