Bitcoin Forum
February 23, 2020, 05:56:28 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 [375] 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 »
7481  Bitcoin / Development & Technical Discussion / Re: When to backup / What to backup on: November 24, 2010, 12:52:56 AM
How does the oldest key help in deciding when to backup? Looking for a timestamp newer than the last backup would mean that we're already running with non-backed up keys, or am I reading this wrong?

If your last backup was before "keypoololdest", you need to back up again. The time will get progressively closer to your latest backup as you use keys, and you should be able to back up in advance.
7482  Bitcoin / Bitcoin Discussion / Re: Please Read: A personal appeal from Wikipedia founder Jimmy Wales on: November 23, 2010, 08:52:45 AM
It's just me that finds silly this reluctance of the wikimedia foundation against adding some ads?

These beg banners they put end up being more annoying than a small add would be, and I don't think it's nearly as effective.

I agree. Wikimedia has plenty of potential revenue opportunities that would not compromise the project's integrity. I doubt that Wikimedia could be completely self-sufficient, but I bet it could get by without any donation drives if it was managed correctly.

I don't like the way Wikimedia is run in general. In particular, Wales should be removed from any sort of leadership position -- he has a long history of making stupid decisions and bypassing his own (poorly-designed) rules.
7483  Bitcoin / Development & Technical Discussion / Re: Bitcoin Protocol Specification on: November 23, 2010, 07:05:52 AM
Creating an IETF-ready specification would be a waste of time. The simple Bitcoin network used now is not what will be used in the future. Like Usenet or IP+BGP, different protocols will be used for generator-to-generator and generator-to-client connections. None of this is implemented yet, and no one knows how it will behave.

Bitcoin is incomplete. Getting the message format is easy compared to figuring out what something like this is supposed to mean:

Code:
// Subscription methods for the broadcast and subscription system.
// Channel numbers are message numbers, i.e. MSG_TABLE and MSG_PRODUCT.
//
// The subscription system uses a meet-in-the-middle strategy.
// With 100,000 nodes, if senders broadcast to 1000 random nodes and receivers
// subscribe to 1000 random nodes, 99.995% (1 - 0.99^1000) of messages will get through.

Guess what doesn't exist in the code? "Product" and "Table" appear nowhere in this sense. Subscriptions are only mentioned a few more times. This "broadcast and subscription system", whatever it is, is some feature that currently only exists in Satoshi's head. There are several other examples of this kind of thing in the code.

Describing how the system currently works in detail would be very useful, but there is no chance that a "specification" will still be complete in a year from now.
7484  Bitcoin / Development & Technical Discussion / Re: determine valid bitcoin address on: November 23, 2010, 02:39:24 AM
This topic contains an explanation of why is undesirable to use such functions:
https://www.bitcoin.org/smf/index.php?topic=1267.msg13897

If something changes in Bitcoin, then all old Bitcoin clients will also screw up. My PHP code checks the address version number in the same way as Bitcoin, so it should be future-proof.
7485  Bitcoin / Bitcoin Discussion / Re: Provocation to upgrade software on: November 23, 2010, 02:16:26 AM
Do the block-generator or transaction-creator record client version in the block?  I see "ver": 1 fields in the raw json of BBE, but what is connected to this?  Is the range of values limited?  (Sorry, I will read the code One DayTM.)

Blocks and transactions have version numbers in them. These are distinct from the client version number, and have always (AFAIK) been 1. Client versions are not included in the chain, but they are communicated to network peers. Version is a signed integer, so the limit is about two million.

There is already a network alert facility. If Satoshi broadcasts a signed message to the network, text will display in all Bitcoin clients of the specified version. Alerts can also disable the JSON-RPC interface, shutting down all sites that rely on Bitcoin until the network becomes safe. A more decentralized scheme would be a good idea in the future, but it's not needed now.
7486  Bitcoin / Bitcoin Discussion / Re: What will keep transaction fees up? on: November 22, 2010, 08:03:12 PM
Are you sure?

Yes. The data covered by the hash includes the Merkle root, which is (basically) a hash of all of the transactions in your block. Adding a transaction changes the Merkle root, which changes the header, which makes you hash invalid.

People might very well hold their generation power until after some high-fee transactions have accumulated, but they'll have to start from scratch.
7487  Bitcoin / Bitcoin Discussion / Re: What will keep transaction fees up? on: November 22, 2010, 04:08:49 PM
The network will evolve into a big game of ‘transaction fee hash chicken’ where a few (or a single) generators will have found a valid hash before the time they announce it.  They will keep it secret until a certain amount of transaction fees has accumulated, at that point they will announce it.

Adding transactions invalidates your block hash.
7488  Bitcoin / Development & Technical Discussion / Re: Test network support broken? on: November 22, 2010, 06:15:08 AM
Try it with an explicit -conf=file switch.
7489  Economy / Marketplace / Re: bitcoins 4 cash on: November 22, 2010, 05:17:18 AM
You need to be using I2P to send mail directly to mail.i2p. Otherwise you need to use a mail gateway, as nanotube suggested.
7490  Bitcoin / Development & Technical Discussion / Re: Block size limit automatic adjustment on: November 22, 2010, 05:02:37 AM
Not many transactions were lost, as the warning messages were sent out that it was a problem at the time.

IIRC, the legitimate chain overtook the "contaminated" chain within the 100-block maturation time, so all transactions were ported to the new chain (except for the illegal ones).

Chain forks are not inherently bad. If the network disagrees about a policy, then a split is good. The better policy will win. If block forks start happening a lot, it would be simple to consider a transaction unconfirmed if it relies on a generation that isn't 500 blocks deep or whatever.
7491  Economy / Marketplace / Re: Hippch's Download Site on: November 21, 2010, 09:46:29 PM
Just accept 0 confirmations and run Bitcoin with -maxconnections=50. It's not a lot of money, and attacks against this are difficult.
7492  Bitcoin / Development & Technical Discussion / Re: URI-scheme for bitcoin on: November 21, 2010, 06:25:31 PM
Did I miss something?

http://pastebin.com/VsBbmXQx
7493  Bitcoin / Development & Technical Discussion / Re: determine valid bitcoin address on: November 21, 2010, 06:09:43 PM
Thanks for this, but checkAddress() appears to be broken for some addresses:

Those are all correct. Nothing can tell you whether someone actually owns an address. It simply checks that the address is in the correct form and contains a valid checksum.

Try to send bitcoins to any of the addresses you listed. Bitcoin will either prevent you from doing so if checkAddress() is false, or it will show a green checkmark if checkAddress() is true.

Quote
1MU97wyf7msCVdaapneW2dW1uXP7oEQsFA  bool(false) ** Actually valid **

I just tested this and checkAddress() returned true. Maybe you had some spaces or something: it does no "cleanup" at all.
7494  Bitcoin / Bitcoin Discussion / Re: Address used for receiving the generated Bitcoin? on: November 21, 2010, 06:42:28 AM
ah, theymos, you're here - so what about the key pool? will the 'looking at wallet backup' thing work?

Yes. It's good for 100 generations (and you can use the -keypool switch to increase this). I think an auto-send script would be easier, though.

Also, I think there may be some cases where a keypool address would be thrown away without a generation (like if Bitcoin crashes, or maybe even when it shuts down).
7495  Bitcoin / Bitcoin Discussion / Re: Address used for receiving the generated Bitcoin? on: November 21, 2010, 06:35:35 AM
Should any Bitcoin be generated for it, will the address that the Bitcoin is sent to be the address that was initially generated for the client?

No. Each generation has a unique address created for it. This address is not shown in any Bitcoin interface.

You could make a script that sends all generated coins to some address, such as this one:
http://bitcointalk.org/index.php?topic=1431.0
7496  Bitcoin / Development & Technical Discussion / Re: Block size limit automatic adjustment on: November 21, 2010, 04:49:11 AM
Generators must bear whatever the network demands. If we ever reach a "professional" level of hundreds of transactions per minute, generators will have to bear that.

If no generators are capable of storing the 10TB block chain or whatever, then there will be no generators and Bitcoin will die. Limit adjustments won't make the chain smaller once it has already grown to a gigantic size.

Quote
You do realize that if this limit is a constant, it will be really hard to change it when needed, right?

It will not be hard to change. It will cause a certain amount of disruption, but it's not difficult. A certain group will change, and the change will either catch on with everyone else or the people changing will realize their new coins are becoming worthless and change back.
7497  Bitcoin / Development & Technical Discussion / Re: Block size limit automatic adjustment on: November 21, 2010, 01:18:52 AM
The main reason for the block size limit is disk space. At 1MB, an attacker can force every generator to permanently store 53GB per year. At 10MB, an attacker can force every generator to permanently store 526GB per year. Even a small change in block size makes a big difference on the load that generators must bear. It must not be changed until the network is ready for it, and this time can not be predicted reliably.

If the block size limit is too high, an attacker can destroy the network by making it impossible for anyone to be a generator. If the block size is too low, fees get higher until the problem is fixed. Automatic adjustments would still carry the risk of adjusting to a limit that is too low.
7498  Bitcoin / Bitcoin Discussion / Re: What will keep transaction fees up? on: November 21, 2010, 12:24:34 AM
Are you sure? Given any difficulty, you still have to crunch the numbers to solve a block. The more transactions, the more numbers to crunch, thus the longer it takes to compute a given hash.

Block hashes are only hashes of the fixed-size 80 byte block header, which contains a hash of the transactions. Transactions only have a small one-time CPU cost for adding.
7499  Bitcoin / Development & Technical Discussion / Re: Looking at Three Systems (poor hash rates on a Xeon) on: November 20, 2010, 09:52:22 PM
It sounds like you actually only have two physical cores, and you're including the virtual hyper-threading cores. This has different effects on different architectures.
7500  Bitcoin / Development & Technical Discussion / Re: Potential vulnerability of hash function? on: November 20, 2010, 07:16:14 PM
In a worst-case situation, would the whole chain have to be restarted with a new genesis block, or do you think some algorithm from some arbitrary block number, say block 200000, would require the new hashing/cryptographically securing algorithm?

The chain will never be restarted.

SHA-256 is very strong.  It's not like the incremental step from MD5 to SHA1.  It can last several decades unless there's some massive breakthrough attack.

If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.

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.
Pages: « 1 ... 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 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 [375] 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 »
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!