|
The tx hash is a large proportion of the size of the tx itself, and many tx must be gathered from far and wide to assemble a single block for initial verification. Why not split up storage by block hashes?
|
|
|
|
|
bitcoind has some unit tests that are exactly what you want; you could copy one, put in your own values, and run it as a bitcoind test. You could do it with openssl but you'd probably need to convert the pubkey into an openssl-compatible format somehow.
|
|
|
|
Yes, you can do it with openssl. Command line example: openssl ecparam -out ec_key.pem -name secp256k1 -genkey
openssl req -new -key ec_key.pem -x509 -nodes -days 365 -out cert.pem
|
|
|
|
double spend ATTEMPTS have happened. but show me the actual tx's of a successful double spend (injection of fresh coins that were not mined)
That's not what double-spending is. Successful double spends happen, usually against people who accept 0- or 1-confirmation transactions in situations where they have no recourse. The solution is not to do that. |
|
|
|
Question: Would the following scenario be practical under real-world usage?
Let's say that you were to render your initial stenographed image as a BMP. Then let's say that you compress both the original image and the stenographed image into an identically compressed JPG setting (i.e. 90% JPG compression), and then proceed to upload both to the Internet Archive (does not manipulate / reformat images in any manner whatsoever).
Would the above scenario even be practical? The basic idea here, is to obfuscate the stenographed image enough to make detection at least a bit more difficult.
Naturally, each oth the two images would be stored on separate and unique Archive pages.
Not remotely. Steganographed data is put into the lowest order bits of the image. JPEG compression is lossy. When you convert BMP->JPEG->BMP, the resulting image will not have the same low order bits as the inputs. |
|
|
|
will people stop thinking that miners NEED fee's
25btc is more then enough to share between them every 10 minutes
if they decide to sell it at a low buy price instantly, that is their fault. we do not need to subsidise them like the givernment sbsidises farmers, purely to make rich corporations richer.
fee's should have only been an issue to be added in a couple decades time. not for the last 5 years and not for any year soon.
i propose miners stop being greedy asking for more money, and instead hoard what they have until bitcoin price rises to the value they want,. they should not sell instantly at a low price and then cry that its not profitable, and then blame the community for not giving them a subsidy..
seriously people the fee's are a greedy bonus. they do not help the community, it does not help with the whole "micro payment" ethos that bit coin had. nor the "free transactions" that bitcoin had.
bit coin fundamentals are being diluted or eventually disappearing completely due to greed
i am not going to be able to buy a 50c chewing gum at a vending machine if im being charged 5c..
yes the fee is not as noticable for large transactions.. but that then makes bitcoin a payment system "only for the rich"
i hope people realise that bitcoin is loosing its main concept and usefulness slowly each day.
take the core-QT. it no longer allows you to simply copy and paste a already known address to hand out to people. Luke Jr wants people to keep editing their donations button to be new addresses per use. hense why this feature is in the core-qt.
yes great for merchants to audit transactions.. but not for average joe.
You don't seem to have considered the economics of mining at all. With current rewards and fees, the orphan risk of including a transaction in a block far outweighs the fee, so we're relying on miners including transactions in blocks out of altruism. Some miners don't include any transactions in their blocks, and they make slightly more money on average. Paying no fees at all would further incentivize such behavior, jeopardizing the survival of the entire economy. |
|
|
|
Does this sound correct? Bought something on TigerDirect.com with Bitcoin - $86.88 Was expected to pay a miner fee by Bitcoin QT. Worked out to $0.05 So I had to pay 5 cents fee on an $87 purchase. Should we stop saying Bitcoin is free? I mean ...  I know - beating a dead horse, but every time I have to pay, I ask myself why I tell people its free. It's not free. It's not intended to be free. You are correct in questioning your motives for making that claim. Still, $0.05 is a lot less than fees for paying with any credit card; it's just more obvious because they payer includes the fee rather than the payee quietly pricing it in. Set your computer to mine; run low priority in the background. Download the client and use your own PC to relay the transaction. It's free for those who support the network by mining. Non miners support the network with a small fee. Obviously your power cost is a factor, but it will likely average out for you if you just run a low priority process.
Google how to do it all if you aren't sure. The info is there.
This is terrible advice and would not help your situation in any way. Pay no attention to this idiot. |
|
|
|
|
You have some shitty domain name so you're trying to figure out what kind of business to start around it? >_<
|
|
|
|
|
bitcoind's built-in cpu miner uses pay-to-pubkey; external mining software can choose its own transaction type.
|
|
|
|
|
Originally, pay-to-pubkey was the standard transaction type. The main benefit of using pay-to-pubkeyhash is that it allows for much shorter addresses (since a RIPEMD160 is much shorter than a pubkey); other than that it takes slightly more time and space than pay-to-pubkey. When mining, you don't need to share the address you're mining to except in the coinbase transaction itself, so there's no reason not to keep doing it the slightly simpler way.
The only benefit I can think of to mining to a pay-to-pubkeyhash is the theoretical situation where a serious vulnerability in secp256k1 has been found; receiving via pay-to-pubkeyhash doesn't reveal your pubkey until you're in the act of spending from that address, and allows less opportunity for someone to crack your key. Of course, no one expects that to happen any time soon.
|
|
|
|
DarkCoin's system for mixing transactions is CoinJoin, just like Bitcoin's system for mixing transactions. There's no special support for it in the DarkCoin core, it's just a rebranded Litecoin with different mining properties.
Incorrect. Darkcoin uses blake, bmw, groestl, jh, keccak, skein, luffa, cubehash, shavite, simd and echo. If you'll note, none of these are Sha-256 with salsa mixing. Stop spreading disinformation. Additionally, the efficient algorithms offer much higher stability in GPU cores . . leading to great decreases in power usage. The difficulty retargeting is regulated by KGW. The block generation time is similar. The block reward is dependent on the difficulty. The capability of CPU mining vs. GPU mining is one of the best I've ever seen with an R9 290 only pulling 10 times the hash of a core i7. Pretty much the only thing in this coin that is shared with Litecoin is the wallet interface, which was brought into Litecoin from Bitcoin. Darkcoin and Litecoin are altcoins, but Darkcoin is not a Litecoin. You're talking about the different mining properties, which I mentioned in the post that you quoted. It was pretty short, so it might be worth another shot at reading. The ONLY differences between DarkCoin and Litecoin are branding and mining. Neither has anything to do with mixing, which is what we're talking about in this thread. DarkSend is CoinJoin. Bitcoin has CoinJoin too. No. What you're saying to me is like saying that there is no difference between the Euro and the Dollar . . besides the fact that one has American presidents or high standing political figures, and is backed by the American economy . . while the Euro is backed by multiple nations and has pictures of European locations on them. Your argument is completely illogical and fallacious, in that you are effectively saying that these coins are the exact same except for everything that goes into them. It's this same reasoning that is leading you to believe that DarkSend is the same thing that CoinJoin is . . when it's really not. If there's no difference between a Euro and a Dollar . . then why can't I walk into a Walmart in Northern USA and thrown down some Euros and walk out with some bread? Sure I can buy bread with both a Euro and a Dollar . . but these fundamental differences keep them completely different. By boiling it down to "they're both money," you're limiting your point of view to that of a child. I never said there was no difference between DarkCoin and Litecoin. I'm saying that its mining algorithm is not related to the DarkSend functionality. Have you read the DarkCoin source code? There are no changes relating to DarkSend. DarkSend is a layer on top of the core software, and could be run on top of any other currency just as easily, because it is a CoinJoin implementation. |
|
|
|
DarkCoin's system for mixing transactions is CoinJoin, just like Bitcoin's system for mixing transactions. There's no special support for it in the DarkCoin core, it's just a rebranded Litecoin with different mining properties.
Incorrect. Darkcoin uses blake, bmw, groestl, jh, keccak, skein, luffa, cubehash, shavite, simd and echo. If you'll note, none of these are Sha-256 with salsa mixing. Stop spreading disinformation. Additionally, the efficient algorithms offer much higher stability in GPU cores . . leading to great decreases in power usage. The difficulty retargeting is regulated by KGW. The block generation time is similar. The block reward is dependent on the difficulty. The capability of CPU mining vs. GPU mining is one of the best I've ever seen with an R9 290 only pulling 10 times the hash of a core i7. Pretty much the only thing in this coin that is shared with Litecoin is the wallet interface, which was brought into Litecoin from Bitcoin. Darkcoin and Litecoin are altcoins, but Darkcoin is not a Litecoin. You're talking about the different mining properties, which I mentioned in the post that you quoted. It was pretty short, so it might be worth another shot at reading. The ONLY differences between DarkCoin and Litecoin are branding and mining. Neither has anything to do with mixing, which is what we're talking about in this thread. DarkSend is CoinJoin. Bitcoin has CoinJoin too. |
|
|
|
|
DarkCoin's system for mixing transactions is CoinJoin, just like Bitcoin's system for mixing transactions. There's no special support for it in the DarkCoin core, it's just a rebranded Litecoin with different mining properties.
|
|
|
|
What do you mean?
It is difficult to write software that is suitable for handling money, especially when it's other peoples' and your software is online for anyone to interact with. Your current programming knowledge is not up to the task. You can solve some problems like the one you posted by asking people to help you with them, but though you may end up with something that "runs" you can't write secure software without really knowing what you're doing. |
|
|
|
|
That was changed in a Feb 21 git commit (595b6d8); in the next release the maximum pubkey size will be 65. (Pubkeys are exactly 33 or 65 bytes, depending on whether they're "compressed").
|
|
|
|
I don't get it yet... Its like this -> I some kind of game using bitcoins, but how do i know if the player has payd let's say 0.0001BTC, Player doesn't do LOGIN, just select diff and play, BUT to been able to play, he need to pay a low amout of 0.0001BTC.... How do i know (my system, PHP only..) if he has payed... Thx4All till now! Some thing that i see on here -> https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC)Oh and one more thing.. not right..assume this -> <?php $RoundValue = 0.12345678; echo 'BTC 0,12345678 = "' .round($RoundValue * 1e8).'"'; ?> THIS WILL TURNS OUT TO BE BTC 0,12345678 = "12345678" That just not right! and without that " round($RoundValue * 1e8) " Its goes all FINE, the way is mean to be...or i forgetting something really bad ..? So..What the hell? Please don't write software that handles money. |
|
|
|
|
I wouldn't know how to check, haven't used gox since the 2011 fiasco. It seems like the only way this could have happened though.
|
|
|
|
If you visit btc-e.com, you will be presented with a diagram of why that's not going to help here. Browser <===> cloudflare < X > btc-e Downforeveryone reports "up" because it can get to a server, but the server is clouflare and it's serving an error message, because btc-e is in fact down. |
|
|
|
[Change from an unconfirmed transaction is available for immediate spend]
It looks like it's going to be necessary to wait for confirmations on your own change from now on. This is a big deal. If I understand correctly, an entire wallet balance will be unusable until a small outgoing transaction is confirmed? No it means the entire balance of the change address is unusable until confirmed. The whole wallet balance would only be unusable until confirmed if you only had a coin balance in one address (the change address). Multibit has always been like this because change was always sent back to the sending address. It hasn't done Multibit's popularity any harm. Actually, it's not the balance of the address that would be locked up, but of the specific UTXOs draw from to build the transaction. The addresses the change outputs are sent to have no bearing on what UTXOs are available. |
|
|
|
|
Your time would be better spent studying basic math. Failing to find an implementation isn't going to teach you any of the things you're missing here.
|
|
|
|
|
Show Posts
