Bitcoin Forum

Does your client have to be 100% synced to the server to send coins and the party get them?

Yes and no.

Technically if you absolutely know there are no further spends after block X then you could submit a valid transaction as long as you are synced up to block X.  The problem is that if after block X (say at block Y) you made a transaction and then restored from an older backup the client would be unaware those unspent outputs are now spent until it processes blocks up to and including Y.  That means that if you sent a transaction prior to syncing up to block Y it potentially could be a double spend and be seen as invalid.

As a result the Satoshi/reference client won't send until it is synced.  You could patch/fork it to override that safety feature and the transactions would be seen as valid by the network as long as the outputs chosen weren't involved in a future block and unknown to the client because its history is incomplete.

If you are asking if you receive bitcoins while offline, know that you never really "receive" bitcoins.  There is no need to be connected to the network to receive coins.

Now whether you can then spend those coins you received while offline depends on the client you are using.  The Bitcoin.org client requires one confirmation to spend those coins, so you would need to be connected enough to be caught up downloading blocks to spend those recently received funds.    Other EWallet clients (both hosted/shared EWallets and hybrid EWallets) might take care of being in sync with the blockchain but without a connection you won't be able to access those types of clients.

Having only intermittent connectivity does not mean the Bitcoin.org client cannot be used, but you will not be able to trust the transactions you receive until they confirm.  Thus a merchant with customers it might not be able to trust combined with intermittent connectivity should not treat as "paid" when receiving a transaction that has no confirmations (0/unconfirmed).

There are types of connectivity loss where Bitcoin probably won't work at all.  For instance, on a cruise ship where you might only have connectivity only periodically as you reach port.  Here's more discussion on that:

Desert island economy on Bitcoin without being connected to the internet?
 - http://bitcointalk.org/index.php?topic=106302.0

[Edit: The client will let you create a transaction that spends coins that were already confirmed, but as D&T mentions, it won't broadcast it until the client has caught up.]

Thank you, and Stephen, what I mean is if I get customers to try bitcoins, do they have to wait the 30 hours it takes to sync to the servers before they can send me a payment.

Running a full node is not for everybody.  There are lightweight clients that don't require the blockchain to be downloaded.

Simplified payment verification (SPV) clients, such as Multibit and Bitcoin Wallet for Android are examples.

Other lightweight clients, including Electrum and Bitcoin Spinner, use a client/server model, where your private keys are still safe locally.  Being client/server, these clients do rely on an external party and thus trust is being placed with the server that the information about balances and confirmations is accurate though, so there are reasons to not store or transact significant amounts of coins through these methods.

And then there are hosted (shared) EWallets such as Coinbase, Paytunia and Instawallet as well, in addition to the EWallet accounts for most exchange accounts.  Again, with these you are extending full trust to an external party -- thus consider this before storing larger amounts of coins with these methods.

Here's a review of some options:
- http://bitcoinmagazine.net/bitcoin-wallet-options/

As far as those needing or wanting the full blockchain, there are methods to speed up the initial startup.  If you pull the bootstrap.dat torrent and run v0.7.1 of the Bitcoin.org client, you'll be up to speed much sooner.  

Going forward, the next version of the Bitcoin.org client, (e.g.,likely v0.8.0), will include ultraprune, which makes a huge difference with regard to the performance of the initial block load time.