I'm assuming this is because they're only 32 bit integers? Or is it because of the inaccurate way that these data types store decimals?
Yup - because they are binary floating point types the problem is indeed due to the representation of certain decimal values (same as 1/3 can't be expressed without recurring digits in decimals). These type of issues are not always seen when doing fairly trivial calculations but can cause real problems when you are dealing with dollars and cents (especially when it comes to auditors  ). Unfortunately I had the bad luck to work on a project that was involving decimal calculations and had chosen to work with the double type - as they didn't want to change the choice of type the resulting code ended up with rounding functions being called all over the place (a horrible mess). |
|
|
|
There's no need for that. You are writing a console program and it writes to the console. And it's a habit you should break as soon as possible, because when you write programs used as pipelines or redirected to files, that will break things.
I have to agree that even rather than the at least more standard C++ approach I suggested it would be better to just change your console settings so that the console window doesn't disappear when the program has finished (assuming I guessed correctly as to why you had coded this). Another thing to at least be aware of (in terms of bad habits) is that the use of float or double types for any professional financial software would be considered a very bad idea (unfortunately though Standard C++ doesn't provide an alternative type for this). |
|
|
|
Not a bad start - just a couple of minor problems: 1) void main( ) is not Standard C++ - you need to use int main( ) (although you don't actually need to code a return statement in main). 2) I'm not quite sure what the point of the system( "Pause" ) - is this because you are using Windows and are trying to prevent a command prompt (or DOS box as still sometimes called) from disappearing? If so then for a more Standard C++ approach maybe use "cin" with something like the following: ...
while( true )
{
... original code here ...
char ch;
cout << "Again or Quit? [aq]";
cin >> ch;
if( ch == 'Q' || ch == 'q' )
break;
}
...
|
|
|
|
Bitcoin withdraw to 1FtWDqjyiuPVzh3tabdb7XoWnVX6gVEg1M
...
Have you sent coins to that address before ?
Specifically did you send 28.25140702 BTC to that address previously? |
|
|
|
|
Why not pay for a VPS service in BTC (have seen a few advertised here) and run your own private git server?
|
|
|
|
|
There is a checkbox setting under Profile -> Look and Layout Preferences that says "Return to topics after posting by default." - I think you might need to uncheck this.
|
|
|
|
|
If you sent the tx using a standard (non-raw tx API) method then in all likelihood the tx is valid and will eventually get confirmed (this could take quite a while depending upon the priority it has). For this case "undoing" the tx is not possible (so be patient and maybe next time consider adding a slightly bigger fee).
If the tx is actually not valid (which should usually only possible if you had constructed it yourself manually using the raw tx API) and you are certain it will never get confirmed then you can use pywallet to remove the unconfirmed tx from your wallet (this can be necessary for removing double-spends).
|
|
|
|
|
It is entirely up to the wallet/website to decide how many confirmations they want to consider as being acceptably safe from reversal.
Any double-spend attempt will fail regardless so the waiting for confirmations is mostly useful to a website or to a user in order to satisfy themselves that the blockchain won't be re-organised by a new chain that invalidates the tx concerned.
Minor re-orgs can happen regularly (due to two different solutions to the next block being broadcast at roughly the same time - the race is then to determine which branch will win out according to subsequent blocks being built upon each branch), however, these would rarely involve any double spend attempt.
If someone is attempting to perform a double-spend and they have the hashing power to present an alternative chain to the current one that invalidates the tx concerned (by placing another tx with the same input and different outputs) then the tx would end up with zero confirmations (being now considered as a double-spend attempt).
|
|
|
|
I wonder if it's really that bad. In a way, won't they actually help this market discover the true price of a transaction?
I don't think that micro txs are the real issue (the pricing of tx's using tx size and coin age stops spamming without fees) but instead the handling of a large # of txs (small or large). In some ways we can thank SD for giving the system a bit of stress as it is now obvious that further development (much of which is already underway) is needed in order for the system to scale up (which will be necessary if it is to ever compete with the likes of a payment processors such as the current credit card ones). |
|
|
|
That one worked, thank you!
Most welcome - as stated quote stuff with Windows console/batch really sucks bad (that's why I wrote the utility to help me with such problems). |
|
|
|
WTF is Windows doing with the arguments?
Okay - well to get my program to do that I changed the input to this: C:\bin>args "[{\"txid\":\"eb63d5d53cd906b5cf75a014e1bcf1c0198ae58d378d45dbfa15045ac89a38ac\",\"vout\":0}]" "{\"1GMaxweLLbo8mdXvnnC19
Wt2wigiYUKgEB\":23.35}"
arg[ 0 ] = 'C:\bin\args.exe'
arg[ 1 ] = '[{"txid":"eb63d5d53cd906b5cf75a014e1bcf1c0198ae58d378d45dbfa15045ac89a38ac","vout":0}]'
arg[ 2 ] = '{"1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB":23.35}'
(without a doubt quote characters are a huge PITA with Windows console and batch file calls) Also this is the source of the "args" program I am using: #include <iostream>
using namespace std;
int main( int argc, char* argv[ ] )
{
for( int i = 0; i < argc; i++ )
cout << "arg[ " << i << " ] = '" << argv[ i ] << "'\n";
}
(I wrote this program due to many such issues I've encountered before) |
|
|
|
So maybe this?
C:\Bin>args [{^"txid^":^"eb63d5d53cd906b5cf75a014e1bcf1c0198ae58d378d45dbfa15045ac89a38ac^",^"vout^":0}] {^"1GMaxweLLbo8md
XvnnC19Wt2wigiYUKgEB^":23.35}
arg[ 0 ] = 'C:\Bin\args.exe'
arg[ 1 ] = '[{txid:eb63d5d53cd906b5cf75a014e1bcf1c0198ae58d378d45dbfa15045ac89a38ac,vout:0}]'
arg[ 2 ] = '{1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB:23.35}'
Tested the argument parsing using a small test program I wrote for Windows - it looks to me like that should do the trick. |
|
|
|
Are you sure such a thing is possible?
I dont see how the miner can take the change. If I sign a transaction with an input of 10 BTC and and output of 7 BTC and I dont specify a change address. Then surely the 3 BTC is lost forever. I dont see how a miner can add his own change address to a transaction signed by someone else.
It would not be possible for miners to get any fees if you had to sign an address for them to do so (which address?) so am pretty sure that this is indeed how the protocol works (input - output = miner's fees). Note that the change address is simply one of the output addresses (nothing in the protocol denotes it as being a change address). |
|
|
|
That will depend on how long the backups are kept as well. If its only a rolling 4 weeks, for example, and the logs are also truncated after 4 weeks, realistically, there's a 2 month window.
True - it very much depends upon how long backups are kept (for my own systems I have backups going back 10 years but perhaps they don't burn backups to CD-R for this forum). |
|
|
|
Thank you all for the help. I am starting to understand how it works around here.
Nothing to do with this site in particular - any Forum that uses a DB (and are there any that don't?) will always have the entire history of anything stored in the DB in the DB log (this is how DB's that support ACID tx's work). Even if the log is truncated after every backup it is common practice to backup the current log along with the DB so that if all backups have been kept then it is always possible to do a complete rebuild of the DB from an initial DB and all the backed up logs. |
|
|
|
By they, do you mean deleted posts or deleted pms or both?
I think it would most likely be both as presumably they are both stored in the DB. |
|
|
|
Key pairs are created at random and anyone can create as many as he wants. Would it theoretically be possible that someone happened to create an existing key pair that gives access to someone else's balance? Even if the probability is extremely low, wouldn't is be a matter of time for this to happen eventually?
The amount of time before finding a "birthday" is perhaps a little more than you might think (try as much time as the universe is old or thereabouts). To get an idea run vanitygen with a very long prefix and check it's estimate: C:\Program Files\Bitcoin>vanitygen 11111111111
Difficulty: 1208925819614629174706176
[180.70 Kkey/s][total 323584][Prob 0.0%][50% in 1.470452e+011y]
Now lets try adding some more 1's to this: C:\Program Files\Bitcoin>vanitygen 111111111111111
Difficulty: 5192296858534827628530500624187392
[186.16 Kkey/s][total 387328][Prob 0.0%][50% in 6.130577e+020y]
|
|
|
|
|
A public/private key pair is simply created by the appropriate maths and can very easily be verified also by maths - the purpose of CA"s has nothing to do with these low-level operations but instead is for the purpose of issuing and signing a certificate that states who the certificate belongs to and who issued it.
As Bitcoin is decentralised there is simply no need to have such authorities - when it comes to making a payment it's up to you to decide if you trust sending money to the address you are going to send it to.
BTW - welcome to the forum!
|
|
|
|
Ok I have worked out the error.
I had a few things compiling as static libraries; while fine if your code is perfect; they hide many linker errors. I changed of the projects in the solution to compile as DLLs, and cleaned up all the linker errors, (and warnings). Bang-Presto. It 'just worked'
Glad you worked it out - provided that the data and functions in any static libraries are only used by the native DLL's then it should "just work". The problem is that you probably need to define DLL function wrappers to expose anything in those static libraries that is needed by the managed interface (so you can still keep static libraries but just need to be careful with their usage). |
|
|
|
Well depending what I was compiling, the pure native parts I was compiling with no /clr (eg. otlib.dll, otapi.dll)
The Native/Managed interface, I compiled with: /clr (eg. otapicli.dll)
The Pure Managed test-app I compiled with /clr:pure (eg. ot_clr_prompt.exe)
The problem as far as I can tell is when linking the native dll's at runtime. However debugging this is very difficult.
It has been quite a while since I worked with this stuff but from memory it might be required to compile everything with at least /clr (unless using some special ugly syntax perhaps) so maybe try compiling the oltlib.dll and otapi.dll with it just to see what happens. Also perhaps this might be of some help: http://msdn.microsoft.com/en-us/library/ms235282.aspx |
|
|
|
|
Show Posts
