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 sh
Fair enough. I'm not expecting anyone to just suddenly adopt BIP 0010
just because I published it to the wiki. I put it there to get feedback
on what it might be missing, and maybe we can converge on a good
preliminary solution. Then update it as we start playing with it and
find more featur
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
Maybe I'm new to this, but this doesn't make any sense. I thought the
point of the BIP was to collaborate to come up with a good solution.
That's exactly what I want to do before I implement it in my software.
After all, they are "Bitcoin Improvement *Proposals*." It seems like
EXACTLY what
Please don't create BIPs that don't have any actual implementation behind
them. Design discussion is fine but the mailing list works for that.
If I were going to implement escrow transactions in BitCoinJ it would not
matter what was written here. I'd just implement the design I thought made
sense.
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 prop
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...
L
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 solut
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
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
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 accepte
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 half-bake
Hi Gavin / Alan,
Agree that we would also need to consider these "half" transaction valid. At
least for the time being up to the lock_time, and one could have an extra
constrain - that the lock_time should be within e.g. 30minutes that would avoid
the will-never-be-completed cases.
My main con
> 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
> 1. from client1 I issue a transaction containing one of the signatures, with
> a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is
> now posted to the p2p network.
As Alan said, that won't work-- it will not be relayed across the
network because it isn't a valid transa
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 h
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 d
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 henc
18 matches
Mail list logo
