> I'd like to hear from other wallet implementors. Do you have a notion
> of 'locked inputs' ? The tricky bit in constructing a transaction but
> not broadcasting it right away is the inputs must be locked, so
> they're not accidentally double-spent.
>
bitcoinj separates the concept of committing a tx to the wallet from
broadcasting it. However by default transactions that weren't seen in the
chain yet will be announced when a new peer is connected to. It'd take
extra code to suppress that, and it's unclear to me why that's useful. I
agree with Pieter that it should be the merchants responsibility to get the
tx out there, but having the client do the broadcast as well can't really
hurt (except perhaps some privacy impact).
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
