Bitcoin Forum
May 26, 2018, 03:02:11 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
  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 350 351 352 353 354 355 356 357 »
6841  Bitcoin / Development & Technical Discussion / Re: Version 0.3.13 on: October 02, 2010, 10:43:29 PM
Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him "unconfirmable" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature.
6842  Bitcoin / Bitcoin Discussion / Re: How to overthrow the GPU Oligarchs on: October 02, 2010, 06:11:11 AM
Can you tell more about it:
"they have to do weird things with extraNonce, which increases the size of the block header".

When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception. After every hash attempt, you increment the Nonce header field, but since this field is only 32 bytes long, it overflows a lot. Whenever it overflows, you increment the variable-size extraNonce field. The larger extraNonce gets, the slower generating will get. It doesn't get significantly large with normal incrementing, though.

If you have a lot of computers and they're all working on the same block with the same public key, then they're all very likely to be hashing the same block at the same time, which is pointless. To fix this, each computer is given a unique extraNonce modifier value. This might be very large to prevent collisions, and it therefore slows down hashing.

Undoubtedly you could design a pooling system without this flaw, but it'd be more difficult.

I see that m0mchil's getwork is doing something with extraNonce. I don't know how bad that implementation is, but it theoretically must be slower than a client without it (all things being equal; clearly adding GPU support will improve performance).
6843  Bitcoin / Bitcoin Discussion / Re: How to overthrow the GPU Oligarchs on: October 02, 2010, 05:01:04 AM
Pools offer the advantage that nodes can co-ordinate their hashing so that they aren't generating the same hashes as each other. It's not about "total hash/s", it's about "total unique hash/s". If everyone in the pool is assigned a subset of all hashes to work on (sizes based on each nodes average hash/s), then we'll guarantee that no hashes will be repeated.

This is already guaranteed because everyone has a unique public key in their block. You reminded me of another way that pools are bad, though: since everyone uses the same public key, they have to do weird things with extraNonce, which increases the size of the block header and makes generating more difficult for them.
6844  Bitcoin / Development & Technical Discussion / Re: Printing bitcoins : could it work? on: October 02, 2010, 04:59:21 AM
Might work for major transactions, but can you see yourself doing this in the checkout line at Kroger?

People already use PIN entry screens for debit cards, which is pretty much the same.
6845  Bitcoin / Development & Technical Discussion / Re: Printing bitcoins : could it work? on: October 02, 2010, 02:19:09 AM
You could print out the public/private keys, but send your coins to that key with a special transaction that also requires a password to claim (done securely with the hash functions and a salt). Then tell the recipient the password orally. An attacker needs to both hear the password component and scan the key component.

You wouldn't want to use just a password because your transaction would then be vulnerable to MITM attacks.
6846  Bitcoin / Bitcoin Discussion / Re: How to overthrow the GPU Oligarchs on: October 01, 2010, 05:45:40 PM
Generation will be less and less interesting in that way, as the coins per block will divide by 2 until there's no coins generated at all, and the system will need to be run by "volunteers", which aren't really volunteers because if no block is generated no coins can be transfered, thus removing all value from all coins...

The companies can raise fees if generations aren't enough to profit.

Every calculation can be made more efficient in hardware. Trying to prevent it is pointless. It'd be a lot like making effective DRM.
6847  Bitcoin / Bitcoin Discussion / Re: How to overthrow the GPU Oligarchs on: October 01, 2010, 04:22:59 PM
Pools won't eliminate the "problem" because pools are not more profitable than normal generation; they just pay out more often. They can't beat companies that have invested in specialized hardware. They also delegate all of the important network decisions to the pool maintainer, so there's no security benefit.
6848  Bitcoin / Bitcoin Discussion / Re: How to overthrow the GPU Oligarchs on: October 01, 2010, 04:12:31 PM
I'll be glad to stop posting code, buy some serious hw and just do the generation myself. As difficulty goes up and people stop generating, this gets more and more statistically interesting... you say I should, right?

The network will eventually be run by "oligarchs". Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won't be able to keep up.

Posting GPU code now will just prolong the period when generation is feasible for normal people. This will attract a few users, and it might increase the network's total power on the short-term, but on the long-term it'll have little value. If I were you, I'd keep the code private. Publishing it wouldn't be bad for the network, though.
6849  Bitcoin / Development & Technical Discussion / Re: BitTrust coins ? Is is possible to make a P2P trust system like bitcoin ? on: October 01, 2010, 03:41:57 PM
You could build an anonymous trust system by combining some aspects of BitCoin with a web of trust. In this system, anyone would be able to send as many "trust coins" as they want to other identities, but how many of these transactions you view as valid would depend on who you trust in the network. You might say that certain identities can send unlimited coins, while others can send up to 50. No identity would have an objective balance -- the balance would be determined entirely by how you process the public list of transactions.

Example:
-You know Identity A personally, so you allow him to send unlimited trust coins.
-He buys a CD from Identity B. Since it went OK, A sends B 100 trust coins.
-Randomly and over a long period of time, B sends these coins to addresses he controls. It is impossible for an observer to know whether any of these transactions were to real people or not, so B has plausible deniability. (This is clearly more secure if there are more real people between B and you, though.)
-B wants to sell you heroin online. To prove his legitimacy, he tells you one of his anonymized trust addresses. When you enter it into your software, you see that he has a number of trust coins, somehow gotten from your trusted peers (possibly in a very indirect way, but directly in this case).
6850  Bitcoin / Bitcoin Discussion / Re: How to overthrow the GPU Oligarchs on: October 01, 2010, 03:30:19 PM
But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.

The average user no longer has a fighting chance and has given up generating blocks altogether.

It's always been the plan for block generation to not be profitable for most people. It's supposed to be done mainly by dedicated "backbone" entities. What's stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network's integrity, or five businesses producing the same Gh/s that will fail if they or someone else destabilizes the network?

I'm not saying that GPU code shouldn't be made, but it's not fair to say that GPU generators are "taking without giving back". People dedicated to generating deserve a head-start on new technologies.
6851  Bitcoin / Bitcoin Discussion / Re: Prioritized transactions, and tx fees on: October 01, 2010, 01:38:39 AM
Maybe we can scale the block limit, like we scale the difficulty?

Compute average block size over past two weeks, and don't accept blocks over AVG_SIZE*100 ?


That would force large block sizes on people who can't handle them. MAX_BLOCK_SIZE can be carefully increased if it's ever actually limiting. 0.3.13 won't even create blocks over 500kB, so it's not a problem right now.
6852  Bitcoin / Bitcoin Discussion / Re: Prioritized transactions, and tx fees on: September 30, 2010, 07:01:29 PM
I did a quick Google search on the topic, and discovered an old Visa press release that stated that during the peak hour for the year of 2005 (Dec 23rd) Visa processed an average of 6,363 transactions per second, or just shy of 3.82 million transactions within a ten minute span.

That's a lot. Bitcoin won't allow blocks over 1MB, so assuming a (rather small) average transaction size of 216 bytes, Bitcoin can only handle 4,629 transactions per 10 minutes.
6853  Bitcoin / Bitcoin Discussion / Re: Prioritized transactions, and tx fees on: September 30, 2010, 06:55:54 PM
Or is this total block size?  Am I looking at this right?

It's total block size. 250K = ~1150 transactions. See:
http://www.bitcoin.org/wiki/doku.php?id=transaction_fee
6854  Bitcoin / Bitcoin Discussion / Re: Prioritized transactions, and tx fees on: September 30, 2010, 06:32:41 PM
No one's going to figure out -paytxfee without reading the forums anyway, so we might as well just use -expectedBlockSize and rely on forum members to explain reasonable values if it actually becomes necessary.
6855  Bitcoin / Bitcoin Discussion / Re: Prioritized transactions, and tx fees on: September 30, 2010, 06:16:36 PM
That's cost per kilobyte, though, and a kilobyte can only hold ~9 TxIns, so 0.01 is not guaranteed to meet the requirement.
6856  Bitcoin / Bitcoin Discussion / Re: Post your static IP on: September 30, 2010, 03:47:49 AM
I took all of the IP addresses in this thread, tested them, and put the working ones on the wiki.
http://www.bitcoin.org/wiki/doku.php?id=fallback_nodes

Please put new entries there from now on.
6857  Economy / Marketplace / Re: Selling 50,000+ BTC at $0.04/BTC on: September 30, 2010, 12:29:23 AM
Also, make a note that I posted that same address on these forums on July 13th so unless those transfers were before then, it's safe to say that I'm actually the owner of that address. So, can you verify the time frame that the transfers were sent?

Two transfers: block 80339 (12 days ago) and 82659 (1 day ago).
6858  Economy / Marketplace / Re: Selling 50,000+ BTC at $0.04/BTC on: September 29, 2010, 09:37:20 PM
70,000 BTC has been sent to the address that bitcoin2cash posted. I don't have tools to see spends from an address, so I can't say what the current balance is.
6859  Bitcoin / Bitcoin Discussion / Re: Prioritized transactions, and tx fees on: September 29, 2010, 09:11:16 PM
As far as I can tell, transactions are not prioritized according to fee size. Paytxfee just ensures that you will meet the fee requirements (and it isn't guaranteed to do that). This does seem to be contrary to what Satoshi and sirius-m have implied, but I can't find any prioritization in the code.
6860  Bitcoin / Development & Technical Discussion / Re: I broke my wallet, sends never confirm now. on: September 29, 2010, 06:47:21 PM
The best option might be four passes at 120, 6, 1, and 0, to somewhat prioritize based on depth.
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 350 351 352 353 354 355 356 357 »
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!