Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On 4/12/12, Jeff Garzik jgar...@exmulti.com wrote: 1. N = 1 or 2 or whatever the community prefers. Ideally enough time for a third-tier miner, mining strange TXs, finds a block. 2. H1 = height of block chain, when a TX is received 3. H2 = H1 + (144 * N) 4. If block chain height reaches H2, and TX has not made it into a block, drop TX from memory pool Why not just adding a field expiration_block = H2? It seems more explicit and flexible than using a 144 * N constant. You're changing the protocol anyway, right? Another question, aren't different peers going to get different H1 for the same tx? -- 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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote: 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. 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. Have you ever read https://gist.github.com/1237788 ? -- Pieter -- 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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Sat, Apr 14, 2012 at 5:27 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote: Some HTTP derivative would probably make life easier for mobile payments and firewalled scenarios, and for client-merchant communications, for instance. Have you ever read https://gist.github.com/1237788 ? Looks like you're already headed in the right direction :) -- 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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On 2012 April 12 Thursday, Jeff Garzik wrote: One of my From-Day-One complaints about bitcoin is that transactions behavior could be far more deterministic (predictable), from a user standpoint. Transactions in the current system can easily remain in limbo forever. One big step in making transactions behave more predictably would be to remove transactions from the memory pool, if they have not made it into a block for a couple days. i.e. A change I've wished for for a while (but I suspect it is too big a change to ever make it) is that a transaction announcement include the block the user wants to base on. It would only be in the protocol message, not the transaction stored in the blockchain. The advantage is that (1) it protects against double spends without needing a confirmation period; as a merchant I can instantly spend a 1-confirmation transaction by creating my transaction with that 1-confirm as its base. (2) your expiry from memory pool becomes easy -- if the base is more than N blocks below the current head, then that transaction won't be included. Retransmission is possible with the base updated. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- 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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
It sounds OK as long as you exclude nLockTimed transactions.
That said, if you broadcast a transaction that does not meet the fee
rules, you should be able to notice that it wasn't accepted by your
peers immediately. Today it's painful because the protocol isn't very
chatty - in bitcoinj I plan to do this by announcing to half the
connected peers and waiting to see if the transaction comes back on
the other half. Getting a response from a peer that the TX was dropped
for reasons {x,y,z} is a better design but needs another protocol
change.
So having transactions expire would address the case where somebody
broadcasts a transaction that successfully propagates across the
network, but then isn't actually accepted by miners for some reason.
For instance due to a change in the default fee schedules. That risk
can be mitigated somewhat by being careful about such changes (timed
phase ins set multiple months out so people have time to upgrade,
alerts announcing it, etc).
I'm not sure we should be encouraging users to attach fees to
transactions though. Even if you can replace a transaction after a
couple of days, the user experience of trying to get the fee right
is atrocious. I don't think any sensible merchant will actually be
willing to put their customers through this nonsense. If somebody
broadcasts a transaction that successfully propagates across a big
chunk of the network but then gets stuck due to lacking sufficient
fees, the best fix is for the merchant to broadcast another
transaction that spends the first and increases the fees on it that
way. After this happens a few times, if I was a merchant I'd be
tempted to just ask buyers to submit the TX to me directly and I'll
handle keeping up with what miners currently charge and attaching
fees. I don't want my customers to have to think about this and have
trades spuriously fail when they forget.
That design requires a minor change to how fees are calculated inside
the memory pool, to include fees on un-included dependencies. But that
seems fairly uncontroversial to me. It's best for users, merchants and
miners to not leave chains of transactions in limbo when together
their fees add up to the minimum required amount.
--
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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Fri, Apr 13, 2012 at 6:04 AM, Mike Hearn m...@plan99.net wrote:
It sounds OK as long as you exclude nLockTimed transactions.
ACK, agreed
That said, if you broadcast a transaction that does not meet the fee
rules, you should be able to notice that it wasn't accepted by your
peers immediately. Today it's painful because the protocol isn't very
chatty - in bitcoinj I plan to do this by announcing to half the
connected peers and waiting to see if the transaction comes back on
the other half. Getting a response from a peer that the TX was dropped
for reasons {x,y,z} is a better design but needs another protocol
change.
So having transactions expire would address the case where somebody
broadcasts a transaction that successfully propagates across the
network, but then isn't actually accepted by miners for some reason.
Correct. As mentioned, this change should impact few TXs on the
existing network.
It's mostly about getting everyone to collectively agree that
transactions should expire, if they don't make it into a block.
(excl. nLockTime stuff) A minor technical step, but also a useful
policy step.
For instance due to a change in the default fee schedules. That risk
can be mitigated somewhat by being careful about such changes (timed
phase ins set multiple months out so people have time to upgrade,
alerts announcing it, etc).
I'm not sure we should be encouraging users to attach fees to
transactions though. Even if you can replace a transaction after a
couple of days, the user experience of trying to get the fee right
is atrocious.
Yes -- I think there is near-universal agreement on this user experience point.
I don't think any sensible merchant will actually be
willing to put their customers through this nonsense. If somebody
broadcasts a transaction that successfully propagates across a big
chunk of the network but then gets stuck due to lacking sufficient
fees, the best fix is for the merchant to broadcast another
transaction that spends the first and increases the fees on it that
way. After this happens a few times, if I was a merchant I'd be
tempted to just ask buyers to submit the TX to me directly and I'll
handle keeping up with what miners currently charge and attaching
fees. I don't want my customers to have to think about this and have
trades spuriously fail when they forget.
That design requires a minor change to how fees are calculated inside
the memory pool, to include fees on un-included dependencies. But that
seems fairly uncontroversial to me. It's best for users, merchants and
miners to not leave chains of transactions in limbo when together
their fees add up to the minimum required amount.
So, to be specific... a A-B chain of transactions, that collectively
meet the network's fee requirements? It seems quite reasonable to
accept that, sure. ACK on concept. A chain of length 2 seems like it
would be most common, and limiting total chain length (to 10? 100?)
for any one chain in the memory pool seems prudent.
As to the larger issue of fees... I will readily admit I have no good ideas.
The user's experience is pretty poor: while it might make economic
sense, from the network's standpoint, to charge for the service of
verifying and storing a transaction, the user has limited means to
determine an ideal fee. There are also other valid economic models
(receiver pays fee) out there that may successfully sustain the
network.
Ideally the fee, if any, is market based and negotiated. The current
method is loose-consensus, mainly aimed at (a) combating dust spam or
(b) ensuring it becomes increasingly more expensive to fill a block,
up to the current 1MB maximum. I think almost everyone agrees the
current fee system is an ugly, warty hack. Problem is... like
democracy, no matter how ugly it is, people have trouble finding a
better system :)
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 by the bitcoin
P2P network design, which is broadcast-oriented. So, it remains an
open question whether we want the base bitcoin layer to even worry
about real-time fee negotiation and direct TX transmission.
It is possible that an instant-payments layer evolves on top of the
base bitcoin block chain layer, with bitcoin transactions evolving
largely into settlements between instant-payment intermediaries large
and small.
--
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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
My one big concern about this that users find a way to exploit this behavior for themselves. If it's too easy for users to create tx they know will get stuck and expire, it's no different than letting them cancel their zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it using a combination of inputs and fees that I know will lead to it being stuck and expire. On the other hand, if such conditions are deterministic enough, it could be detected by the recipient and flagged. It's not a huge deal, but it's something to consider. -Alan On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik jgar...@exmulti.com wrote: Not sure whether this rises to the level of a BIP or not, as it is largely an implementation change. One of my From-Day-One complaints about bitcoin is that transactions behavior could be far more deterministic (predictable), from a user standpoint. Transactions in the current system can easily remain in limbo forever. One big step in making transactions behave more predictably would be to remove transactions from the memory pool, if they have not made it into a block for a couple days. i.e. 1. N = 1 or 2 or whatever the community prefers. Ideally enough time for a third-tier miner, mining strange TXs, finds a block. 2. H1 = height of block chain, when a TX is received 3. H2 = H1 + (144 * N) 4. If block chain height reaches H2, and TX has not made it into a block, drop TX from memory pool Although this only impacts a small amount of TX's ultimately, what it does do is give us the ability -- once miners have upgraded to this rule -- to tell bitcoin users that their transactions expire after N days. Backwards compatibility should not be an issue; clients are free to retransmit their TX at any time, as usual, thereby resetting the clock for all peers who have forgotten the TX in question. Once in place, clients may then implement code that notices a TX has expired (read: likely to have been forgotten by the network, assuming they themselves have stopped retransmitting it). Then you can start working on wallet/coin recovery, perhaps resending with a higher fee etc. The above change is not really fill-or-kill but it should be a big step, opening the door to deterministic TX behavior. -- 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 -- 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
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Thu, Apr 12, 2012 at 3:19 PM, Alan Reiner etothe...@gmail.com wrote: My one big concern about this that users find a way to exploit this behavior for themselves. If it's too easy for users to create tx they know will get stuck and expire, it's no different than letting them cancel their zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it using a combination of inputs and fees that I know will lead to it being stuck and expire. On the other hand, if such conditions are deterministic enough, it could be detected by the recipient and flagged. It's not a huge deal, but it's something to consider. Do you have a -specific- concern that you feel may be exploited? Expiration already occurs at random, as nodes shut down and restart, log on and log off the network. -- 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
