On Sat, Apr 14, 2012 at 11:13 AM, Mike Hearn <m...@plan99.net> wrote: >> So, to be specific... a A->B chain of transactions, that collectively >> meet the network's fee requirements? > > Yes.
ACK on the concept >> Ideally the fee, if any, is market based and negotiated. Problem is... like >> democracy, no matter how ugly it is, people have trouble finding a >> better system :) > > I think this is something we can explore over the coming years. I > favor having people commonly pass transactions around outside the > broadcast network with the transactions and their dependencies being > broadcast only when there's a lack of trust between recipient and > sender. The block chain is an optional service after all. Agreed. A TX is just a signed message. No reason why it -must- use mainnet's distributed notary service. >> Furthermore, many of these ideas -- like sending TX's directly to the >> merchant -- involve far more direct payee<->payer communication on the >> part of the wallet client than is currently envisioned > > Yes, though it's worth remembering that the original Bitcoin design > did have participants communicate directly. When I talked with Satoshi > in 2009 he saw the pay-to-IP-address mode imagined as the normal way > to make payments, with pay-to-address being used as a kind of backup > for when the recipient was offline. > > In the end that's not how things evolved, but it the pendulum could > easily swing back the other way. IIRC pay-to-IP was removed because it was unreliable -and- detrimental to privacy? ISTR Satoshi specifically disliking the privacy elements of p2ip. But I also have a "gut feeling" that these sorts of payments and direct communication should be done via a wholly separate protocol than the bitcoin P2P protocol. Doing p2ip as it was done originally, inside the bitcoin P2P protocol, was a mistake. Extensible as it is, I think a better job -- and faster evolution -- can be done with a separate protocol on a separate port. Some HTTP derivative would probably make life easier for mobile payments and firewalled scenarios, and for client->merchant communications, for instance. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
