Again, I propose to change OP from POST FORMAT: YYYY-MM-DD SITE - HEADLINE to POST FORMAT: [YYYY-MM-DD] SITE - HEADLINE.
OR people just follow the format already established. Easier and backwards compatible. Likewise many of these articles are not "notable". |
|
|
|
Just a cursory look, without testing, but it looks like it is wide open to SQL injection in many spots for one thing. Fullphp code is given in blockchain only
$real_secret = 'ZzsMLGKe162CfA5EcG6j'
$invoice_id = $_GET['invoice_id']; //invoice_id is past back to the callback URL
$transaction_hash = $_GET['transaction_hash'];
$input_transaction_hash = $_GET['input_transaction_hash'];
$input_address = $_GET['input_address'];
$value_in_satoshi = $_GET['value'];
$value_in_btc = $value_in_satoshi / 100000000;
//Commented out to test, uncomment when live
if ($_GET['test'] == true) {
return;
}
try {
//create or open the database
$database = new SQLiteDatabase('db.sqlite', 0666, $error);
} catch(Exception $e) {
die($error);
}
//Add the invoice to the database
$query = "insert INTO invoice_payments (invoice_id, transaction_hash, value) values($invoice_id, '$transaction_hash', $value_in_btc)";
if($database->queryExec($query, $error)) {
echo "*ok*";
}
//Select the amount paid into an invoice with select SUM(value) as value from invoice_payments where invoice_id = $invoice_id
Lol please tell me where this script is live ;-) Looks like you can steal all BTC from them ;-) It is great if u please explain the catch. The $real_secret is not checked in this code. How do u overcome that verification ? |
|
|
|
HAHA stupid apple.
Old news, but did you even read the article? Obviously not since it was a B of A issue. Why let facts get in the way of bashing Apple. |
|
|
|
|
Treating an exchange as a bank is a bad idea. If you don't have the keys, you don't own the coins and are merely a debtor.
|
|
|
|
but they are not successfully adopted by mass. I believe why Apple picks up this again and repackages it to its specially designed hardware is that they see this as an great opportunity. I agree. Like with MP3 players, phones etc. And it does offer value in terms of protected card numbers, having to carry fewer cards, ease of use etc. |
|
|
|
I glanced over the paper and have a couple of perhaps naive questions:
1. As bitcoin has economic value, I don't quite understand how this would work with sidechains. Suppose I transfer 1000BTC to a sidechain, but whatever changes i make will result in a loss of purchasing power of the "new bitcoin" in my sidechain. However, since I have a two way peg, i would be able to transfer my "new bitcoin" back to parental bitcoin chain at the 1:1 ratio?
2. Alternatively, if my "new bitcoin" chain will be successful, then bitcoins will 'evaporate' from the parental chain toward my chain, but it is intuitively unfair that initial coins in the "new bitcoin" will have the same value as latecomers 'new bitcoins' that will 'evaporate' later from the parental bitcoin. If no equal value, then how that difference in value would be determined?
3. Will parental bitcoins acquire more and more value as sidechains accumulate or will they lose value toward zero as value is transferred to sidechains?
4. I think that authors might need to introduce some value "entanglement" between 'locked' bitcoins (that moved to sidechains) and the rest of bitcoins in the parental chain. This way, if sidechains acquire additional value this value will be reflected in "non-locked" parental bitcoins, otherwise parental bitcoins will be unaffected by sidechains growth and will eventually lose value.
Because coins can always be transferred between chains, the value will be roughly equal. The value cannot be equal if the properties are different because one coin/sidechain will be more attractive than another, and this is exactly the point I am making. Alternatively, if a sidechain becomes more attractive than a parental blockchain and no direct value is assigned to this (and by definition to the remaining old blockchain bitcoin), essentially ALL bitcoins will migrate/diffuse to this more attractive sidechain. Are economic considerations have to place in bitcoin development? This would be surprising all things considered. Have you read the paper? The coins can be transferred between chains at essentially no cost so, as go1111111 says, any differences can/will be arbitraged out. If you could buy Bitcoin and BitcoinSidechain for different amounts of fiat you'd do so. Regarding your #2, I don't see anything intuitively unfair about it since the two chains are both limited to the same equivalent number of bitcoins outstanding. Eg. Whether your 1000 BTC are on the main chain or the side chain, no one can increase the number of coins available. :-) |
|
|
|
There are a lot of positive discussion about sidechain technology recently. It wil incorporate other innovated altcoins' features into bitcoin, which will enhance the usability of bitcoin and kill the existence of altcoin. I am eager to know how it will play out.
Which features of altcoins will be incorporated? I am curious to find out. Some examples are discussed in the paper, but things like fixing transaction malleability, improved privacy, scripting extensions, peer-to-peer markets etc. |
|
|
|
|
If you don't have the keys, you are probably out of luck. Like if you burn some paper money, there will be no getting it back.
|
|
|
|
|
Scan the QR code on the top one and see what is there.
|
|
|
|
|
I believe that pywallet should be able to do it with its "--dumpwallet" command. That should dump the wallet.
If you do a
keypoolrefill 1000
and it returns blank, that indicates it was successful. To me it should return a success message, perhaps with a count returned, but that is just me.
|
|
|
|
This command: bitcoin-qt -keypool=1000 Is if you are running Bitcoin from the command line (e.g. Terminal in OS x, or a shell in Linux). You can edit the config file to increase it, see: https://en.bitcoin.it/wiki/Running_BitcoinYou can see the OS x directory and file you need to edit with the keypool=1000 command. In the wiki the example shows: #keypool=100 which means it is commented out. You can edit it to say: keypool=1000 Thanks, I went into the OS X Terminal and typed in bitcoin-qt -keypool=1000 but it returned the error message "command not found". I don't feel comfortable creating & editing a config file. Would love to be able to just use the terminal command, but there seems to be no instructions anywhere on how to actually use these terminal commands. (LOL. And we wonder why "normal people" don't use Bitcoin yet. This is so many years away from being easy enough for the mainstream populace!  ) I agree about ease of use issues. Something like this in Terminal (I'll be by a Mac tomorrow but I think I got it): Code: ./Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -keypool=1000 This is just the path to the applications folder and then to the binary runtime (the actual program) inside the application bundle. This will launch Bitcoin, so you want to quit it prior to this command. |
|
|
|
This command: bitcoin-qt -keypool=1000 Is if you are running Bitcoin from the command line (e.g. Terminal in OS x, or a shell in Linux). You can edit the config file to increase it, see: https://en.bitcoin.it/wiki/Running_BitcoinYou can see the OS x directory and file you need to edit with the keypool=1000 command. In the wiki the example shows: #keypool=100 which means it is commented out. You can edit it to say: keypool=1000 |
|
|
|
Lite wallets are bitcoin. You can send or receive coins. I can't tell if you are just trolling or not, but saying that "they" aren't getting something right because you don't have enough memory when running under 32 bit is like asking why you can't do 2014 3D rendering, good speech recognition, and 60 fps games using an 8080 or a 6502 microprocessor with 48K of memory. By the way, the code is open source, so if you have a solution that will let it sync well on 32 bit systems, it would be more than welcome. Lol, the whole point of bitcoin is to use bitcoin.. the rest in my opinion, are un-necessary third party apps.. why cant they just get sumat right for once..
Like apple used to..
|
|
|
|
Nowayhozy am I upgrading to x64, or any other bloatware, like win 7, 8, 9, 10, whatever, I'm fed up updating only to find my pc does more for others than it does for me, too many 'service's that do nothing but require mre updates..
I did post the last log, just uninstalled bitcoin after realising it really is a waste of time and energy, and since it's safe to assume bitcoin devs will kill xp supoort too, then fort me, I'll just wait till they make a bitcoin app so good, it wont need updated, cause it will simply work! - Okay I do dream a bit lol.. thanks for your help, but I reckon it's the app, in particular:
File: ../..src/allocators.h, Line 41
Cause I got that error from the last 3 versions..
Never happened before..
Pc is runnin like a dream..
Based on the error, the odds are you are running out of memory which is something that has been known to occur on 32 bit systems during the initial sync. Just use a different wallet, like multibit (for example) |
|
|
|
-snip-
But yeah, you'll have to have a working and synced core wallet to export the keys and import them into multibit.
No! Exporting private keys works without syncing. -snip-
In this case, yes, those may not be issues.
But ALL have been issues this year making it non trivial to install for a non tech person. Most people would just say screw it. Look at the issues for 32 bit versions and the initial sync running out of RAM, look at all the tech support threads, depending on the platform, and all the various suggestions people have, some of which I mentioned above.
Obviously I can say, if you exclude app nap because it is Mac, or you can exclude 32 bit issues because it is Windows, then you can say it is easy because you just exclude all the machines with issues. Anyway, thin clients are best for these types of users right now, imo. Bitcoin Core is resource intensive now, more so than the past, and will only get more so.
Somehow I aggree with both (Newar) of you. On the one hand you have the people that have no problem setting up bitcoin core or endure/solve the problems when they arise and on the other hand you have the people that have problems and maybe should just use another wallet. Satoshi predicted that not everyone would be running a full node in the future. Maybe this time is now, maybe we are allready at a stage where only "nerds" or tech savvy individuals run full nodes besides the big companies and miners. I agree. Not everyone will run full nodes, the more techy the person is, the more likely they will. I just know my aunt or grandmother would not try. They'd call me and try to get me to do it over the phone or via screen sharing/VNC or just switch to something that is easy to set up. Most people want to use bitcoin for <whatever>, not run a node. That is the nature of how growth goes. :-) |
|
|
|
NEED HELP!
I cant download the wallet
why does it always " out of sync " and when i place my cursor on the signal (botom right) it says "0 active connection to hyperstake network"?
what should i do? my network is fine btw.
thanks so much guyss
It sounds like this is for an alt-coin (hyper stake), so you might ask in the alt section, but it just means that it hasn't found any peers to connect to as of that point. |
|
|
|
Of course it's trivial, it just needs time. From my observation, the "fresher" the blocks are the slower it gets. CPU will spike because it's validating the blocks. It's not just about downloading.
So if you have tried the torrent, tweaks like the connect= command etc., all you can do is wait.
In return you will know that the blockchain on your harddisk is *the* blockchain and don't have to rely on a 3rd party as you do with thin clients. Worth something, IMHO.
I think all the tips about using the torrent, 32 vs 64 bit, questions about RAM, App Nap, slow vs fast peers, bandwidth, RAM, etc make it no longer trivial. Trivial is something my Aunt or grandmother could do. Download, double-click, done. [...] Well, that is the case. 32 vs. 64 is no issue. RAM is no issue. App nap is a Mac specific thing. Peers is no issue. Bandwith is no issue. All you need to add to your list is: wait. In this case, yes, those may not be issues. But ALL have been issues this year making it non trivial to install for a non tech person. Most people would just say screw it. Look at the issues for 32 bit versions and the initial sync running out of RAM, look at all the tech support threads, depending on the platform, and all the various suggestions people have, some of which I mentioned above. Obviously I can say, if you exclude app nap because it is Mac, or you can exclude 32 bit issues because it is Windows, then you can say it is easy because you just exclude all the machines with issues. Anyway, thin clients are best for these types of users right now, imo. Bitcoin Core is resource intensive now, more so than the past, and will only get more so. |
|
|
|
|
Offline, cold storage for the majority of your funds. There are a lot of discussions about how to best do this.
|
|
|
|
Of course it's trivial, it just needs time. From my observation, the "fresher" the blocks are the slower it gets. CPU will spike because it's validating the blocks. It's not just about downloading.
So if you have tried the torrent, tweaks like the connect= command etc., all you can do is wait.
In return you will know that the blockchain on your harddisk is *the* blockchain and don't have to rely on a 3rd party as you do with thin clients. Worth something, IMHO.
I think all the tips about using the torrent, 32 vs 64 bit, questions about RAM, App Nap, slow vs fast peers, bandwidth, RAM, etc make it no longer trivial. Trivial is something my Aunt or grandmother could do. Download, double-click, done. Not to say it is hard for the technically inclined, but definitely not trivially easy. Back in 2010 and 2011 it was very fast to start up and to be caught up to the current chain and a lot less resource intensive. Edit: btw, this is not a criticism of Bitcoin, just a statement of facts. |
|
|
|
|
Show Posts
