Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

You can include a transaction bounty (traditionally 0.01 BTC) with your payment which the verifiers receive if they're the first to verify your payment. Effectively, this puts your transaction at the top of the priority queue. When you're connected to a healthy number of peers, this can bring down the verification time down to seconds.

Another approach is to have "trusted sources" which are Bitcoin banks/ewallets. If your customer is using a Bitcoin bank like eWallet to send a payment, you can pretty much assume that the transaction is valid based on the source, without verification.

Either way, this is merely a short term problem. As more Bitcoin infrastructure springs up (more banks, more verification hubs, more incentive on transaction fees rather than mining, when mining gets too expensive) then these problems will be organically mitigated. If the Bitcoin infrastructure were to remain the way it is now forever, it won't scale for many other reasons (like requiring peers' wallets to store significant transaction history that could grow at the rate of gigabytes per hour with "real world" volume).



You can include a transaction bounty (traditionally 0.01 BTC) with your payment which the verifiers receive if they're the first to verify your payment. Effectively, this puts your transaction at the top of the priority queue. When you're connected to a healthy number of peers, this can bring down the verification time down to seconds.

Isn't transaction verification tied to block generation, and isn't block generation limited to about 1 every 10 minutes?


Someone correct me if I'm wrong, but I don't think transaction verification is tied to generating new blocks.

From how I understand it, verification involves:

1. Confirming the privately-signed transaction against the public key of the source wallet (transactions not forged).

2. Confirming against the historical transaction chain that the coins actually belong to the source wallet (coins not forged).

3. Passing the verified transaction along to other peers.


The generating of new blocks is what sets the transaction "in stone". And the more blocks past a transaction's inclusion, the harder it is to reverse that transaction - more blocks = more certain you have actually received the money.

Prior to being included in a block, it's entirely possible for the payer to issue the same money to multiple recipients. Once it's in, it's assured that only one is included, and others are therefore invalid. So it's in recipients' best interests to wait for a few blocks before totally accepting something as "paid".


Ah that makes sense. Thanks for the explanation.


It is. Transaction fees are (theoretically) supposed to provide incentive to be a block solver, and the solver can choose what transactions to include and what to ignore, so it's in their best interest to include ones that have fees. As usage increases, this means more and more work for the solvers, so they're more likely to drop things they can't make money on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: