Re: [Bitcoin-development] Adding request/reply id in messages
I don't understand why you say my proposal would make the protocol more stateful. I think it doesn't. Each reply is only the result of the current request only, and there is no new session information. I also wondered this. My first thought was that it's basically the same as the PING message, a nonce that is repeated immediately on reply. This makes it easier to multiplex operations over a single channel. I'm not against this basic idea, and it is easy to ignore for clients that don't want to use it. I think the state comes in here: - inv sends back the requestid given in getblocks or a special value in case of a notification. - addr sends back the requestid given in getaddr or a special value in case of a notification. *command1* sends back the requestid given in *command2*. This requires keeping state on the connection between command1 and command2. Arguably, this state already exists in the current protocol, but I'd rather see it reduced than extended. Also... Many of the described commands don't need this as they already have a natural nonce. For example, the id of the requested block header. If this is passed in the reply, and the caller can correlate the request and reply without a special nonce administration. Wladimir -- 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
[Bitcoin-development] Announcing the IFEX Project
The Internet Financial EXchange (IFEX) Project is an open body for the discussion and development of financial standards for the internet community. The project seeks to focus on enhancing interoperability between financial settlement systems of all types, including conventional financial systems, emerging digital currencies, alternative financial communities, and financial service providers. Interested parties are invited to review the proposals on the website at http://www.ifex-project.org/ and join the mailing list at http://group.ifex-project.org/ Two items on the site that may be of particular interest: (1) The latest version of the IIBAN Proposal (v1) for financial endpoint identification at http://www.ifex-project.org/our-proposals/iiban. This latest version includes initial IANA registry contents and a reference mechanism for financial endpoint transcription error correction. (Relevance: In contrast to settlement system-specific financial endpoint identifiers, IIBAN provides a democratically allocated, 13 character identifier that is already familiar in format to users in Europe and other countries and is theoretically compatible with conventional banking infrastructure in those regions. In addition, IIBAN is not tied to any specific financial commodity or settlement system, and provides strong protection against identifier transcription errors.) (2) The IFEX Protocol is a *work in progress* that hopes to bridge the gap between conventional financial systems, emerging digital currencies, alternative financial communities, and financial service providers by providing a standard protocol for transaction and settlement path negotiation with arbitrary financial instruments, currencies or assets. (Relevance: better connectivity, lower settlement fees, real time redundant financial routing, arbitrary instrument/currency/asset handling) How IFEX's proposed infrastructure differs from existing projects: - Not a currency, not a settlement-network, but a mechanism for bridging them. - Broader and more inclusive scope than existing vendor-specific APIs and conventional finance industry networking protocols. Global focus. No legacy 'features'. No artificial barriers to innovators. The hope is to move towards an open source implementation of the (work in progress) IFEX protocol that interoperates with major and emerging settlement networks for the benefit of all parts of the community. We have already had expressions of interest from representatives in a range of communities (Bitcoin, CES, Ripple, W3C Web Payments, digital currency exchange developers, etc.), and look forward your input on the mailing list. Happy Friday the 13th! Regards, Walter Stanish The IFEX Project http://www.ifex-project.org/ -- 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] Announcing the IFEX Project
Hi Walter, This could be of interest to the XChange project. See GitHub: https://github.com/timmolter/XChange The aim of this project is to provide a unifed API for applications to access financial exchanges. At present it supports Bitcoin exchanges (MtGox and Intersango are the primary focus with others to follow). It is in the very early stages of development, but is likely to be integrated into the MultiBit Bitcoin client (see http://multibit.org) in the near future (early prototypes are available directly from sources). One problem that the XChange development team faces is that each exchange rolls its own data model and uses its own protocol (web socket, socket IO, direct socket and so on). To provide a reference implementation of how an exchange should publish its data would be beneficial. Kind regards, Gary On 13 April 2012 10:34, Walter Stanish wal...@stani.sh wrote: The Internet Financial EXchange (IFEX) Project is an open body for the discussion and development of financial standards for the internet community. The project seeks to focus on enhancing interoperability between financial settlement systems of all types, including conventional financial systems, emerging digital currencies, alternative financial communities, and financial service providers. Interested parties are invited to review the proposals on the website at http://www.ifex-project.org/ and join the mailing list at http://group.ifex-project.org/ Two items on the site that may be of particular interest: (1) The latest version of the IIBAN Proposal (v1) for financial endpoint identification at http://www.ifex-project.org/our-proposals/iiban. This latest version includes initial IANA registry contents and a reference mechanism for financial endpoint transcription error correction. (Relevance: In contrast to settlement system-specific financial endpoint identifiers, IIBAN provides a democratically allocated, 13 character identifier that is already familiar in format to users in Europe and other countries and is theoretically compatible with conventional banking infrastructure in those regions. In addition, IIBAN is not tied to any specific financial commodity or settlement system, and provides strong protection against identifier transcription errors.) (2) The IFEX Protocol is a *work in progress* that hopes to bridge the gap between conventional financial systems, emerging digital currencies, alternative financial communities, and financial service providers by providing a standard protocol for transaction and settlement path negotiation with arbitrary financial instruments, currencies or assets. (Relevance: better connectivity, lower settlement fees, real time redundant financial routing, arbitrary instrument/currency/asset handling) How IFEX's proposed infrastructure differs from existing projects: - Not a currency, not a settlement-network, but a mechanism for bridging them. - Broader and more inclusive scope than existing vendor-specific APIs and conventional finance industry networking protocols. Global focus. No legacy 'features'. No artificial barriers to innovators. The hope is to move towards an open source implementation of the (work in progress) IFEX protocol that interoperates with major and emerging settlement networks for the benefit of all parts of the community. We have already had expressions of interest from representatives in a range of communities (Bitcoin, CES, Ripple, W3C Web Payments, digital currency exchange developers, etc.), and look forward your input on the mailing list. Happy Friday the 13th! Regards, Walter Stanish The IFEX Project http://www.ifex-project.org/ -- 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 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
