|
I like the idea of autotrade, but your implementation requires trust.
I think some sort of multi-party transaction would be a better route. Armory's support for offline transactions will probably make this easier since you can build partial transactions to be signed later.
|
|
|
|
|
I'd recommend Ubuntu considering that's what Armory is developed with. The no network privacy remix sounds like a good idea.
|
|
|
|
|
All this security, but you don't check github's SSL certs?
|
|
|
|
not really. the best source of feedback is IRC I have been working on a new sever backend, that uses only bitcoind and not Abe. it is almost ready. I'll catch up with the docs after that I'll test this the moment it's out! No libbitcoin or Abe? |
|
|
|
I really don't see the difference between having a GPU you could sell for $200 but choose not to in order to mine Litecoin/Vanity addresses, and investing $200 to purchase the same GPU for the same purpose. Either way you're giving up $200 in order to mine.
Yes, $200 = $200, but that isn't the only cost. Cards don't show up at your door and start mining. You have to do some setup and probably play with clock speeds. If you've already done this for a card for BTC, transitioning the card to a new purpose is less work than setting up a brand new card. |
|
|
|
So instead of writing the same post I write every time the topic of Bitcoin energy usage comes up, I'll just link to all the others, in chronological order: https://bitcointalk.org/index.php?topic=10411.msg149581#msg149581https://bitcointalk.org/index.php?topic=10832.msg156457#msg156457https://bitcointalk.org/index.php?topic=74356.msg855455#msg855455https://bitcointalk.org/index.php?topic=106245.msg1166103#msg1166103And here's another one by Stephen Gornick, three weeks ago, pointing out the exact same thing: https://bitcointalk.org/index.php?topic=117927.msg1278020#msg1278020Using the "4 MJ per banknote" figure in the presentation, and stats from the US Treasury, circulating one-dollar bills alone consumes 338 megawatts, or more than 50 times the entire Bitcoin network. And that's even ignoring the fact (pointed out in the presentation but ignored in the figures) that the number of Bitcoin transactions can increase by a factor of 10 before hitting even the artificial transaction limits imposed by the protocol, which can be removed. After that, you can read the wiki to see how easily Bitcoin can again scale by another factor of 300 with minimal increase in energy consumption. Altogether, that gets Bitcoin to a market cap of around $10 trillion, while still beating paper money in energy consumption with basically zero modification at all. Beyond that, if by some miracle Bitcoin ever comes remotely close to the stupid amount of waste generated by the traditional banking system (which it won't), proof of work can easily be replaced. So energy usage is, again, probably the single biggest non-issue in Bitcoin ever. I fully agree with you except for "proof of work can easily be replaced." what do you mean by this? I don't think it's trivial to remove the PoW from bitcoin at all. |
|
|
|
I see all of those 5xxx cards for sale, and I kinda wish I could put them to good use. Vanity mining is in my future, but it's not worth investing in.
Vanitypool is nice, but it's not often worth more than Bitcoin mining. Currently I would lose money activating it (at ~$0.15/kWh) even with 90% PSU power efficiency and GPUs at 0.95V. Clearly you're right: not worth investing in. But that doesn't mean I can fool around with it once BTC mining becomes unprofitable.  I wouldn't buy cards for it, but if you have cards running, it might worth looking into depending on your cost of electricity. |
|
|
|
|
Mine vanity addresses with them.
|
|
|
|
Here is a request I'd like to make:
Currently there's a page for Vanity Wallet.
It is presently able to take two private keys in hexadecimal, and provide the EC product of the two, along with its corresponding public key and bitcoin address. I would like this page enhanced.
Here is what I'd like changed:
1. I would like it to accept key input in any private key format the codebase recognizes (compressed private keys may either be disallowed, or simply not allowed to be combined with uncompressed keys). Specifically that should include "minikeys" (30-characters) as well as the usual 51-character code that starts with '5'.
2. I would also like it to accept user input of up to one public key - in other words, one box can contain a public key and the other box can be a private key, and the resulting public key and bitcoin address will be shown (with the corresponding private key unavailable, of course).
The reason is that I would like to start offering 2-factor physical bitcoins (mostly my gold-plated savings bar), and have BitAddress.org be the only tool the other party needs to securely participate in this sort of offering.
The reward for completion: Five gold-plated two-factor Casascius savings bars engraved with the vanity addresses of your choice (because you will generate your addresses starting with five different public keys I give you, one for each bar.) Shipping is included.
This would be awesome. That's a great bounty, too! |
|
|
|
|
This is a cool idea. I had been reading the first and last few characters to make sure the address was right. This is even easier.
|
|
|
|
Props to the TRC developers (code modifiers) in that TRC addresses look like bitcoin addresses. That is fucking awesome.
Also good job on not changing the BITCOIN logo to the TRC logo (if there is one).
They are "Developpers" according to their website lol |
|
|
|
You know what? I bet there's a problem with one of your wallets. One of of them is corrupt, maybe?
Can you temporarily relocate your wallets out of the .armory directory and then reload? I bet it will start, then.
I'll try that in the morning. Although the wallets load fine (albeit single threaded) with the dev branch. Oh! What about mempool.bin. It's possible for that to be corrupt, too. Because that is such a common cause of crashing, I put logic into 0.84.1 to detect when Armory fails to load more than 3 times, and automatically delete mempool.bin. Even if that's not the problem, perhaps you can check for me that it is at least detecting it. (1) There's a new entry in ArmorySettings.txt called "FailedLoadCount". That should be incrementing every time it crashes (2) The log file will eventually start reporting "<X> attempts to load blockchain failed. Removing mempool.bin." It should happen every time after the third failed load. Can you at least check for me that it is doing that? Though, if it is doing that, then it is removing mempool.bin, and there's nothing more for you to try. So far... I moved my ~/Library/Application\ Support/Armory directory to a safe place and then reopened Armory and it worked! It started freaking out about losing the connection to the Satoshi client, but I think that's just because I opened armory right after waking up my laptop so I was ~50 blocks behind. And it just crashed. I guess it must be one of my wallets. I'll load them one at a time and see what happens. So I tried just renaming them *.wallet.off, but they all still loaded  I'll just move them out of the folder. Testing my offline wallet first. EDIT: My offline wallets load, but my wallet that I imported from Satoshi (back when that was a thing) and my encrypted hot wallet both cause a segfault. I'm going to test them in Ubuntu. |
|
|
|
You know what? I bet there's a problem with one of your wallets. One of of them is corrupt, maybe?
Can you temporarily relocate your wallets out of the .armory directory and then reload? I bet it will start, then.
I'll try that in the morning. Although the wallets load fine (albeit single threaded) with the dev branch. |
|
|
|
|
Finally honoring my 1 BTC pledge!
76657054c41fc381622d96aacbc570c5a6441efc1d10545d8e1128e95ab0cb75
|
|
|
|
If you're on a Mac and not a software engineer, forget about creating a bootable USB drive using Ubuntu.
Apparently, the concensus and my personal experience is, it doesn't work.
How about someone update this tutorial to save more newbies from spending hours and hours pointlessly trying to create a bootable Ubuntu USB drive on OS X? Beuller... Beuller...
http://www.ubuntu.com/download/help/create-a-usb-stick-on-mac-osx |
|
|
|
I'm still getting a segfault on OSX I'm going to replace, lines 10776 and 10895 with some debug lines like you recommended before and then send you the output. I also just installed Ubuntu 12.04 desktop x86_64 on my gaming rig (Steam linux here I come!), so I can test Armory there, too. Hold off on that... I'll give you a version that has the blockchain-loading bug fix. In fact, it's already committed. Try it. Compiling now! EDIT: No luck  Still got a seg fault. I can give you the crash report, but it doesn't look too helpful. Log output seems pretty useless, too. Are you running it from the command line? Does it get through blockchain loading then crash? Mid-loading? I wonder if it's a wacky set of blkXXXX.dat files, which has turned out to cause issues in the past. But since those blk files are so damned big, I can never get anyone to send me one so I can debug it Speaking of that, does it work in --offline mode? If that works, sounds like a scan issue. I know it's a pain to redownload the blockchain... but if you are feeling generous with your time/bandwidth, could you rename your blk files and redownload and see if that solves it? If so, I can open the guest acct on my system for a night for you to scp the blk file with the problem. Not there yet, but I am getting frustrated by this... It happens right after the blockchain finishes scanning. This log might be helpful. Crashed Thread: 2
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
VM Regions Near 0:
-->
__TEXT 000000010dcc2000-000000010dcc3000 [ 4K] r-x/rwx SM=COW /Users/USER/*
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8a055686 mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8a054c42 mach_msg + 70
2 com.apple.CoreFoundation 0x00007fff819cc803 __CFRunLoopServiceMachPort + 195
3 com.apple.CoreFoundation 0x00007fff819d1ee6 __CFRunLoopRun + 1078
4 com.apple.CoreFoundation 0x00007fff819d16b2 CFRunLoopRunSpecific + 290
5 com.apple.HIToolbox 0x00007fff865d40a4 RunCurrentEventLoopInMode + 209
6 com.apple.HIToolbox 0x00007fff865d3e42 ReceiveNextEventCommon + 356
7 com.apple.HIToolbox 0x00007fff865d3cd3 BlockUntilNextEventMatchingListInMode + 62
8 com.apple.AppKit 0x00007fff827df613 _DPSNextEvent + 685
9 com.apple.AppKit 0x00007fff827deed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
10 com.apple.AppKit 0x00007fff827d6283 -[NSApplication run] + 517
11 QtGui 0x000000010f4f250b QEventDispatcherMac::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 1259
12 QtCore 0x000000010e8b9ba5 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 501
13 QtCore 0x000000010e8bca8e QCoreApplication::exec() + 206
14 QtGui.so 0x000000010eecb971 meth_QApplication_exec_ + 81
15 org.python.python 0x000000010dce25a9 PyEval_EvalFrameEx + 9244
16 org.python.python 0x000000010dce0147 PyEval_EvalCodeEx + 1934
17 org.python.python 0x000000010dcdf9b3 PyEval_EvalCode + 54
18 org.python.python 0x000000010dd1bc70 0x10dcc9000 + 339056
19 org.python.python 0x000000010dd1bd3c PyRun_FileExFlags + 165
20 org.python.python 0x000000010dd1b726 PyRun_SimpleFileExFlags + 410
21 org.python.python 0x000000010dd3fe27 Py_Main + 2715
22 libdyld.dylib 0x00007fff8621c7e1 start + 1
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8a057d16 kevent + 10
1 libdispatch.dylib 0x00007fff81f35dea _dispatch_mgr_invoke + 883
2 libdispatch.dylib 0x00007fff81f359ee _dispatch_mgr_thread + 54
Thread 2 Crashed:
0 _CppBlockUtils.so 0x0000000110b68cdb BtcWallet::scanTx(Tx&, unsigned int, unsigned int, unsigned int) + 2095
1 _CppBlockUtils.so 0x0000000110b69b00 BlockDataManager_FileRefs::scanRegisteredTxForWallet(BtcWallet&, unsigned int, unsigned int) + 402
2 _CppBlockUtils.so 0x0000000110b69df2 BlockDataManager_FileRefs::scanBlockchainForTx(BtcWallet&, unsigned int, unsigned int) + 478
3 _CppBlockUtils.so 0x0000000110cbefd6 _wrap_BlockDataManager_FileRefs_scanBlockchainForTx + 1094
4 org.python.python 0x000000010dce0f72 PyEval_EvalFrameEx + 3557
5 org.python.python 0x000000010dce0147 PyEval_EvalCodeEx + 1934
6 org.python.python 0x000000010dce68df 0x10dcc9000 + 121055
7 org.python.python 0x000000010dce263a PyEval_EvalFrameEx + 9389
8 org.python.python 0x000000010dce6869 0x10dcc9000 + 120937
9 org.python.python 0x000000010dce263a PyEval_EvalFrameEx + 9389
10 org.python.python 0x000000010dce6869 0x10dcc9000 + 120937
11 org.python.python 0x000000010dce263a PyEval_EvalFrameEx + 9389
12 org.python.python 0x000000010dce6869 0x10dcc9000 + 120937
13 org.python.python 0x000000010dce263a PyEval_EvalFrameEx + 9389
14 org.python.python 0x000000010dce0147 PyEval_EvalCodeEx + 1934
15 org.python.python 0x000000010dd19d7a 0x10dcc9000 + 331130
16 org.python.python 0x000000010dcd86c6 PyObject_Call + 97
17 org.python.python 0x000000010dcf59bf 0x10dcc9000 + 182719
18 org.python.python 0x000000010dcd86c6 PyObject_Call + 97
19 org.python.python 0x000000010dce6018 PyEval_CallObjectWithKeywords + 177
20 org.python.python 0x000000010dd427f6 0x10dcc9000 + 497654
21 libsystem_c.dylib 0x00007fff8ab29742 _pthread_start + 327
22 libsystem_c.dylib 0x00007fff8ab16181 thread_start + 13
I just re-downloaded the blockchain. Sorry, I didn't save the files, although I do have a time machine backup of them from awhile ago. The fresh download still crashes. |
|
|
|
I'm still getting a segfault on OSX I'm going to replace, lines 10776 and 10895 with some debug lines like you recommended before and then send you the output. I also just installed Ubuntu 12.04 desktop x86_64 on my gaming rig (Steam linux here I come!), so I can test Armory there, too. Hold off on that... I'll give you a version that has the blockchain-loading bug fix. In fact, it's already committed. Try it. Compiling now! EDIT: No luck Still got a seg fault. I can give you the crash report, but it doesn't look too helpful. Log output seems pretty useless, too. |
|
|
|
|
p2pool.stitthappens.com:8336 is now running 9.0 (2cb4d8381e179f71ea2075cdce948ea83cf0dc55)
|
|
|
|
One quick note, (Not sure if this has been thought of yet, or if I am missing the point on a larger scale)
For colored bitcoins...
Lets say I own the address 1DD6eE8d19j5gUJTzEPMvFsvDLsRaedhME , and make a bot so that every coin you send to it is bounced back to you. The coins are now referenced as once being a part of this address
Couldn't I just use the block chain to check if coins I owned have been passed through that address, making them "colored"? Of course you could simplify this with some work on the client to check...
Am I missing something :/
You are missing something. It isn't being referenced by an address that makes something colored. It's being referenced by a specific transaction. In Bitcoin, you trace can trace a transaction all the way back to it's generation as block reward. Colored bitcoins use this same principle, but rather than tracing the transaction to it's original block, they trace it back to its coloring transaction. The fact that one of your addresses owns colored bitcoins has no effect on the color of coins you send unless you send the actual colored coins somewhere. Your hypothetical bot would taint the coins (taint like on blockchain.info), but this is not the same as coloring. Taint is tracking links between addresses and coloring is tracking the specific coins. |
|
|
|
I'm still getting a segfault on OSX I'm going to replace, lines 10776 and 10895 with some debug lines like you recommended before and then send you the output. I also just installed Ubuntu 12.04 desktop x86_64 on my gaming rig (Steam linux here I come!), so I can test Armory there, too. |
|
|
|
|
Show Posts
