On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote:
I would like to discuss the following bitcoin protocol improvement proposal:
Adding request/reply id in all messages (in the message header,
based on what was done for the checksum field)
That seems like a
On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:
On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote:
I would like to discuss the following bitcoin protocol improvement proposal:
Adding request/reply id in all messages (in the message header,
This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless
protocols are more secure.
From: Pieter Wuille pieter.wui...@gmail.com
To: Gavin Andresen gavinandre...@gmail.com
Cc: bitcoin-development@lists.sourceforge.net
Sent: Thursday, April
On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote:
Hi,
I would like to discuss the following bitcoin protocol improvement proposal:
Adding request/reply id in all messages (in the message header,
based on what was done for the checksum field)
The original
Jeff elaborated the problems very well, but I just want to add this:
Your change is essentially relying (trusting) the server to track a piece of
information (your state). Anytime you start depending on another node in some
way, it is opening yourself up to be exploited. Nodes should be doing
I agree that it would be nice if the protocol stayed stateless.
I also think we should try and keep in our heads the aggregate
bitcoin-universe cost of implementing any protocol change; even a very
small change, something that truly only takes one hour of time from each
bitcoin node client
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
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
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
On Thu, Apr 12, 2012 at 7:24 PM, Amir Taaki zgen...@yahoo.com wrote:
Jeff elaborated the problems very well, but I just want to add this:
Your change is essentially relying (trusting) the server to track a piece
of information (your state).
No, it is more about distinguishing between
10 matches
Mail list logo
