If the 10-minute gap is carefully synchronized to occur just before a retarget then we will have interesting problem in both game theory and control theory.
Could you elaborate on this point? I'm not too familiar with the intracacies of retargeting. I would expect that both sides of the network would compute the next block with different difficulties, and when they reconverge, the chain with the maximum cumulative difficulty would "win" and nodes would switch to that chain with that new difficulty (thus, if both chains have the same number of blocks generated since the split, the one with higher difficulty will win when they reconverge). |
|
|
|
* In left-to-right languages such as English, check boxes (such as those in the Preference dialog) are supposed to be to the left of the label, not the right, and vice-versa for right-to-left languages.
I did it that way just because of the layout of the rest of the dialog which has descriptions on the left, interactive widgets on the right. I could switch it, but I feel it wouldn't look right... I think I generally used default layout for checkboxes elsewhere in the app (I let QCheckbox decide for me, probably based on locale). If I didn't, please point it out to me. * The default date format (%Y-%b-%d %I:%M%p) isn't my system default date format (ISO 8601), and isn't even a standard date format used anywhere in the world. Where'd this weird date format come from? Also, for the example date, it's generally recommended for the time to be after 12:59 PM, to make it easier to differentiate between 12- and 24-hour time.
Ack! I forgot that the date displays differently depending on your time-zone. On my system the datetime is 10:32pm so that when the user switches to 24hr clock it is apparent. I selected the unixtime to use based on my clock, forgetting others would see a different time. I guess I can manually set the datetime object, to guarantee that the example time shown is 10:32pm on the user's system. As for default format, you're right. I picked a default I like. And that's why I made it an option. I kind of wanted to use %c for the reason you mentioned, but then it would not be obvious to the user how to modify that field. * It looks like I didn't fully test the light-on-dark colour scheme handling earlier: unconfirmed transactions in the ledger are displayed in black on a dark background. I understand reducing the contrast for unconfirmed transactions, but I think you overdid it slightly.  I'll see if I can improve that. I set my offline system to a dark theme so that I have a place to test those colors, but obviously it won't be displaying zero-conf tx... |
|
|
|
New feature almost complete! Need feedback!I want to make it easy for users/merchants to request payments from other users. Now that Armory supports clicking on URIs, I wanted users to be able to create them. What comes to mind is the woman at statelesssweets.com with whom I had to iterate a couple times to make sure we were in agreement about BTC price and quantity (btw, I highly recommend her sweets, they are delicious!). So I want merchants to easily be able to create blocks of text to copy into websites or emails like this: Click here to pay!If the link does not work on your system, use this payment information: Pay to: 1y9F9ER9B45LieNcQ8dEV6YTGNPrwW3YG Amount: 12.95 BTC Message: Joe's Fish Shop - Order #123 - 3 kg tuna - (888)555-1212 I have put together the following interface, but I'm not completely satisfied with it. I need some feedback. (1) You can either right-click on an address in your address book and select "Request payment to this address", or when you create a new address, there's now a "Make clickable link" button:  (2) You then fill out the fields as you would like the recipient to see them. This is the part that is mildly difficult to communicate. I am hoping it comes across as self-explanatory. Btw, everything shown here is the default (except for Amount which starts blank), because I want users to see what kind of information they could be entering into the fields. But it might be too over-the-top...  (3) I wanted to allow the user to copy raw HTML or URI (forum users will need to copy the raw URI for forum posts), but I also didn't want to confuse the majority of users who will just copy the block of text and might be confused by the extra buttons. However, I haven't yet figured out how to programmatically copy HTML into the clipboard the same as selecting it and <ctrl>-c. So I couldn't create a "Copy All Text" button. But I wonder if that's really an issue.  (4) The recipient sees the block of text, and if they're using Armory, Multibit or Electrum, then they will see a popup like this after they click on it (I need to polish this dialog a bit):  (5) After selecting a wallet, they are 1 click away from sending (plus typing in passphrase...)  So far, I've already been using it for myself. Mainly to setup donation links on my webpage. I know that most users are still using Bitcoin-Qt which does not support URI-handlers, but I hope they will eventually. Because this functionality (both creating and clicking links) is such a dramatic improvement for the community, and much of the community is not yet using alt clients... Questions, comments, recommendations and donations welcome!
|
|
|
|
I agree the current logo is good. I don't think it needs change, but I wouldn't be opposed to alternatives if it didn't stray far enough to be a complete rebranding. I think trying to rebrand Bitcoin might not go over well, but it is possible for users&merchants to slowly transition from one logo to a similar-looking logo. I highly recommend 99designs.com as well. I got my Armory logo done there (see my avatar icon, without the e^ipi), and I thought $300 was completely reasonable for the massive selection and amount of refinement I got. You will have to have someone highly respected and trusted to manage the process (I'm looking at Erik), because it is a process: designers will contribute tons of great ideas, and you need to constantly dig through them and rate and comment on those designs, so that designers can come up with further ideas, or refine existing ideas to the tune of what is desired. I think even if you don't end up with a design that you like, you will get tons of ideas, and $300 is nothing for such a high-value project. I'll donate 5 BTC for it. A couple things to pay attention to, that I didn't think about before I got my logo done: - (1) It should be simple -- just because it looks cool doesn't mean it's memorable and distinct. Consider google logo (just a 'g'), nike logo (checkmark), facebook, etc. Very simple and effective. No 3D skills are required.
- (2) One of my primary criteria for my Armory logo was that I didn't want it to be round, because if you look at your taskbar right now, you'll see that most of your existing applications use round logos/icons, and it to be distinct. In the world of Bitcoin, that might be too much to ask for, because it will probably have a coin theme... but just a perspective to consider...
- (3) My logo requires gradients to render the 3D properly, and that turned out to be a total PITA when it came to getting shirts printed. I had to pay for full-color printing, even though it's only a couple base colors and I was only getting a tiny print on the left breast, and that increased the cost almost 50%. This isn't relevant for just shirts, there's a lots of applications where full-color is inconvenient (getting stationary created, making signs, etc).
- (3a) Extra credit: the logo should also have the same essence when converted to binary-black-white (no greys), and still be identifiable when black-white is inverted. This further expands where it can exist, and makes it even cheaper to include on Tshirts, signs, etc. It doesn't mean that the base, hi-res design shouldn't have colors/gradients to it, only that it should still be identifiable and look good when converted to black-white.
The current logo succeeds quite well at all those criteria, but as someone who has spent a lot of time in Thailand, I do disagree with its resemblance to the baht symbol (Thai money). Just thought I'd pass along my own experience with this, since I had to go through the branding process 6 months ago, and have some experience now trying to promote my brand with a full-color 3D logo. [/list] |
|
|
|
|
I own the first one (it's in my sig). It's actually not too crazy for a GPU to produce, but you need regex which isn't supported by GPU-vanitygen. So, I sent a few of my my idling CPUs (on my mining machines) on that task and found it in a couple weeks. I think I figured out it should've been like 70 days on average, so I definitely got lucky! I'm not sure it was really worth all the energy I could've spent trying to find it, but it's not like my CPUs were doing anything useful anyway, and my PSUs are adequately overpowered for the GPU load...
The only problem with the address is that it's so strange that many people don't even recognize it as a real address. It's disappointing to get messages like "What is 1QBD?".
|
|
|
|
I have more than a hundred of mBTC size inputs in an offline wallet and want to send to a single address. The total balance is about 0.16BTC and Armory requires me to pay 0.0195BTC as fee. However, it always returns "SelectCoins returned a list of size zero. This is problematic and probably not your fault." What should I do?
That's super interesting! I just stumbled across that error message in the code the other day and was amused that it was still there. And, until now, I've never seen or heard that error triggered. Though, I also haven't tested sending transactions with hundreds of inputs... One thing to try would be sending (FullBalance - 0.0195) and then set the fee to 0.0195. I would guess there's an issue with the iterative process of trying to find the right fee for such a large transaction. If you tell it the correct fee to start, it might work better... Can I purchase a watching-only version of that wallet for 0.20 BTC? I would really like to step through Select coins in a debugger with that wallet, to figure out what's happening. Even if you succeed in getting the coins spent, I can just stop the blockchain reading before they are spent so that Armory will try spending them, and then I can track it down... Unfortunately, I live on the east coast (US) and my power has been out for 2 days, so I don't have access to my development machine(s). I hope my power comes back soon, and then I'll dig into it... |
|
|
|
So I just got a question about checking .deb signatures. I spent an hour waiting for my crappy offline system to generate a 4096-bit GPG key, so that I could start signing packages manually. And then I manually took the packages to that machine, and used a debsig package to apply my signature using the "builder" signer-type. I got the message stating that it was signed, and then I moved that back to my online computer and posted. However (this was stupid), I never actually checked the signatures were valid before uploading them to github. However, now that I try to do it with the debsig-verify package, it tells me there's no signature!? Maybe I uploaded the pre-signed packages... Here's what I did to check the signature, which I believe is correct. Once I get this process ironed out, will start including all of this with the offline-all-in-one package so that there will be considerably fewer steps. Maybe I missed something. For checking using an online computer (the key id is 98832223): - 1. sudo apt-get install seahorse debsig-verify
- 2. gpg --keyserver pgp.mit.edu --recv-keys 98832223
- 3. debsig-verify armory_0.81-1_i386.deb
For offline computer, you need to download some stuff from online first, then take it to the offline computer: There was a crazy storm last night that took out power to huge areas of my county. So I'm at a coffee shop right now and don't have access to any of my development systems. I'll check the signatures when the power comes back on. |
|
|
|
The makefile now checks for the existence of the path for the highest available Python version from 2.7, 2.6 and 2.5. On Gentoo it's not uncommon to have multiple Python versions installed simultaneously, so this check fails on my system because I have 2.7 installed, but my default version is 2.6. I have very little knowledge of pythonisms, but I'd guess that asking the python executable itself would be a more robust way to determine the version number. This solved the issue for me: PYVER = `python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`
SWIG_INC += -I"$(DEPSDIR)/include/python$(PYVER)"
STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a" You are absolutely right. I am terrible with Makefiles. I had modified the Makefile, at least temporarily, to statically link python so that there would no longer be python issues for users who use the *.deb packages, but I did so [apparently] at the expense of those compiling from source. Your recommendation is very helpful, and I will adopt that or something similar. I knew there was a better way to do it, but you are the first person that has mentioned it! Thanks! |
|
|
|
|
For those that are compiling from source, version 0.81 is on the "dev" branch.
EDIT: Disregard that. I already merged into master a few hours ago and completely forgot! Whoops!
|
|
|
|
|
For reference, the correct way is to use long-integers to store the number of satoshis, which is 1e-8. That is the smallest "atom" of a Bitcoin, limited artificially by the original design of the network. There should be no rounding unless you're talking about rounding the 9th decimal place as the result of a calculation.
In Armory, my coin2str() function truncates zeros from the right side so that users who only only deal with >= 0.01 BTC units and higher aren't overwhelmed with zero digits. It is my policy that if there is precision down to 8 decimal places, I show it.
It should never be stored as a float or double. Set a constant ONE_BTC=100000000 and then when you want to specify something in Bitcoins, say long(2.5*ONE_BTC). And a coin2str() function to convert from Satoshis back to a pleasant string representation.
|
|
|
|
I had high hope for this client and apart from that I'm not disappointed.
I've been watching a while for 6.00 import, What is the best place to watch for update ? I see that the download page still show 0.80
You can subscribe to the announcement thread to receive updates when I make official releases: https://bitcointalk.org/index.php?topic=75647.0The main page still says 0.80 because I just discovered this problem yesterday and haven't had time to test 0.81 much yet. However, I wanted to make it available for folks like you who are inconvienced by the broken feature -- hence why I post it here, and hope some people will use it and report bugs. It was tough to tell after 4 sentences of hard criticisms whether your last line about a great client was sarcasm. I understand that your first impression was hardly something to brag about, but that's why it's still alpha. I also just completely revamped the blockchain utilities under-the-hood. I expected there to be some issues, but nothing as silly as botched importing. I guess this version isn't quite stable, yet. Hopefully 0.81 has fixed it (and it has some extra features), perhaps you'll try it out and tell me if it meets your expectations. P.S. -- The 0.6.X wallet import is going to be a while. I need a whole new wallet format in order to support compressed public keys, which is what's used by the Satoshi client. And changing the wallet is no small deal... I've already started a branch for it, but it's a huge change and going to require tons of testing since that is the most sensitive part of the application... |
|
|
|
I've tried using Armory, all of what I wanted failed.
importing Bitcoin-QT 6.xx fail ,,, well that's highly needed.
Importing private key / address, : It would loop endlessly at asking me, "is this address accurate - yes", I type password to decrypt wallet , loop
It wouldn't say password fail or anything, anyhow I'm pretty sure of the password, I've just created / entered it ~4 times.
And finding "import private key" wasn't were I expected it, "Wallet properties" really ? Maybe it could be part of receive bitcoin.
Thanks for this great client.
Transisto, I have a warning about 0.6.X being unsupported. They will be supported in a future update. If this is a problem, please use another client. My apologies about a bug in address importing in 0.80. If you are running Windows64 or Linux64, the links for the fixed versions are three posts up (version 0.81). It should be completely fixed, there. I will compile 32-bit binaries tonight. Importing private keys is a wallet operation. It has to go into a wallet. I can perhaps add something to the menu that helps you find it, and then let you select a wallet after you click on it. This software is not magical -- it's still a work in progress, and if there are features unavailable, then please use an alternative. I do apologize for the lack of quality control on 0.80 -- this is why I need more people helping me test. Please try 0.81, unless you absolutely need the Satoshi 0.6.X wallets. P.S - As for address importing 0.6.X wallets -- I highly recommend users actually just create a new wallet and transfer their funds to it. I have tried hard to support wallet migration, but it is likely to open you up to issues anyway, the same way as running the same wallets in two places simultaneously with the regular client. |
|
|
|
New features and bug-fixes! (Unofficial 0.81-alpha) - Export Transactions Window: Right now, it only exports in .csv format. You can select which wallets to export, sort order, and date format. It's a .csv so there's no way to integrate formatting or formulas, but I want to eventually add the capability, if possible (I found a python-xls-writer module that appears to have a very permissive license I might be able to use for this purpose). For now, I'm happy just to have the export capability implemented at all!
- Options/Preferences Dialog: Set your default transaction fee, date formats, usermode, and system tray notifications!
- Major bug fix (spend zero-conf change): If Armory needs to use zero-confirmation sent-to-self outputs to construct your transaction, it will crash. No more.
- Major bug fix (address importing): How did I miss this? This is why I need more testers! It's not 100% -- I've witnessed a crash while rescanning in Windows, once. Can't reproduce it again in Windows or Linux. Please let me know if you find a way to trigger it -- but worst case it will only cause Armory to crash after importing, and then everything will be functional and correct after restarting Armory.
Win64 installer and a Linux64 installer |
|
|
|
My guess is that someone found a vulnerability
how likely is it someone could brute-force the daily secret hashed and published in advance? In a perfect world, the methodology is secure, and this would be extremely difficult. Even with millions of bets there should be no way to reverse-engineer the secret from the HMAC operation, especially knowing only the last two bytes. (is the full output of HMAC(secret,TxID) shown?) It's my understanding that there has not been a lot of confirmed double-spend [attempts]. I could be wrong though. But the world isn't perfect. The machine holding the secrets and doing the calculations must be connected to the internet. Maybe someone found a way to get the server to leak information. I'm sure interested peoples have isolated a "direct" connection to this node, and even if they don't "hack" it, may be able to get useful information out of communicating with it. |
|
|
|
|
My guess is that someone found a vulnerability and exploited it for 1000 blocks, and is waiting for the site to "refill" before doing it again. The sequence of losses is just way too extreme over that 182k-184k region to be luck, unless it's based mostly on long-shot bets. But from the previous postings, there haven't been a ton of long-shot bets..
Or the vulnerability was found and fixed. I'm not really sure. But as an attacker, it might be more beneficial to let the site recover and skim money instead. So you get the benefits of running a gambling website without actually having to run one!
|
|
|
|
|
FYI: Armory doesn't do this yet. If you have an older wallet, you can migrate it into Armory, but Armory will start generating different addresses than Bitcoin-Qt/bitcoind after that point, so they won't really be the same wallet anymore.
However, the main devs have decided to implement deterministic wallets into Bitcoin-Qt/bitcoind, and I've been part of the development discussion about it. I will be implementing the same wallet format (and maintain support for the old wallet format, too), so it will be possible to share wallets between programs. That's probably a few months away, though.
|
|
|
|
|
Thanks dooglus. I've been super busy and I accidentally deleted my most-recent updates to that script, and didn't feel like reimplementing it. I've been too busy trying to get out the next version of Armory.
You got the interpretation right: looks like SD is taking a really long time to process bets so there's a lot of unreturned bets piling up.
|
|
|
|
|
My guess is that 1 GB is not enough for the new blockchain utilities. Or it's not enough in the presence of other resource-heavy applications.
I don't know why it doesn't load at all, though. I would just expect it to take a while ... perhaps 5 minutes?
I just tested it on a 10.04-32bit VM with 1 GB of RAM and it took 58s to load. Not fantastic, but it works. I wonder what else could be causing it...
Anyone else have any issues with it? I was hoping to get some positive responses about the fixed coinbase transactions and unconfirmed values :-/
I'll probably convert make the last version 0.80-alpha and get started on the next round. Which by the way, I looked and found I had already put in the optimizations I thought I had -- they were just in a differnet place. So I don't know what else I can do other than just making it save data between loads...
|
|
|
|
I posted an idea about how to make 0-conf tx safe. There was some discussion, and it wasn't killed so far, but there wasn't much of an interest either, so I am starting to believe that it's not something demanded. I think when one of the core developers immediately points out how it can be used to reliably defraud somebody, that makes it pretty much DOA. But I would propose that there is indeed demand for a reliable zero-confirmation transaction. I hate bringing up zero-conf tx in general, because there are so many issues with them that they are useful only in isolated cases, usually partial-trust situations. I guess, this shouldn't be seen as a driving force for implementing this proposal, but more seen as an example of how much verifiable information can be obtained from the network with minimal download. It's fast enough that a light node could obtain as much information about a zero-conf tx as a full-node, with just a few kB downloaded. Regardless of how that information is used, it's a huge functional advantage from where we are currently. |
|
|
|
|
The number one problem that this solves (besides blockchain pruning) is one of trust. When a new node gets on the network right now, there are two options:
(1) Run a full node, with full blockchain, ultimate security -- verify everything in the blockchain yourself
(2) Run a lightweight node, with reduced level of security -- trust that someone else gave you your own correct balance, and have no way to check whether transactions are valid, especially zero-conf tx
With this meta-chain in place, you can run (1) for a lot less disk space, and (2; lightweight nodes) can achieve the ultimate security model without needing to hold the full chain. I can verifiably import my own wallet knowing nothing but the headers and verify it directly against the blockchain. If someone gives me a zero-conf tx, I can check not only that its inputs exist, but that the inputs haven't been spent yet. Zero-conf tx should not really be trusted, anyway... but at least you can verify whether it's even possible for the network to accept it, which what a full node does.
|
|
|
|
|
Show Posts
