Bitcoin Forum
November 17, 2018, 08:09:15 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 »
7001  Bitcoin / Bitcoin Discussion / Re: no confirmations on: October 28, 2010, 01:38:55 PM
What version are you using? Versions older than 0.3.13 will send bad transactions that most generators won't accept if you've ever received a similar bad transaction.

Run Bitcoin with the -debug switch and double-click the transaction. Paste the hash here. The hash is located under the "transaction" header:
CTransaction(hash=c3821b, ver=1, ...

Maybe that transaction didn't propagate correctly and it took that long before it was rebroadcast?

That is possible. Bitcoin waits a long time before it rebroadcasts, and it might take an especially long time if you never leave Bitcoin open for longer than a few hours.

Maybe somebody is simply messing with the network using a botnet or other large scale attack ?
I would like to hear Satoshi's opinion on what would exactly happen if (50% - 1) nodes of the network started to revoke the same transactions simultaneously. I mean there would be 50% - 1 "cheaters" working together, and the rest would be honest nodes.

Would the network still work properly in that case ? Or perhaps would some transactions be irreversably damaged ? Would the network figure out which hash calculations to trust and which not ?

An attacker with more than 50% of the network's CPU could prevent a specific transaction from gaining confirmations. See the wiki. There's pretty much no chance that this is happening here, though.

You might be able to do this for a while with less than 50% of the network. It depends on how lucky you are. You need to create more than 50% of blocks.
7002  Bitcoin / Development & Technical Discussion / Re: Rainbow tables against Botnets? on: October 27, 2010, 10:28:48 PM
All of the data that Bitcoin hashes is too large and random to use rainbow tables with.
7003  Economy / Economics / Re: Price Deflation Discourage Investment? on: October 27, 2010, 08:18:22 AM
Generating is just like buying bitcoins, except you pay with electricity and time.
7004  Bitcoin / Bitcoin Discussion / Re: Bitbot Need a New Home! on: October 27, 2010, 08:00:26 AM
I think Mizerydearia is planning to release bitbot's source. That would allow a new bitbot to be set up on a more stable server, or at least a backup bot to be made.
7005  Bitcoin / Bitcoin Discussion / Re: A lucrative attack on bitcoin? on: October 26, 2010, 11:52:04 PM
Quote from: ByteCoin
so theymos is easily out by a factor of 100.

I forgot to move the decimal over for the fee per KB.  Embarrassed
7006  Bitcoin / Bitcoin Discussion / Re: A lucrative attack on bitcoin? on: October 26, 2010, 08:50:01 PM
Large blocks are a valid DoS attack against bitcoin, presently.  Transaction fees kick in at higher block sizes, but it still remains quite inexpensive to flood the network, even if you are paying full TX fees right up to the 1MB (?) block limit.  I dunno about lucrative, but...

Driving a block to 1MB costs 21 million BTC. I don't think attackers are going to pay...

Code:
if (nNewBlockSize >= MAX_BLOCK_SIZE_GEN)
                return MAX_MONEY;

Here's how much it would cost (estimates) to make the block size go to various levels:
-50 KB: Free
-250 KB: 2 BTC
-300 KB: 127 BTC
-350 KB: 293 BTC
-400 KB: 543 BTC
-450 KB: 1043 BTC
-490 KB: 3543 BTC
-495 KB: 8543 BTC
-499 KB: 33543 BTC

Attackers can feel free to pay 500 BTC every 10 minutes to make sending transactions expensive...
7007  Bitcoin / Bitcoin Discussion / Re: A lucrative attack on bitcoin? on: October 26, 2010, 08:15:06 PM
True.  Quoting Satoshi's white paper :

That's about transactions in blocks, which are further protected by transaction fees. I'm talking about transactions waiting to get into a block.
7008  Bitcoin / Bitcoin Discussion / Re: A lucrative attack on bitcoin? on: October 26, 2010, 07:57:54 PM
Unless there is a scheme for forgetting transactions that have insufficient fee then it's still a big problem.

Transactions are forgotten over time, to prevent just this problem! Nodes delete transactions in their memory pool on shutdown, and they never rebroadcast transactions that they already know about. This causes most of the network to forget about a transaction in about a week. If your transaction isn't going through, you would restore from an old wallet backup, wait for the network to forget your transaction, and re-send.
7009  Economy / Economics / Re: How evil is Bitcoin ? on: October 26, 2010, 01:44:10 AM
From a large corporation, a purely profit driven enterprise, faceless and cruel.
Most don't have unions, minimum wages and ignore the cries of employees.
The producer of the item being liberated is already payed in full.

This kind of incorrect thinking is caused mainly by ignorance of economics, I think.

In a voluntary society such things would be punished more harshly than they are now imo.

In anarcho-capitalism, you'd probably have to pay your own defense agency a huge amount of money to convince them to keep such an idiot under their protection.
7010  Economy / Economics / Re: How evil is Bitcoin ? on: October 26, 2010, 01:27:52 AM
Some anarchists (usually social anarchists) have advocated forms of direct democracy as an alternative to the centralized state and capitalism; however, others (such as individualist anarchists) have criticized direct democracy and democracy in general for ignoring the rights of the minority, and instead have advocated a form of consensus decision-making. Libertarian Marxists, however, fully support direct democracy in the form of the proletarian republic and see majority rule and citizen participation as virtues. The Young Communist League, USA in particular refers to representative democracy as "bourgeois democracy," implying that they see direct democracy as "true democracy."

Any kind of democracy, "consensus decision-making", or any type of government entails some group of people forcing their will on some other group of people. They all violate property rights and are therefore immoral.
7011  Bitcoin / Bitcoin Discussion / Re: With "Balance sheets" most of the block chain can be forgotten. on: October 25, 2010, 10:15:39 PM
Quote
Using the same definition, "Balance sheets" is essentially done as well!

The simplified payment verification system is already in place. The Merkle root required for its functioning is included in all blocks. Blocks do not include the hash of a balance sheet.

The size difference would not be significant. SPV is ~80 bytes per block plus 32 bytes per transaction, whereas balance sheets would be 20 bytes per unique address. Currently there are 132415 unique addresses in the system and 134267 transactions. SPV: 11.29 MB; balances: 2.65 MB. This is assuming that balance sheets will not have any header-like overhead, which they almost certainly will.

SPV looks through the Merkle tree to get the number of confirmations and prove that transactions and their prev_outs were not double-spent. This is the point of SPV. How would balance sheets solve this? If you're just going to download the most recent 5 blocks or whatever (an insecure method), why even have balance sheets? You can't generate with balance sheets, as you are unable to verify referenced signatures.

Using balance sheets with the current system would require receiving and processing every transaction ever made, which will become difficult as the block chain grows. SPV requires no such processing, and the amount of data stored on disk is the amount received through the network.

A balance sheet system written from scratch would not be any better than the current system. Generators need to know the contents of every non-spent transaction, so a parallel network similar to the current one would have to be kept. Clients would need to download every block header (as in the current system) because the current block with the balance hash can only be verified if you have every block in the chain.
7012  Bitcoin / Bitcoin Discussion / Re: With "Balance sheets" most of the block chain can be forgotten. on: October 25, 2010, 02:28:07 AM
This is essentially already done. Bitcoin uses a hash tree structure for transactions that makes it possible for nodes to:
- Do everything except generation by downloading just the block headers and Merkle tree for each block, which is a tiny amount of data.
- Discard outputs that have been spent (referred to by a later transaction), even if you're a generator.

Neither of these are actually implemented yet, but the system of capable of doing it.

You could even generate while running in header-only mode (using getdata messages to get transactions you're missing), though the entire network could not do this.
7013  Bitcoin / Project Development / Re: Bounty for Bitcoin Animated Movie [5173.05 BTC ($285) and growing] on: October 24, 2010, 10:36:03 PM
Could he simply be automatically sending bitcoins from one wallet to another?

My old post (edited) was a mistake. I was looking at the wrong output index. Noagendamarket sent to those addresses, not bytemaster.
7014  Bitcoin / Project Development / Re: Bounty for Bitcoin Animated Movie [5173.05 BTC ($285) and growing] on: October 24, 2010, 10:30:27 PM
I suppose you can check to see if the same coins were 'spent' by bytemaster, and to whom.

It was not spent.
7015  Bitcoin / Bitcoin Technical Support / Re: Stopping Bitcoin on: October 24, 2010, 03:28:23 AM
So the calulators that I see are just calculating odds then.  I take it you could solve a block in your first 5 minutes if you were lucky enough.  Or if unlucky then you might not solve one all month.

That's right. The calculators look at the current odds per hash (this changes from time to time), and from that calculate the average number of hashes it takes to solve a block. Then you can figure out the average time to solve a block based on your hash rate.
7016  Bitcoin / Bitcoin Technical Support / Re: Stopping Bitcoin on: October 24, 2010, 12:28:04 AM
There is no "progress", so there is no loss. For every hash that you calculate (you might calculate millions of these per second), there's a small chance of solving a block. Each hash is like an entry into a lottery. Each hash is independent of the others, so nothing needs to be saved.
7017  Bitcoin / Bitcoin Technical Support / Re: ERROR - PLEASE HELP ME! on: October 23, 2010, 06:29:19 PM
He was generating invalid blocks at difficulty 1.0.  He must have a corrupted txindex entry in his blkindex.dat file.  He just needs to delete blk*.dat and let it redownload.

He already did that, and the same problem occurred right away. So it's probably an antivirus issue.
7018  Bitcoin / Bitcoin Technical Support / Re: ERROR - PLEASE HELP ME! on: October 23, 2010, 06:14:37 PM
What does it take for a client to reject an incoming block from the network? If we know this we can work backwards and find out why he wants to reject every new block. There must be a transaction in the main chain 1699 or prior that his client disagrees with.

He would have to disagree with 1699, but that is an empty block. There's no reason he should disagree with that one.

My theory:

His antivirus cuts off files after a certain size. This caused his block database to be limited at 1698 (and maybe he rejects blocks after that due to corruption). However, his block index was not cut off (because it's shorter), so he ignores incoming blocks as "already have", even though he doesn't really have them. Every time he generates a block, it is quickly destroyed by the antivirus, but its confirmations are preserved by the block index for some reason.
7019  Bitcoin / Development & Technical Discussion / Re: Suggestion: Allow short messages to be sent together with bitcoins ? on: October 23, 2010, 05:56:04 PM
Like grondilu said, encryption isn't possible.

It's possible to modify Bitcoin to send messages. Just create transactions that start with something like this:
Code:
BTCMESSAGEv1--This is a message OP_DROP

The network will accept these, but I don't think your recipient will recognize them unless he is also using your modified Bitcoin.
7020  Bitcoin / Development & Technical Discussion / Re: Version 0.3.14 on: October 22, 2010, 06:55:14 PM
Satoshi, could you tell me of what revision is this version ?

I tried diff-ing the files (from SVN and from the binary package with sources), but there seems to be some kind of binary differences in the files, and they are marked as different when doing directory compare, but diff software cannot pinpoint what are the exact differences !!

That is the weirdest thing i have seen in a long time.
Perhaps the files from the package are encoded in UTF-8, UTF-16 or something ? In SVN, they are noticeably smaller.

SVN has Unix line endings, while the source in the packages has Windows line endings. The files are otherwise exactly the same.
Pages: « 1 ... 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 »
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!