BIPs are either standards track (affects everyone, represents consensus),
informational (ie basically just summarizing the authors viewpoints on
things) or process.
My point is you can't have a credible standards track BIP until something
has been implemented end to end. I don't think it's a good
Sure, of course, as long as it's clearly labelled as just your thoughts, no
issues.
For dispute mediation the way I'd start is playing around with some UI
design stuff and a toy protocol underneath. Once the process is smooth from
the users POV (no seeing binary blobs disguised as text) then it
Hi Alan,
I have now read BIP0010 - one first idea is: add a link to it on the wiki (or
remove all bip links from the wiki... - we don't want two places for BIPs...)
I am not sure where you prefer the discussion on the content of the BIP - but
now you get it here, but feel free to redirect...
Michael, thanks for taking time to read the proposal. Responses are
inline, below.
I am not sure where you prefer the discussion on the content of the BIP - but
now you get it here, but feel free to redirect...
Likes:
* inclusion of prevout txout scripts - could prove handy
* that it is a
Hi All,
Along with the multisig/op_eval BIPs (11/12) I am considering how the actual
client functionality could be.
Some of you might already have the solution for this - if not I would like to
propose the following...
Lets consider the 2 of 3 multisig - and lets say I now have some coins
That's what my proposal was for, in BIP 0010:
https://github.com/genjix/bips/blob/master/bip-0010.md
However, I just found a minor problem with it that should be addressed
if we want to enable super-lightweight clients that only sign tx's
without needing the blockchain. Simply that the TxIns
Actually, I'm not sure if your solution works, because it relies on
broadcasting a tx to the network that isn't valid. I believe that the
first tx in your proposal will be rejected and thus you'll need to exchange
the tx's offline.
However, third-parties could pretty easily and conveniently
I don't think partially-signed transactions belong on the main Bitcoin
P2P network, mostly because I don't see any way of preventing somebody
from endlessly spamming bogus, will-never-be-completed partial
transactions just to be annoying.
... of course I write that and then start thinking
Crossing posts ;)
I like your idea! - It adds a pricetag to distributing a signature - and - as
you mention it will be part of the standard. It is only up to the clients if
they want to support it or not, but it does give you 0-conf world wide
instantaneous anonymously distribution of
One more thought on putting arbitrary stuff in the scriptSig:
Miners could decide to revolt and remove the extra scriptSig
information before including the transaction in their blocks. They'd
still get the full transaction fee, and the transaction would still
validate so the block would be
It's propably best to create a separate p2p network for off-band
information like this. No need to involve the blockchain with it.
- Joel
On Wed, 2011-11-09 at 16:18 -0500, Gavin Andresen wrote:
One more thought on putting arbitrary stuff in the scriptSig:
Miners could decide to revolt and
For now I think requiring direct-connection negotiation is best for these kinds
of things. A direct connection is OK in most cases, and more complicated
schemes will be more likely to fail. Maybe the IP transactions protocol can be
used.
In the future, I imagine that users of ultra-lightweight
The purpose of creating BIP 0010 now, is to encourage a standard that
developers /want/ to adopt, from the outset. Every developer who is
planning to touch multi-signature transactions, is going to have to
solve the problem of multi-sig tx exchanges, eventually. By offering an
excellent
13 matches
Mail list logo
