Bitcoin Forum
August 14, 2020, 05:47:37 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 »
7461  Bitcoin / Bitcoin Technical Support / Re: wiki registration on: December 15, 2010, 05:02:29 AM
Bitcoin.org is sometimes blocked by email filters.

I have sent an email to your wiki email address. If you respond, I will change your password to a random one and send it to you.
7462  Bitcoin / Project Development / Re: block explorer command in yubnub on: December 15, 2010, 01:16:10 AM
Cool! You should actually redirect to /search/x, which will allow searches for partial addresses, transaction hashes, etc. Example:
http://blockexplorer.com/search/1Cvvr8As

I use a Firefox keyword to do much the same thing.
7463  Economy / Trading Discussion / Re: customer experience for purchases with Bitcoin on: December 14, 2010, 11:00:15 PM
As I understand the protocol, transactions are broadcast through the network without regard for transaction fees.

This was changed in 0.3.19. Transactions are no longer relayed if they don't have enough fee according to the client doing the relaying.

Clients older than 0.3.17 will actually send transactions that will be rejected for relaying by new clients. So if you're sending big transactions, make sure you're using the latest version...
7464  Bitcoin / Bitcoin Discussion / Re: Mining cartel attack on: December 14, 2010, 10:50:07 PM
So part of the computed input to the hash is a rounded version of the current time. If Bitcoin had something like this (and I'm sure there's some messy mechanics involved), it would allow us to reject blocks that have been stored for longer than a day (in this example). I suppose a cartel could precompute blocks in the future and hold them till they become valid / useful, but if the range for this were say, 4 hours?

There already is a timestamp, and you already will reject blocks too far in the past or future.
7465  Bitcoin / Development & Technical Discussion / Re: "Hidden Columns" in the windows UI? on: December 14, 2010, 10:33:54 PM
The columns become unlocked when you run with the -debug switch. Then you can resize them to a usable size.

For the first column:
- The first number is the block this transaction was included in, or INT_MAX if it is still unconfirmed.
- The second number is 1 if the transaction is a generation.
- The third number is a timestamp of when this transaction was sent/received
- The last number only appears on sent items. It indicates which output is not change.

The second column is the transaction's hash.

You can also get detailed information when double-clicking transactions while -debug is enabled.
7466  Bitcoin / Bitcoin Technical Support / Re: why it doesn't show from what address bitcoins came? on: December 14, 2010, 07:23:10 PM
You're not able to automatically tell in all cases, and in many cases transactions are from dozens of different addresses (when coins are combined). Bitcoin doesn't even try to figure it out. "Unknown" is the wrong word to use, though.

The coins came from 1A6hiTQC6NRXaoMsYKyvHxpPMz9Grog66Y.
http://blockexplorer.com/address/1GAP9vs4WxToXHe2btEWf2jb1u21dfzH9X
7467  Bitcoin / Bitcoin Discussion / Re: BitDNS and Generalizing Bitcoin on: December 14, 2010, 12:27:52 PM
Will it be open source or proprietary?

Open.
7468  Bitcoin / Bitcoin Discussion / Re: BitDNS and Generalizing Bitcoin on: December 14, 2010, 11:57:43 AM
My first objection to this is that it doesn't solve the problem of miner front-running; it just makes it more difficult. A few of the largest miners will just make an arrangement to mutually-process each other's fee adjust transactions. Almost inevitably, the design will produce a small group of large registrar-like operators.

More than 40% of the network would have to cooperate to get free domains. If malicious people are getting that much CPU, we have bigger problems. Even if this happens, servers can raise the limit to 7/10 or whatever.

Smaller percentages will get you a "discount", but I don't consider that to be a big deal. In particular, it'll be pretty easy to get a 1/5th discount if you can ever expect to create a block.

It's not a problem if people buy up names and then sell them on the market. This is an appropriate way to distribute unique resources. It's like homesteading some land in order to sell it later at a profit. We just want to prevent people from claiming millions of domains for free and then not using/selling them.

As for front-running: the first registrant will have an advantage in the race to get 4 adjusts. The first person has to send 4 more messages, while the attacker has to send 5. This can't really be done automatically, either, as people would attack the automated system by registering useless, random domains.
7469  Bitcoin / Development & Technical Discussion / Re: 0.3.18 Bug Report on "getreceivedbyaccount" display on: December 14, 2010, 12:44:19 AM
What is the difference between an address and an account? Are they not the same thing? In version 0.3.13 they seem to perform the same function.

"Label" was renamed to "account" recently. Addresses are grouped into accounts.

Lots of people have been confusing "address" and "account". The name should be changed to something more clear.
7470  Bitcoin / Bitcoin Discussion / Re: Mining cartel attack on: December 13, 2010, 10:50:42 PM
Someone (I wont say who) was discussing investing $200 000  into computer hardware which would mean they would control the network for the conceivable future.

Benevolent dictator anyone?

I trust ArtForz even more than Satoshi. If he did that, it would be a great benefit to the network.
7471  Bitcoin / Bitcoin Technical Support / Re: setup a server to connect to in I2P - how? on: December 13, 2010, 10:11:00 PM
Addnode only works with IP addresses.

Also, if you manage to get I2P's proxy to translate the IP address properly, make sure you use an address in the 192.0.2.x range. Bitcoin un-proxifies most other private ranges.
7472  Bitcoin / Bitcoin Discussion / Re: BitDNS and Generalizing Bitcoin on: December 13, 2010, 10:05:50 PM
Nanotube and I will be developing an implementation to go along with our proposal. If you like your idea, create it and let the market decide.
7473  Bitcoin / Bitcoin Technical Support / Re: setup a server to connect to in I2P - how? on: December 13, 2010, 04:53:01 PM
Only one connection is required, though more is desired for safety.

An I2P "Bitcoin proxy" would have to somehow connect simultaneously to both I2P peers and Internet peers. Otherwise anyone connecting to you would be segmented in I2P.

You will attempt to connect to Internet peers even with -noirc. You will just use the addr/seednode bootstrap mechanism instead of the IRC one. If you want to limit outbound connections to only peers you specify, use -connect=ip or -maxconnections=x in combination with exactly x -addnode=ip switches.

To connect to Bitcoin peers on Tor hidden services, it's necessary to use Tor's MapAddress option. Does I2P's proxy have a similar option of mapping an I2P address to an IP address?
7474  Bitcoin / Development & Technical Discussion / Re: 0.3.18 Bug Report on "getreceivedbyaccount" display on: December 13, 2010, 04:41:26 PM
You should be using getreceivedbyaddress rather than getreceivedbyaccount. You didn't assign that address to any account.
7475  Bitcoin / Mining / Re: Join a pooled bitcoin mining effort on: December 13, 2010, 02:36:02 PM
Nothing in Bitcoin's JSON-RPC can be used to see generations, apparently.

In rpc.cpp, you can see checks like this:
Code:
            if (wtx.IsCoinBase() || !wtx.IsFinal())
                continue;

Removing the "wtx.IsCoinBase()" check should allow you to see the transactions. I haven't tried it, though -- maybe they won't be handled correctly.
7476  Bitcoin / Bitcoin Discussion / Re: Mining cartel attack on: December 13, 2010, 02:20:28 PM
Is that really true?  I thought the "longest chain" was now defined in terms of the difficulties of the specific hash values in the chain, so I would expect that once a client has seen both blocks, it will build on whichever has the smaller hash value.  Is it not working that way?  Of course until you see the second block, you build on the first one, and it may take some time to switch.

Length has always been defined as "total work", but this is just the number of blocks multiplied by the difficulty of the blocks (for each 2016-block section). A smaller hash is not considered to be better than a larger hash.
7477  Bitcoin / Development & Technical Discussion / Re: infinite increasing of the chain size on: December 13, 2010, 03:04:14 AM
So how much data does the chain contain right now ?

- 97,289 blocks
- 56,806,614 bytes
- 206,775 transactions
- 248,937 outputs
- 278,362 inputs
- 162,871 addresses
7478  Bitcoin / Bitcoin Discussion / Re: Mining cartel attack on: December 13, 2010, 12:29:23 AM
What happens when two people both transmit a different valid next block? How does the network determine which chain to keep growing?

You build onto whichever one you saw first.
7479  Bitcoin / Bitcoin Technical Support / Re: BTC "Not Connected" on: December 12, 2010, 08:00:19 PM
Are you running Microsoft Security Essentials? You need to add an exception for Bitcoin in that case.
7480  Bitcoin / Development & Technical Discussion / Re: infinite increasing of the chain size on: December 12, 2010, 11:19:53 AM
Only generators need to store the entire block chain. Non-generators only need to store the tiny block headers. This is already mostly implemented (see fClient in the source).
Pages: « 1 ... 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 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 »
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!