Bitcoin Forum
May 27, 2024, 05:22:23 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 286 287 288 289 290 291 292 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 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 ... 421 »
6701  Bitcoin / Development & Technical Discussion / Re: Why transaction fee is so big? on: May 30, 2011, 09:00:53 PM
You must have received a ton of very small transactions. As a result, sending them all requires a lot of data. The fees are usually not so high.
6702  Bitcoin / Development & Technical Discussion / Re: Is the ECDSA public key hashed as a extra level of protection? on: May 30, 2011, 08:56:29 PM
It's to make the public keys shorter. You could just truncate the key and say that any key with the same start is OK, but this is probably less secure than hashing the entire key.
6703  Bitcoin / Development & Technical Discussion / Re: Transaction pruning details on: May 30, 2011, 05:23:51 PM
Forget for a while about transaction fees, but can one of these transactions be pruned (after being confirmed by enough blocks in the longest chain)?

The first one can be forgotten (assuming it only has one output). It will never again be needed for verifying other transactions, since it can't be redeemed again.
6704  Bitcoin / Bitcoin Discussion / Re: Co-ordinated DDoS on multiple mining pools on: May 30, 2011, 09:25:56 AM
Is it possible to have a decentralized pool, or is a central authority required to ensure miners are honest?

It is possible to have a decentralized pool, but IMO building it would be a waste of time, since it will be too expensive to be a full Bitcoin node not too far in the future, and participants in a decentralized pool must be full nodes. A decentralized pool also requires a great deal of bandwidth itself, since all peers must understand the complete state of the pool (as far as I can tell).

One possible design:
- Each miner broadcasts all of the low-difficulty shares they win, which is used to calculate proper ratios for every participant.
- Each miner works on its own block. The coinbase transaction pays out according to ratios that it calculates. Each miner chooses which transactions to include according to its own rules.
- Miners broadcast their block headers, coinbase transactions, and Merkle branches for their coinbase transactions to the entire pool. The pool doesn't need to know which other transactions they include.
- When you receive a header+coinbase, you examine the payout ratios, and if you agree with them, you add the person who sent it to your own coinbase transactions for payout.
6705  Other / Politics & Society / Re: Bitcoin mail on: May 30, 2011, 08:28:57 AM
I'm not sure that there will be a sufficient market. I hardly ever send snail mail.
6706  Other / Meta / Re: Contacting the admins on: May 30, 2011, 08:18:37 AM
The active administrators are currently:
theymos (me)
Gavin Andresen
sirius

Sirius runs the server.
6707  Bitcoin / Development & Technical Discussion / Re: Design notes for sharing work between multiple independent chains on: May 30, 2011, 07:00:12 AM
No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.


I argued against that notion in the thread:

If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices:
- You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.)
- You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.
6708  Bitcoin / Development & Technical Discussion / Re: Design notes for sharing work between multiple independent chains on: May 30, 2011, 06:51:00 AM
But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

That's only if >50% of the mining power agrees to do that. I doubt it will ever happen.
6709  Bitcoin / Bitcoin Discussion / Re: Bitcoin is men's toy on: May 30, 2011, 06:41:26 AM
Right now only technical people can use Bitcoin, and most technical people are male for some reason. Once Bitcoin (or some EWallet service) is easy enough for non-techies to use, it will be adopted by some communities that contain a balanced or female-dominated demographic.
6710  Bitcoin / Bitcoin Technical Support / Re: No Connections and bitcoin command not found on: May 30, 2011, 05:50:26 AM
You need to tell your shell where the bitcoin binary is located. It varies by distribution, but you might try:
Code:
/usr/bin/bitcoin -addnode...
or
Code:
/usr/local/bin/bitcoin
or
Code:
~/.bitcoin/bitcoin

Use your file search utility if none of that works.
6711  Bitcoin / Bitcoin Discussion / Re: What's the largest purchase you've made in Bitcoins? on: May 30, 2011, 05:45:08 AM
I think my largest trade for real-world items was 300 BTC for a laptop.
6712  Bitcoin / Bitcoin Discussion / Re: mybitcoin security vulnerabilities on: May 30, 2011, 02:56:22 AM
I'm not surprised. MyBitcoin is still accepting payments with only 1 confirmation, which would allow some of the larger pools to steal BTC right now.
6713  Bitcoin / Development & Technical Discussion / Re: Adding a technical Security section to the FAQ on: May 30, 2011, 02:40:38 AM
https://en.bitcoin.it/wiki/Weaknesses#Spamming_transactions
6714  Bitcoin / Development & Technical Discussion / Re: Why do you want to change Bitcoin? on: May 30, 2011, 02:36:45 AM
"Elegant" is word that describes the core of Bitcoin well. Maybe a few things could have been done better, but the current system could conceivably work for hundreds of years (with minor tweaks along the way).
6715  Bitcoin / Development & Technical Discussion / Re: Design notes for sharing work between multiple independent chains on: May 30, 2011, 12:45:07 AM
An output with 0 value is valid, and these outputs can't be forgotten by the network until they are spent (which is also valid). So you can stuff all of the DNS data into several of those outputs.

When the bitDNS spec was written, having more than two outputs was not considered standard; therefore, it was difficult to get those transactions into blocks. Now they are standard.
6716  Bitcoin / Development & Technical Discussion / Re: Txn fee back to 0.01 in rc5? on: May 29, 2011, 07:55:20 PM
BTW, Luke-Jr pool accepts transactions with lower fees...
I can't seem to figure it out though, I added "-addnode=173.242.112.53" when launching Bitcoin but it still forces the 0.01 fee. Must be too late at night for me.... Huh

Your client doesn't negotiate fees in any way with your peers, so it doesn't know that Luke-Jr requires lower fees. You have to modify your client (or use an old version) to take advantage of the lower fees.

Luke-Jr also rejects all totally free transactions, I believe.
6717  Bitcoin / Development & Technical Discussion / Re: Design notes for sharing work between multiple independent chains on: May 29, 2011, 07:50:55 PM
As most miners will forget old transactions, you would have to renew the transactions from time to time with BitDNS.
Am I right, theymos?

Yes. Our spec handles this by requiring DNS renewals. There are ways to handle it more elegantly, though (using multiple 0-value outputs, for example). The spec was written a while ago.
6718  Bitcoin / Bitcoin Discussion / Re: Bitcoin is a PoS on: May 29, 2011, 07:57:20 AM
No one will accept your reversible credit card or PayPal money for non-reversible bitcoins unless you prove your trustworthiness in some way. The difficulty of trading isn't a problem with Bitcoin (mostly): all non-reversible payment methods such as wire/ACH transfers are just difficult to use, and you need to use them to get bitcoins.

Pecunix is 9 years old, but it still has this problem because it is also non-reversible. In fact, Pecunix is probably even more difficult to get. Same for Liberty Reserve, though it is younger than Pecunix.
6719  Bitcoin / Development & Technical Discussion / Re: Txn fee back to 0.01 in rc5? on: May 29, 2011, 06:39:16 AM
You can set the fee in the options or is that something else?

That can only increase fees from the default, not decrease them.

Once transaction replacement is possible, Bitcoin will hardly even have to worry about this. People will use trial and error to find the correct fees.
6720  Other / Meta / Re: "Currency exchange" subforum in Marketplace? on: May 29, 2011, 03:08:44 AM
Currency Exchange
Goods
Services
Employment

Someone make it happen. If I want to buy chicken bones first I have to see if any are for sale, then I have to go to a different forum to offer to buy them. What the hell? This applies for everything, not just bones. If I'm just curious about what goods are being bought and sold, I have to go to two forums, why?

The current setup is not good for users at all. It's simple to police, that's it's only benefit.

I'm going to repost this in it's own thread later if I need to.

This sort of split makes more sense to me than "buying/selling". Shouldn't "employment" be combined with "services", though?
Pages: « 1 ... 286 287 288 289 290 291 292 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 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 ... 421 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!