Can this be calculated in advance knowing the initial transaction size and
the number of signatures required?
Sure of course. You assume each signature to be placed in the tx is 73
bytes. Not very hard, but if the tx you get back from the API doesn't
contain such a 73-byte sentinel value then
On Wed, Mar 12, 2014 at 05:14:25PM +0100, Mike Hearn wrote:
Can this be calculated in advance knowing the initial transaction size and
the number of signatures required?
Sure of course. You assume each signature to be placed in the tx is 73
bytes. Not very hard, but if the tx you get
On Wed, Mar 12, 2014 at 12:02 PM, Mike Hearn m...@plan99.net wrote:
This is what bitcoind produces and expects by default, for a partially
signed transaction.
What happens if the act of filling out the signature pushes the transaction
into a higher fee level?
Partially signed and multisig
On Wed, Mar 12, 2014 at 12:41 PM, Mike Hearn m...@plan99.net wrote:
Partially signed and multisig transactions within bitcoind go through
the raw transaction API, which does absolutely nothing if the sig
pushes the TX to a higher fee level.
Well, we'll have to make sure this is carefully and
Gavin,
You have pretty much nailed my intent in both respects. This sets up a way
to negotiate the address and abstract away the nasty details of finding
public keys from bitcoin addresses, and provides a nice clean way for
redemption abstracting away the long strings of hex.
For redemption, I
On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote:
I very much like the idea of assuming each party uses HD wallets, that
certainly simplifies things greatly.
It also assumes a reality different from our current one.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote:
I very much like the idea of assuming each party uses HD wallets, that
certainly simplifies things greatly.
It also assumes a reality different from our
Sure, but I don't see wallets being able to _assume_ _remote_ parties
have an HD wallet for a long, long time. Interoperability common
sense implies the environment will be heterogenous, perhaps forever,
invalidating assume-each-party-uses-HD logic.
On Tue, Mar 11, 2014 at 9:51 AM, Gavin
On Tue, Mar 11, 2014 at 10:13 AM, Jeff Garzik jgar...@bitpay.com wrote:
Sure, but I don't see wallets being able to _assume_ _remote_ parties
have an HD wallet for a long, long time. Interoperability common
sense implies the environment will be heterogenous, perhaps forever,
invalidating
On Tue, Mar 11, 2014 at 10:23 AM, Gavin Andresen
gavinandre...@gmail.com wrote:
If the remote party is one of the parties involved in a multisig, and speaks
the Lets set up a multisig wallet together / Lets spend from a multisig
protocols, then it should be perfectly reasonable to assume that
(#include rant.h)
Right now, HD is hot air. Let us end the pie-in-the-sky assumptions
about how HD will save the day, with zero code to back it up. Bitcoin
Wallet purportedly fails to rotate addresses, a privacy ugly, because
of this Waiting For Godot situation. An attempt to add a simple,
Speaking from the MultiBit perspective, all future protocol development
(with the exception of critical security and network compatibility fixes)
will be put into a HD wallet. Over time we want to see MultiBit Classic
gracefully retire and be fully superseded.
Right now, HD is not out there but
You can follow HDW progress in bitcoinj on this branch:
https://github.com/bitcoinj/bitcoinj/commits/keychain
I've been working on it for a couple of months now. Electrum (Thomas V) is
also making good progress, and Trezor already uses HD wallets. I think most
popular end user wallets except
Trezor and Electrum may be earlier than this.
Sorry for not joining the discussion earlier.
I have postponed the release of bip32 features in Electrum due to
ongoing discussions with Trezor and bitcoinj developers.
I planned to post a summary in a separate thread, but this info is also
On Tue, 2014-03-11 at 16:18 +0100, Mike Hearn wrote:
You can follow HDW progress in bitcoinj on this branch:
https://github.com/bitcoinj/bitcoinj/commits/keychain
I've been working on it for a couple of months now. Electrum (Thomas
V) is also making good progress, and Trezor
Hello,
I wanted to just add a very brief note to this discussion, that presently
for multisignature creation and management (new transaction etc) I've been
using this: https://coinb.in/multisig/
There were some initial bumps in the road but they were worked out,
see full thread more or less
On Tue, Mar 11, 2014 at 10:13:48AM -0400, Jeff Garzik wrote:
Sure, but I don't see wallets being able to _assume_ _remote_ parties
have an HD wallet for a long, long time. Interoperability common
sense implies the environment will be heterogenous, perhaps forever,
invalidating
Hello people,
We are working on some of this stuff. We had some very early draft on
how we envisioned multisig happening. It is all implemented in Haskoin
available as multiple repositories in Github. I am happy to see this
gathering momentum.
Our multisig system uses BIP-0032 HD wallets, and
I might as well throw in a word about Armory. After our next release in
a couple weeks, we will be going full-speed at new wallets and BIP32
integration. Just like Jean-Pierre mentioned, we'll be using parallel
trees to generate P2SH addresses after sorting the keys
lexicographically. We plan
Ciphrex CoinVault (https://ciphrex.com) is currently using parallel trees with
lexicographic sorting of keys.
CoinVault is also using a partially signed transaction format whereby 0-length
placeholders are used for missing signatures in the transaction scripts. Once
all the required signatures
I was wondering if there would be merit in a kind of BIP for a payment
protocol using multisig?
Currently, setting up a multisig is quite a feat. Users have to exchange
public keys, work out how to get the public keys from their addresses. If
one of the parties are not savvy enough, an malicious
In my experience, best process for standardizing something is:
1) Somebody has a great idea
2) They implement it
3) Everybody agrees, Great idea! and they copy it.
4) Idea gets refined by the people copying it.
5) It gets standardized.
Mutisig wallets are at step 2 right now. BIP is step 5, in
No, this doesn't make any sense. Multisig outputs are a tool you use to
build helpful features, not a feature in and of themselves.
By all means create a nice protocol, implementation and BIP for something
like:
- Creation of multi-user money pools for managing an organisations funds
- Dispute
Payment protocol currently supports payments to multi-sig addresses.
In general, almost all wallet software sucks RE multisig. Just try
any of these actions in Bitcoin-Qt or another wallet:
* obtain a public key you control, given a bitcoin address
* easily share public keys
* easily share
As far as I'm concerned, the way forward is to scrap BIP 10 and build up
something new that is flexible and extensible. Also, my understanding
is that there may be room in the payment protocol for this stuff though
I'm not sure if it is really adapted well to all the steps: exchanging
public
All of that only melds with the payment protocol under an extremely
expansive definition of payment. The payment protocol is really
geared towards a direct one-to-one relationship.
We can make the payment protocol do all this, if you squeeze and push
and try reall hard; it is mainly a question
I was trying to use bip10 for multisig and coinjoin, but there was a
problem with it. I'll have to look back at my notes, but I thought I
sent you a message about it. And then real life swallowed my bitcoin time...
I think the bottom line was that it would be useful in the generic case
with
Multisig is orthogonal to the payment protocol (but payment protocol is
needed first).
There need to be protocols for:
a) Establishing multisig wallets of various sorts. See:
https://moqups.com/gavinandresen/no8mzUDB/
https://moqups.com/gavinandresen/no8mzUDB/p:ab18547e0
... etc. for a UI
28 matches
Mail list logo
