Mike Hearn f27430c356 Refactor/bugfix broadcast of pending transactions when a peergroup starts up. ... Previously the PeerGroup itself would broadcast the pending transactions by simply sending an inv with them all to every peer. This is a good way to get a transaction blasted out if there are no problems with it, but it means we cannot track propagation and the numBroadcastPeers() value was correspondingly not increased. This seems to be causing issues with the Android wallet. So try out a different approach - have the wallet use broadcastTransaction as per normal on the PeerGroup when it's added. The TX will be propagated and watched as with a normal spend.		2013-10-11 14:50:53 +02:00
..
main/java	Refactor/bugfix broadcast of pending transactions when a peergroup starts up.	2013-10-11 14:50:53 +02:00
test	Refactor/bugfix broadcast of pending transactions when a peergroup starts up.	2013-10-11 14:50:53 +02:00
bitcoin.proto	Wallet: support for key rotation.	2013-08-11 16:33:36 +02:00
paymentchannel.proto	Payment channels: protocol tweak - when the client sends a CLOSE, the server sends a CLOSE back that contains the final negotiated contract, so it can be inserted into the wallet without needing to wait for a network broadcast (this is useful if the client does not have internet connectivity at that point).	2013-10-04 17:10:42 +02:00
storedclientpaymentchannel.proto	Payment channels: bug fixes and improved close behaviour.	2013-09-30 14:35:25 +02:00
storedserverpaymentchannel.proto	Store states in protobufs instead of using Java Serialization.	2013-07-11 14:16:40 +02:00