Bitcoin Forum
May 24, 2024, 01:42:32 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 [110] 111 112 113 »
2181  Bitcoin / Development & Technical Discussion / TEST network, for experimental development and hacking on: July 15, 2010, 12:51:03 AM
I went ahead and created a modified Bitcoin client with a brand-new block chain and a few other changes (detailed below) that will make it independent of the "production" Bitcoin network.

I intend to use it to test out some code I'm writing for my next project; I don't want to accidentally break (or slowdown or otherwise interfere with) the real Bitcoin network.  It should also be useful for anybody who wants to see if they can purposely break Bitcoin (for the purposes of a security audit).

Code is hosted at github: http://github.com/gavinandresen/bitcoin-git

Patches to go from 'production' bitcoin to 'TEST network' bitcoin are also at github: http://gist.github.com/502460

... so go nuts and start hacking.

Changes are:

+ Listen port is 18333 (instead of 8333).  Uses 18332 for JSON-RPC (instead of 8332).
+ Uses irc.lfnet.org channel #bitcoinTEST  for bootstrapping.
+ Never tries to connect to "well known" nodes for bootstrapping.
+ Uses bitcoinTEST for the default data directory (e.g. ~/.bitcoinTEST on Linux, %APPDATA%/BitcoinTEST on Windows, etc)
+ Uses a different ADDRESSVERSION for Bitcoin Addresses (0xff instead of 0x0), so you can't screw up copying and pasting Bitcoin addresses (if you try to use a TEST address on the production system it will tell you it's invalid; you can, however, lose TESTcoins by trying to send them to a valid production address)
++ Has a brand-new block chain (with a different genesis block)
++ Initial difficulty is 4 times easier than production Bitcoin
++ protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda } instead of { 0xf9, 0xbe, 0xb4, 0xd9 }

(16 July: "++" stuff added in response to the suggestions below in this thread)

A very generous TEST Bitcoin Faucet is running at: https://freebitcoins.appspot.com/TEST/

I think the TEST and production GUIs don't play well with each other; at least on my Mac, I have to quit the "real" bitcoin before running TEST.  That's probably an easy fix, I just need to figure out how...

2182  Economy / Marketplace / Re: World's SECOND Bitcoin lottery, Slashdot edition, this time stock markets! on: July 14, 2010, 03:18:54 PM
Ok.

As long as I get eleven.

(it's my favorite number)
2183  Bitcoin / Bitcoin Discussion / Why another surge in interest? on: July 14, 2010, 02:14:30 PM
So about two hours ago (8AM EST, 24 July) I see a big spike in traffic to the Bitcoin Faucet:


What's up with that?  The slashdot effect was just tapering off...
2184  Economy / Marketplace / Re: Donations to freebitcoins.appspot.com needed! on: July 14, 2010, 01:04:32 PM
Thanks Xavier!

To everyone else:  the Faucet is now giving out bit-nickels; it just went under 500 BTC.  I've got just under 2,000 BTC left to refill it, but I think I'll start letting it drain a nickel-at-a-time and keep it above zero for as long as I can (refilling it to just under 500 if it gets near zero).
2185  Economy / Marketplace / Re: World's SECOND Bitcoin lottery, Slashdot edition, this time stock markets! on: July 14, 2010, 12:59:42 PM
5 lots (25 BTC) on 011 please.

Eleven is my favorite number.
2186  Economy / Economics / Re: Forever(?) lost coins on: July 14, 2010, 11:43:36 AM
My point was that if "they" mount an attack, I think they're unlikely to do something subtle like try to mess with the block chain.

If "they" want to mess with the network, it would be far easier to do something like what China's doing with its Great Wall-- forcing connections they don't like to be dropped.  Or what botnets do now:  mount a denial-of-service attack by flooding the network.

Much more likely:  "they" will catch you for tax evasion when you convert your bitcoins to your local fiat currency and buy that fancy sports car you've always wanted.
2187  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 14, 2010, 04:22:49 AM
Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.

There's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:
Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.

I think Satoshi has done an amazingly fantastic job; over the last two days of Bitcoin being "slashdotted" I haven't heard of ANY problems with Bitcoin transactions getting lost, or of the network crashing due to the load, or any problem at all with the core functionality.

Yes, it's annoying to have to wait for the block chain to download (especially with the Microsoft Security Essentials weirdness), and yes it would be nice if all the pieces of Bitcoin functionality were already nicely separated and ready to be rearranged and extended in all the ways we all want to rearrange and extend it.  But I've been poking at the Bitcoin code for over a month now, and the more I learn the more impressed I become at the thought that's gone into it.

This quote seems appropriate:
"We reject: kings, presidents and voting.
We believe in: rough consensus and running code."  -- David D. Clark
2188  Economy / Economics / Re: Forever(?) lost coins on: July 14, 2010, 02:52:16 AM
Yeah, that would be a good problem to have.

Why would they mess around with the block chain, though?  Are you imagining the men in black double-spending enough Bitcoins to make merchants think it is untrustworthy? ("I shipped 100 computers to Langley, Virginia when the transaction had six confirmations, and now there's a new block chain that says those coins were paid to somebody else!!!")
2189  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 14, 2010, 02:20:45 AM
And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.

Is this possible? What would this look like? From a technical perspective what does a "lightweight client" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.
I'm imagining:

A lightweight client would have a wallet with coins in it (public+private key pairs).

And a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.

The lightweight client sends money by:
  creating a transaction (signing coins with the private key)
  sending the signed transaction securely to the ultra-fast server, which puts it on the network.
  receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)
   (or getting a "you already spent those coins" error from the server)

The lightweight client receives money by:
  Either polling the server every once in a while, asking "Any payments to these BC addresses that I have in my wallet?"
   ... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees
    a relevant transaction with N confirmations)
  When transactions occur, the lightweight client updates its wallet (adds the coins).

You don't have to trust the server; it never has your private keys.

Well, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?

2190  Bitcoin / Bitcoin Technical Support / Re: How long to start generating BC's? on: July 14, 2010, 01:44:36 AM
No, actually, in the current source code it never gets lowered:
Code:
    // Retarget
    CBigNum bnNew;
    bnNew.SetCompact(pindexLast->nBits);
    bnNew *= nActualTimespan;
    bnNew /= nTargetTimespan;

    if (bnNew > bnProofOfWorkLimit)
        bnNew = bnProofOfWorkLimit;

    /// debug print
    printf("GetNextWorkRequired RETARGET\n");
There's no "else if (bnNew < ...something)"

UPDATE:  rodin is right, I'm wrong.  bnProofOfWorkLimit is a constant, and this code just make sure the proof of work never gets too easy.
2191  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 14, 2010, 12:42:32 AM
77428 transactions in 66663 blocks is about 46,752,464 bytes.
which works out to about 600 bytes per transaction (including block headers + database overheads)
That sounds about right.

So a million transactions a day would be 600 million bytes.  600 megabytes a day, 18 GB a month.

That's not bad.  Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers).  You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month.  And 18GB isn't much disk space in these days of terabyte hard drives.

A million transactions per day is a LOT!  For comparison, in 2006 there were about 60 million credit card transactions per day in the US.

Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be some fancy IPV6 multicast protocol or something).  And they'll implement a couple of gateway nodes (running on really fast connections) that shuttle transaction and block traffic from the current Bitcoin network into the super-efficient network.  And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.

You know, kind of like how we have those Big Routers in the Sky that handle Internet backbone traffic (or the ultra-fast DNS root servers).  The Internet didn't start out with astoundingly fast routers zinging packets around.
2192  Economy / Economics / Re: Forever(?) lost coins on: July 13, 2010, 03:53:55 PM
... like how the RIAA screws around trying to disrupt BitTorrent swarms...

Umm, good luck with that.  I'm betting The Swarm will win most of the battles.
2193  Bitcoin / Bitcoin Discussion / Re: Average transaction time? on: July 13, 2010, 02:56:44 AM
After he's downloaded all 66,312 blocks and is up-to-date, transactions are very fast.
2194  Economy / Marketplace / Re: Donations to freebitcoins.appspot.com needed! on: July 13, 2010, 01:57:24 AM
Thanks for the donations... whoever you are who donated!

The Faucet has about 2,000 coins in it at the moment; I just deployed a new version that will automatically start giving out bit-nickels if the balance falls below 500 (but allows anybody who gets a bit-nickel to come back later and get the 5 bitcoins "they deserve" if/when the Faucet is refilled).
2195  Economy / Marketplace / Re: Get 5 free bitcoins from freebitcoins.appspot.com on: July 13, 2010, 01:04:22 AM
Gavin, you COULD look at the previous owner of the coins and remove that address from your blacklist. However, I dunno about the IP data.
Yeah, I could, but it seemed like more trouble than it was worth; if you got coins from the Faucet into a non-empty wallet and then donated them back there's no guarantee that the donation back would be the SAME coins.  I just don't want to deal with a lot of "I got five coins and then sent back ten but I still can't get more from the Faucet...."
2196  Bitcoin / Bitcoin Discussion / Re: Yet another newbie/wannabe geek is confused on: July 13, 2010, 12:52:41 AM
Transactions with "0 confirmations" are transactions that your client has seen, but haven't been put into a block yet.

Here's what happened when you bought the bitcoins:

Seller:  "Hey Bitcoin Network!  These here Bitcoins are getting sent to that there Bitcoin Address!"

Your client, listening in on all the payment network messages:  "Wow, spiffy, that's one of MY Bicoin Addresses!  I'll add that transaction to my wallet, and show that transaction as 0/unconfirmed in the UI."

Then your client goes on its merry way downloading the 66,241 blocks in the block chain.

In the meantime, some lucky soul generates block number 66,242, and includes your transaction in that block.  When your client connects that block up to the block chain (which it won't do until it gets all 64,241 previous blocks), it'll show it as "1/unconfirmed"

Then 2 confirmations when block 66,243 gets generated, etc.

Wonky things can happen if two nodes generate a different block 66,241 (especially if one of them included your transaction and one of them didn't, you can go from 1/unconfirmed back to 0/unconfirmed for a little while), but after a couple more blocks get generated everything sorts itself out.
2197  Economy / Economics / Re: Bubble and crashes on: July 12, 2010, 11:32:12 PM
First: it looks like we're in the middle of our first Bitcoin Bubble.  Price today went from about 0.8 US cents to 1.4 US cents on the Bitcoin Market.  Maybe the price won't crash back down... will be interesting to see what happens.

Second, RE: lending:  I think it's going to be really hard to establish enough trust to create a lending bitcoin bank.  I base that on my experiences dabbling as a Prosper.com lender; when hard times hit, repaying your Bitcoin debts will be WAAAAY down on the priority list.

Instead, I think we'll see Ponzi schemes masquerading as lending banks.  Buyer beware!

2198  Bitcoin / Project Development / Re: IRC meetings on: July 12, 2010, 11:24:13 PM
I'm available any time between about 12pm and 3am EST (UTC-5 (or -4 right now for daylight savings)).

That's when I sleep!  Meeting whenever is most convenient for Satoshi makes sense to me.
2199  Bitcoin / Development & Technical Discussion / Re: Bitcoin Generation and Alternative Applications on: July 12, 2010, 09:30:21 PM
I guess I'm having problems seeing where this algorithm is necessarily all that difficult and can't be sped up in some manner where a dedicated coin generator wouldn't have a huge advantage over a normal ordinary client in terms of the creation of Bitcoins.

Sure, you could build specialized hardware that computed SHA256 hashes faster than ANYBODY!
And then you'd be able to generate most of the bitcoins.

So:  how much would it cost you, in dollars or euros-- and don't forget to pay yourself for the time needed to design and build such a system?

Because you'd be able to generate, at most, 50 bitcoins every 10 minutes or so.  Soon after you started generating, all the other nodes on the network notice that bitcoins are being generated quicker than normal and increase the difficulty of the problem being solved (you've gotta twiddle the block header more times to find SHA256Hash(block_header) < target_value ).

If Bitcoins become even more wildly popular, then maybe people will think they can profit by building or renting specialized hardware.  That would be a very good problem for Bitcoin to have.
2200  Economy / Marketplace / Donations to freebitcoins.appspot.com needed! on: July 12, 2010, 07:15:46 PM
The Bitcoin Faucet is handling the slashdotting really well... except that I'm running out of coins to give away.  over 5,000 have flowed out of the Faucet since I refilled it last night.

Any of you early adopters who generated tens of thousands of coins back in the early days, are you willing to send a few to the Faucet to be given away so more people can try out Bitcoin?  I know that most of them are likely to be lost (I suspect there a lot of slashdot lookey-loos who won't stick around long enough to spend their 5 bitcoins), but if that's the case then that'll just increase the value of your other bitcoins, anyway...

Fountain donation address is:  15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC

Depending on donations and how long the slashdotting lasts, I might have to start giving away bitnickels...
Pages: « 1 ... 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 [110] 111 112 113 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!