It certainly wouldn't hurt if there was a way to use OP_MULTICHECKSIG
with hash160 values instead... I doubt that's workable, though.
At the moment, I feel that the copy&paste size problem is much smaller
than the risk we take implementing such a huge change to the network. I
almost feel like,
On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki wrote:
> How could you have a 70 byte long address without a P2SH scheme? Is this a
> mistake?
... No it's not a mistake. P2SH _prevents_ needing long addresses.
Lets unpack the acronym "pay to script _hash_". Hashes only need to
be 128-256 bits i
On Sunday, January 29, 2012 12:10:41 AM Amir Taaki wrote:
> 2 compressed pubkeys
2 compressed pubkeys are 33 bytes each. Add 1 bytes for the N (n-of-m), 1 byte
for the address version, and finally the 4 byte checksum, you get a total of
72 bytes. But these are *bytes* - to get an address, you al
2 compressed pubkeys
- Original Message -
From: Amir Taaki
To: "bitcoin-development@lists.sourceforge.net"
Cc:
Sent: Sunday, January 29, 2012 4:52 AM
Subject: [Bitcoin-development] Quote on BIP 16
Gavin said:
"Part of the controversy is whether really long bitcoin addresses would wor
Gavin said:
"Part of the controversy is whether really long bitcoin addresses would work--
would it be OK if the new bitcoin addresses were really long and looked
something like
this: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)
I've a
On 01/28/2012 02:45 AM, Luke-Jr wrote:
> It's been implemented in many clients for nearly all 2011.
> Bitcoin-Qt is just behind the pace. Not relevant.
Bitcoin Wallet for Android implements only parts of this spec:
The hexadecimal notations (x) and exponent notations (X) feel horribly
redundant
Dear Bitcoiners,
I have been following some of the debate on the various BIP suggestions for
enabling e.g. multisignature transactions. ( First a little rant - it seems
like the discussion takes place in at least 5 different forums plus the IRC,
this is so annoying. Please keep the discussion a
I'd state it this way: a spec needs to be minimally complete
The subset implemented by bitcoin-qt allows description of *all* currently
desirable bitcoin transactions.
The rest of the spec is simply other ways to describe the same = redundancy
In case new transaction types are added, the spec ob
8 matches
Mail list logo
