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
11 matches
Mail list logo
