Bitcoin Forum
January 20, 2018, 03:35:01 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 [343] 344 345 346 347 348 349 »
6841  Economy / Economics / Re: Transaction Fees in the Deflated Economy on: July 19, 2010, 02:06:43 AM
I didn't see a cancel button there.

Couldn't a client just send a burst of small transactions in order to avoid the transaction fee? If/when 0.01 BTCs become valuable, then the charge might also be something to adjust.

There's no cancel button because the person doesn't have enough funds to pay the transaction fee.

When there are already 80 kilobytes of transactions in a block, further transactions get only 3 kilobytes of free transactions. But I don't think the current implementation actually accounts for this when sending, so transactions over 3KB would get rejected and would have to wait for the next block. In any case, the total size of all transactions is capped at either 100KB or 200KB (not sure which), and any transactions beyond that will have to wait for the next block.

It's pretty harmless to adjust transaction fee stuff, which is probably why the terms are not too well-defined right now.

I am not too familiar with the source code (just did a bit of browsing), so I could be wrong about this stuff.
6842  Economy / Exchanges / Re: New Bitcoin Exchange on: July 19, 2010, 01:14:03 AM
that's not really what I'm afraid of, but thats an issue too.

hmm, but still, in theory, it would be possible for someone with physical access to your RAM to read my password, wouldn't it ?

If an attacker had that much access, he could modify the login page to remove the password-hashing JavaScript.
6843  Economy / Economics / Re: Transaction Fees in the Deflated Economy on: July 19, 2010, 12:40:47 AM
It's based on data size. The first 60 kilobytes are free, and it's (around?) 0.01 BTC per kilobyte after that. Data size is increased when sending the transaction requires that you draw Bitcoins from many different sources.

In the image below (from someone on IRC), 0.01 BTC was sent back and forth until their balance was made mostly of these "cents". Then, when they tried to send the entire balance, 1/8th of their transaction was required as a fee because combining all of these transactions took up so much data.

Transaction fees are at line 525 in main.h.
6844  Bitcoin / Bitcoin Discussion / Re: Anonymous Altruists on: July 19, 2010, 12:29:23 AM
afaik you can get the transaction fees even if you are not generating coins at all.

Nope. You only get them when you publish a block. It's added to the 50 BTC created from nothing.
6845  Bitcoin / Development & Technical Discussion / Re: iPIG private internet gateway on: July 18, 2010, 07:26:33 PM
You can also do that for any proxy (including Tor and I2P) with Proxifier:
6846  Bitcoin / Development & Technical Discussion / Re: Divisibility Adjustment - Technical Feasibility on: July 18, 2010, 07:13:02 PM
Currently, Bitcoins are stored as a 64-bit integer. The number of Bitcoins is multiplied by 100000000 to give eight decimals of precision. Exactly where the decimal point is placed in this large number is completely up the UI, so this can be easily changed. Extending this precision (by turning it into a 128-bit integer or whatever) is possible, but all clients that did this would be incompatible with old clients. It could be changed gradually in the same way SHA-256 could be:

Quote from: satoshi
If the hash breakdown came gradually, we could transition to a new hash in an orderly way.  The software would be programmed to start using a new hash after a certain block number.  Everyone would have to upgrade by that time.  The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.
6847  Bitcoin / Development & Technical Discussion / Re: Privacy versus Safety: handling change on: July 18, 2010, 06:36:18 AM
dete: You are losing the private keys in the case. Almost every time you send coins, you're also sending some coins back to yourself, to a brand new keypair. Since this new private key is not in the backup, you lose the coins.
6848  Economy / Exchanges / Re: New Bitcoin Exchange on: July 18, 2010, 02:45:00 AM
Why would I use Mt. Gox instead of BitCoin Market?
6849  Bitcoin / Development & Technical Discussion / Re: Calculate Hash Target and Probability in PHP on: July 17, 2010, 11:41:22 PM
This is how I do probability per hash:
(The tickmarks execute the command on the shell.)

Then you do 1/$probability to get average number of hashes. Divide this by the number of hashes you're getting per second to get the number of seconds.

You can calculate the target like this:
"Difficulty" is the number returned by getDifficulty. (The huge number is the maximum target, which getDifficulty is based on.) This calculation is not exact.

I search debug.log to get the target, but the result of the last retarget seems to be less accurate than the calculation above. I'm not sure why this is. Maybe the code changed. (Edit: I now think that this is just an artifact from the "nBits" decompression.)
6850  Bitcoin / Development & Technical Discussion / Re: Post-Minting Phase and CPU Usage on: July 17, 2010, 10:46:45 PM
1)I understand that 21,000,000 coins is the maximum.  How many total blocks will this be, given the logarithmic decrease of coins/block when we hit the 21M?

Somewhere around block 5,355,000 (this will be sometime around 2111 at 6 blocks an hour.)
I expect many things will have changed by then though.

The last block that will generate coins will be block #6,929,999. Then the total number of coins in circulation will remain static at 20999999.9769.

I've created some future-proof calculators for this:
(Change 6929999 to whatever number you want, or leave it out for the current number of blocks.
6851  Bitcoin / Bitcoin Discussion / Re: Bitcoin subscriptions on: July 16, 2010, 06:44:35 PM
Try "bitcoin -?" for a list.
6852  Bitcoin / Bitcoin Discussion / Re: What does the "total ledger" of all coins look like? on: July 15, 2010, 11:31:53 PM
Could someone make a graph of all the coin values ever awarded, their path through the system, and their current holder?  Something like  but on the whole economy?

I'm going to do that. It will be a website that will allow you to see inside of blocks and trace transaction histories. I think I know how to do everything required, so you might see it somewhat soon.

What information is private?  I suppose aggregation of multiple Bitcoin Addresses (a person, for example) is inscrutable.

Yes. You can get the "top 10 most valuable BitCoin addresses", but not the "top 10 richest users"

But could someone, conceivably, state with accuracy how much money has been donated to Bitfountain's posted address?

You can see it exactly if the address doesn't change.
6853  Economy / Marketplace / Re: BitCoin Casino (Beta mode) on: July 15, 2010, 10:39:49 PM
He handles it manually.
6854  Economy / Marketplace / Re: BitCoin Casino (Beta mode) on: July 15, 2010, 10:43:51 AM
There's another page somewhere where you can add addresses, which will then appear in that list.
6855  Bitcoin / Development & Technical Discussion / Re: Hash() function not secure on: July 15, 2010, 07:37:54 AM
PKCS #5 is used by TrueCrypt (and GPG, I think). If each iteration reduced the difficulty of finding collisions, as bdonlan suggests, then TrueCrypt would be easy to break. You'd just attack the hashing algorithm to find the master key.
6856  Bitcoin / Development & Technical Discussion / Re: Hash() function not secure on: July 15, 2010, 02:42:43 AM
I have no doubt that hashing multiple times is secure, since it is specified in PKCS #5 and other standards:
An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.
6857  Bitcoin / Development & Technical Discussion / Re: Website integration for bitcoin on: July 15, 2010, 02:18:12 AM
Don't use 8080. Freenet Message System uses that port by default (on localhost), and I expect that there are a lot of FMS users here. It's also a registered port. I suggest using a port that isn't listed here.
6858  Bitcoin / Bitcoin Discussion / Re: Bitcoin depletion? on: July 15, 2010, 02:03:21 AM
If it really becomes an issue (which I really doubt), the client can be updated to support more precision. Everyone would need to update, but it should be possible to switch to the new system smoothly and gradually.
6859  Bitcoin / Development & Technical Discussion / Re: anyone tried running with VIA Padlock extensions? on: July 15, 2010, 01:55:53 AM
Is each "khash/sec" a whole attempt, or each single cycle through SHA256?

It's a whole attempt.
6860  Bitcoin / Development & Technical Discussion / Re: Hash() function not secure on: July 15, 2010, 01:45:03 AM
You're trying to solve:
SHA256(SHA256(d'))==256-bit number

This still has 256 bits of security, and you have to do two hashes per attempt to brute-force it.
Pages: « 1 ... 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 [343] 344 345 346 347 348 349 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!