Thomas Kerin [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-03-27 to 2019-05-26
💬 Posted a total of 25 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP draft, soft/hard, BIP-45, BIP Draft, BIP Proposal
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5am

Profile Code

nprofile1qqsv673vh28mtznpxyssrp0jy4mf9attvehmyjleeuqke2925jj2uqgv38leq

Author Public Key

npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5am

Show more details

Last Notes

2023-06-07 18:18:23

- reply

📅 Original date posted:2019-05-26
📝 Original message:The scriptSig when evaluated populates the stack so opcodes can operate
on them. A witness is essentially a list of data elements, quite similar
to the script stack (the witness is passed in as the script stack in fact)
OP_0 when evaluated pushes a _zero length_ value onto the stack, hence
the 00 (the varlen) in the witness serialization. OP_1 (51 in decimal)
pushes 0x01 to the stack, so when serialized would be 0101.
It may help to consider the entire witness structure as
vector<vector<data element>> and it's length must equal the number of
inputs - so a non-segwit input must have a zero sized witness.
On 5/26/19 12:56 AM, Aymeric Vitte via bitcoin-dev wrote:
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:59:02

- reply

📅 Original date posted:2017-04-05
📝 Original message:A schism is just that: miners can't ameliorate a HF transition in the way they can censor transactions without permission. This is how miners became a convenient way to activate soft-forks.
So while BIP9 can indicate the later censorship (a soft fork) in a way that nodes can follow (or not) a hardfork always requires nodes to upgrade to the version increasing the degrees of freedom of the system.
Signaling is less useful here: the change is not opt-in and will require coordination; and the continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening.
On 04/05/2017 12:08 PM, Tom Zander via bitcoin-dev wrote:
On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote:
BIP 9 provides a mechanism for having miners coordinate softforks because they can make the upgrade process smoother this way. But the same is not true of hardforks: miners are essentially irrelevant to them, and cannot make the process any smoother.
Can you explain how miners are irrelevant if the upgrade is not a soft fork?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/a0b4d424/attachment.html>

2023-06-07 17:54:20

- reply

📅 Original date posted:2016-11-16
📝 Original message:BIP30 actually was given similar treatment after a reasonable amount of
time had passed.
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which
neither benefited nor improved bitcoin, but did document an event for
posterity.
This is not a hard fork. Removing ISM just means we've committed to
those soft-forks only locking into the chain we use now.
On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote:
> This sort of statement represents one consequence of the
> aforementioned bad precedent.
>
> Are checkpoints good now? Are hard forks okay now?
>
> What is the maximum depth of a reorg allowed by this non-machine
> consensus?
>
> Shouldn't we just define a max depth so that all cruft deeper than
> that can just be discarded on a regular basis?
>
> Why are there activation heights defined by this hard fork if it's not
> possible to reorg back to them?
>
> The "BIP" is neither a Proposal (it's been decided, just documenting
> for posterity), nor an Improvement (there is no actual benefit, just
> some tidying up in the notoriously obtuse satoshi code base), nor
> Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has
> been CoreCoin).
>
> e
>
> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp at gmail.com
> <mailto:jameson.lopp at gmail.com>> wrote:
>
>> Since "buried deployments" are specifically in reference to
>> historical consensus changes, I think the question is more one of
>> human consensus than machine consensus. Is there any disagreement
>> amongst Bitcoin users that BIP34 activated at block 227931, BIP65
>> activated at block 388381, and BIP66 activated at block 363725?
>> Somehow I doubt it.
>>
>> It seems to me that this change is merely cementing into place a few
>> attributes of the blockchain's history that are not in dispute.
>>
>> - Jameson
>>
>> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Actually this does nothing to provide justification for this
>> consensus rule change. It is just an attempt to deflect criticism
>> from the fact that it is such a change.
>>
>> e
>>
>> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak at gmail.com
>> <mailto:btcdrak at gmail.com>> wrote:
>> >
>> > I think this is already covered in the BIP text:-
>> >
>> > "As of November 2016, the most recent of these changes (BIP 65,
>> > enforced since December 2015) has nearly 50,000 blocks built on
>> top of
>> > it. The occurrence of such a reorg that would cause the activating
>> > block to be disconnected would raise fundamental concerns about the
>> > security assumptions of Bitcoin, a far bigger issue than any
>> > non-backwards compatible change.
>> >
>> > So while this proposal could theoretically result in a consensus
>> > split, it is extremely unlikely, and in particular any such
>> > circumstances would be sufficiently damaging to the Bitcoin
>> network to
>> > dwarf any concerns about the effects of this proposed change."
>> >
>> >
>> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> >> NACK
>> >>
>> >> Horrible precedent (hardcoding rule changes based on the
>> assumption that
>> >> large forks indicate a catastrophic failure), extremely poor
>> process
>> >> (already shipped, now the discussion), and not even a material
>> performance
>> >> optimization (the checks are avoidable once activated until a
>> sufficiently
>> >> deep reorg deactivates them).
>> >>
>> >> e
>> >>
>> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Recently Bitcoin Core merged a simplification to the consensus
>> rules
>> >> surrounding deployment of BIPs 34, 66, and 65
>> >> (https://github.com/bitcoin/bitcoin/pull/8391
>> <https://github.com/bitcoin/bitcoin/pull/8391>), and though the
>> change is a
>> >> minor one, I thought it was worth documenting the rationale in
>> a BIP for
>> >> posterity.
>> >>
>> >> Here's the abstract:
>> >>
>> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated
>> via miner
>> >> signaling in block version numbers. Now that the chain has
>> long since passed
>> >> the blocks at which those consensus rules have triggered, we
>> can (as a
>> >> simplification and optimization) replace the trigger mechanism
>> by caching
>> >> the block heights at which those consensus rules became enforced.
>> >>
>> >> The full draft can be found here:
>> >>
>> >>
>> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
>> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> >>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/794ee05f/attachment.html>

2023-06-07 17:52:52

- reply

📅 Original date posted:2016-08-24
📝 Original message:I want to pitch a use-case that might have been ignored in this discussion:
I don't think this protocol is only useful for hardware wallets.
Technically any website that wants to request public keys/signatures and
offload the responsibility for managing keys and signing to the user
would also find this valuable.
I hope we can move forward with a protocol that suits both the hardware
people, and the people who find signing transactions in browsers
unsettling.
Maybe we the focus should move away from only servicing hardware, and
asking if the motivation is better captured by "allow users pick their
own ECDSA implementation, hardware or software", then working out what
we need to get us there.
On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote:
> On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi
>
> > I have some experience with hardware wallet development and its
> > integration and I know it's a mess. But it is too early to
> define such
> > rigid standards yet. Also, TREZOR concept (device as a server
> and the
> > primary source of workflow management) goes directly against your
> > proposal of wallet software as an workflow manager. So it is
> clear NACK
> > for me.
>
> The current question – as already mentioned – is we ACK to work
> together
> on a signing protocol or if we NACK this before we even have started.
>
>
> ACK for Ledger. What's necessary to sign a transaction is well known,
> I don't see how driving any hardware wallet from the wallet itself or
> from a third party daemon implementing that URL scheme would make any
> difference, other than providing better devices interoperability, as
> well as easier maintenance and update paths for the wallets.
>
> --
> Nicolas Bacca | CTO, Ledger
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/ce0a856d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/ce0a856d/attachment-0001.sig>

2023-06-07 17:52:48

- reply

📅 Original date posted:2016-08-16
📝 Original message:Hi all,
Thanks again Jonas for starting this!
I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascript code / using Core's debug
console / coinb.in
Happily the procedure is largely the same, though I would echo Jochen's
point that there needs to be a way to request an xpub/public key.
The redeemScript and witnessScript are also required fields for full
validation & signing a transaction input if it's P2SH, or just the
witnessScript if it's bare V0_P2WSH
Since the output amounts are required, so maybe instead provide
serialized TxOut's? or Utxo's i.e: [txid, vout, amount, scriptPubKey].
The protocol ought to be as stateless as possible - it can't be assumed
whether the redeemScript and other details will ever be saved on the
device - so perhaps provide the redeemScript + witnessScript as the
final fields on the Utxo structure above.
I do think it enables two important choices for bitcoin users:
* it might be preferable to provide your own xpub vs generating a brand
new HD key to potentially lose.
* you could leverage the services provided by [random example]
GreenAddress without necessarily having to rely on signing code provided
by them, and so end up only having to trust only one ECDSA
implementation when interacting with a wide number of services
All the best
Thomas
On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing. A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware. Do you plan to have this in a separate
> standard or should this also be included here? Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary: All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme. So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions. Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
> witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
> scriptSig: <0 <32-byte-hash>>
> (0x220020{32-byte-hash})
> scriptPubKey: HASH160 <20-byte-hash> EQUAL
> (0xA914{20-byte-hash}87)
> (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output. Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
> Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing. A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware. Do you plan to have this in a separate
> standard or should this also be included here? Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary: All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme. So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions. Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
> witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
> scriptSig: <0 <32-byte-hash>>
> (0x220020{32-byte-hash})
> scriptPubKey: HASH160 <20-byte-hash> EQUAL
> (0xA914{20-byte-hash}87)
> (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output. Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
> Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.sig>

2023-06-07 17:49:08

- reply

📅 Original date posted:2016-02-11
📝 Original message:I wonder if this is possible as a soft fork without using segwit?
Increasing the sigop count for a NOP would be a hard fork, but such a
change would be fine with a new segwit version. It might require specific
support in the altcoin, which might be troublesome..
On 11 Feb 2016 20:05, "Tier Nolan via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There was some discussion on the bitcointalk forums about using CLTV for
> cross chain transfers.
>
> Many altcoins don't support CLTV, so transfers to those coins cannot be
> made secure.
>
> I created a protocol. It uses on cut and choose to allow commitments to
> publish private keys, but it is clunky and not entirely secure.
>
> I created a BIP draft for an opcode which would allow outputs to be locked
> unless a private key was published that matches a given public key.
>
> https://github.com/TierNolan/bips/blob/cpkv/bip-cprkv.mediawiki
> <https://www.avast.com/sig-email> This email has been sent from a
> virus-free computer protected by Avast.
> www.avast.com <https://www.avast.com/sig-email>
> <#-1229186329_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160211/1bf8b94b/attachment.html>

2023-06-07 17:48:10

- reply

📅 Original date posted:2016-01-26
📝 Original message:On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:
> There are already valid use cases for OP_RETURN, it only makes sense
> to fully support the feature. The only reason it's not supported now
> is because the Payments protocol came before OP_RETURN.
>
You keep saying OP_RETURN is new, but it has been there from day one.
It's purpose is causing script execution to end if encountered.
Since then, we have tolerated putting pushdata's after it, and even
raised the limit for the size of this data. It still doesn't mean every
proposal has to be rewritten to cater for a new allowance we give
OP_RETURN.
> I've also been exploring this area with key.run
> (https://git.playgrub.com/toby/keyrun) and want the functionality for
> voting based on aggregate OP_RETURN value. *Not* to store data on the
> blockchain, but to associate content pointers with transactions.
>
> I think that since OP_RETURN has already been approved and supported
> it doesn't make much sense for me to have to re-defend it from scratch
> here.
I'd generally agree with Luke. Removing the cost of this hurts bitcoin,
and ironically, your application to a certain degree. Just because you
can do a thing one way, it doesn't mean you should. Especially if your
applications success depends on people spamming OP_RETURN hashes of
every torrent they like.

2023-06-07 17:45:31

- reply

📅 Original date posted:2015-12-04
📝 Original message:1. Not relaying can cause problems. Gossip networks operate by
propagating new information (like a single new header), and refuse to
relay information if it's obviously invalid.
>From the POV of a full node, which will normally hear about the header
first, there's no point to not telling peers about this information.
It's likely in the interest of SPV wallets to hear about EVERY
contending chain, so they can go about their business deciding which is
correct.
2. The only difference between a block and it's header is the list of
transactions. There isn't anywhere else to put the flag but the header's
version. Which is good, because clients usually receive headers first.
3. "Signal would need to include some sort of proof" That's not the
point of this BIP. You can't prove the miner has or hasn't verified the
chain. What purpose would it even serve? If clients accepted this
'proof', they might ignore blocks they should pay attention to.
The BIP doesn't involve proof at all, it's just an indicator you can
chose to use or ignore.
On 04/12/15 12:44, Jannes Faber via bitcoin-dev wrote:
> nodes side by side, one of them doesn't validate in order to reduce latency

2023-06-07 17:42:21

- reply

📅 Original date posted:2015-10-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Jean Pierre,
This is a problem I've considered before, though I have to say I prefer
your solution.
The problem is, how can a person who restores his wallet from just a
seed restore
all his multi-signature addresses with other parties?
Your proposal is nice because all participants are equal, and it
minimalizes the data
required for recovery because it's deterministic, and the (extended)
public key is the first
piece of metadata you'll ask for from others.. Let it be the only thing
we need!
Regards amending BIP45 - BIP's are not amended after the fact, however
bad it may be
in retrospect. It might be best to write a BIP specifying a
"pseudorandom & deterministic
path generation for HD/multi-signature accounts"
TK
On 04/10/15 16:18, Jean-Pierre Rupp via bitcoin-dev wrote:
> I have a possible solution:
>
> Take all public keys encoded in the purpose-specific extended public
> keys (m/45') of all cosigners and sort them lexicographically, according
> to BIP-45. Serialize this information and calculate its HASH160
> (RIPEMD160 ∘ HASH256). Split the output in five 32-bit chunks, setting
> the MSB on all of them to 0. Use these 32-bit chunks to build a
> derivation path from the purpose-specific extended public keys. Treat
> this derivation path as if it was the purpose-specific extended public
> key in BIP-45.
>
> This scheme will avoid public key sharing, and as long as you share your
> purpose-specific extended public key only with your cosigners, it should
> be relatively hard for a passive observer to link activity between
> different cosigning accounts.
>
> On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
>> Hello,
>>
>> I have been reviewing BIP-45 today. There is a privacy problem with it
>> that should at least be mentioned in the document.
>>
>> When using the same extended public key for all multisig activity, and
>> dealing with different cosigners in separate multisig accounts, reuse of
>> the same set of public keys means that all cosigners from all accounts
>> will be able to monitor multisig activity from every other cosigner, in
>> every other account.
>>
>> Besides privacy considerations, HD wallet's non-reuse of public keys
>> provide some defence against wallets that do not implement deterministic
>> signing, and use poor entropy for signature nonces.
>>
>> Unless users are expected to establish a single cosigning account, this
>> scheme will result in reuse of public keys, and degradation of privacy.
>>
>> I understand that for convenience it is useful to have a single extended
>> public key that can be handed to every cosigner. This makes setting up
>> accounts or recovering from data loss a easier.
>>
>> I suggest that privacy & potential security degradation due to increased
>> public key reuse in the case of users with multiple multisig accounts
>> should get a mention in the BIP-45 document.
>>
>> Greetings
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJWEWDlAAoJEAiDZR291eTlFAkQALgiiKX+VzLOwLK13S0EcE0v
RZeC8hqS5AEi/wpOYC2H0TFaHhDqDgy7Pt7nTt/vfOr9QFbJm076I/iFIhLPPAWf
rRg5kzL6ebOyX1NLmALcNgE9L+Jwz09kdzLUj+xZesJfu1AiSMgND38vFq4CmRfg
YSnWI4iMSP3OoMO5Akjq7m9Ww/lENPDmxTrz2ET9KwKPEkjrdt3c0ipQcs+/vGuU
RfRCUwxcdu/0nl5JhltxMV6wUMjdJ3AGbamWZpL+vA+jT5paOd4ORjc64huQGtFQ
W7l8ynbbVqtXlYYs9mXCMm70316sdo5ZpOXzQmplwtuHWVYt9ssS1aLkBoLYCBtU
i95Ki79S2ooeIjDEqI6FKpgVnLTmUbhudg/vk7eA0+RoNh3SBEHV2HmZ5yTBNtjk
P2a2tRmrbe3CmrdogbJzaweZenzoR82PziF7DAb/2JqtccPSdTW/GrAGyCoe0O5B
PId/iELHKpQepvybp+5PI6q2Atgzut4ze+a2vBiXjbiU3j0sX0XWg5fu9R9Ea1Bw
5+BY71GSa20OTDYEsp5esrl5/AUFj4ivB2OWFok77nGi2rTK+rKL3qMvbmYjAKUV
rWN4m6r8pU2hdhBCEJkXjg57whiMYn5w7ILlrbK5lLEu5qo0txoRtBPaid+y4mkK
moZU0LtvSQSX6ZaojQ/v
=Vs6z
-----END PGP SIGNATURE-----

2023-06-07 17:41:55

- reply

📅 Original date posted:2015-09-30
📝 Original message:Who is funding this?
Why not fund Core development?
On 30 Sep 2015 7:37 am, "Richard Olsen via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> All,
>
> We are looking for participants in a Bitcoin related competition: the aim
> is to build a trading platform (initially for foreign exchange, other
> assets will follow) which lets participants settle their trades through the
> blockchain via coloured coins. To facilitate a quicker trade
> reconciliation, the use of a sidechain is a suggestion but by no means a
> requirement. There will be an online briefing event today where we will
> outline the requirements in more detail, though much of it we have posted
> on our website www.lykkex.com .
>
> As we want this to be a community driven effort rather than something
> turning into a proprietary technology, all contributions will be made
> available under a MIT license on Github.
>
> I look forward to answering your questions at the online briefing event
> or over email,
>
> Thank you and kind regards,
> Richard Olsen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/5e34964e/attachment.html>

2023-06-07 17:40:24

- reply

📅 Original date posted:2015-09-15
📝 Original message:Something very similar was posted not too long ago.
Long and sort of it is, there is no point in saying you priced in GBP, etc,
because it can vary from exchange to exchange.
To be honest, adding more things to consider at checkout time confuses
things; why not just specify the amount of Bitcoin you wish to be paid?
On 15 Sep 2015 11:11 am, "John Bailon via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> I'd like to propose a BIP for a standard URI scheme to allow wallet
> operators that implement instant exchange or pegging to other currencies,
> cryptocurrencies or asset classes to allow for interoperable communications
> of rates and other pertinent information.
>
> The idea is to include in the wallet address as parameters information
> that supplements the presentation of a proposed transaction.
>
> For example, a wallet operator that instantly exchanges bitcoin to gold
> would present a wallet address as follows:
>
> bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV?currency=xau&rate=0.2084&expires=1458432000
>
> Wherein:
> <currency> : the currency, cryptocurrency or asset that the transaction
> will end up as encoded in ISO 4217 if applicable.
> <rate> : the bitcoin to <currency> rate as dictated by receiving wallet
> <expires> : unix timestamp of when the rate loses validity
>
> This would allow the sending wallet the ability to present up-to-date
> exchange rates. When, for example, a wallet operator that pegs to the USD
> scans the address above, it would be able to present to the user the
> following information:
>
> 1. USD to XAU rate
> 2. How much XAU will be received by the address
> 3. How long before the rates expires
>
>
> Thoughts?
>
>
> Regards,
> John
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150915/7a45e450/attachment.html>

2023-06-07 17:40:12

- reply

📅 Original date posted:2015-09-14
📝 Original message:I think it would be more akin to bip70. I have a similar proposal, largely
already written up around this. I'm very interested in having this for
multi signature wallets.
On 14 Sep 2015 8:06 pm, "Arthur - bitcoin-fr.io via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
> I realized that there isn't any way to ask for a signature (or to verify a
> message) as easily you can do when requesting a payment using a bitcoin URI
> scheme (BIP0021).
> I think a URI scheme to use the signing tools in bitcoin core might be
> useful, and with a proper consensus it could become available in most
> bitcoin clients who already support message signing/verifying and payment
> url (or QRCode) and enable new uses of bitcoin signatures.
> A way to gain proper consensus is going through a BIP, so that's why I'm
> here: to present my idea publicly before going any further (draft BIP and
> reference implementation).
> Some thoughts
> - like BIP0021: "Bitcoin clients MUST NOT act on URIs without getting the
> user's authorization." so signing requires the user to manually approve the
> process
> - it could use the same URI scheme than BIP0021 with an additional
> parameter (ex: signaction=<verify/sign>) or use another one like BIP121
> (ex: btcsig:)
> PS : I'll also post a topic in "Development & Technical Discussion"
> section on Bitcointalk
>
> --
> Arthur Bouquet
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150915/bef6bd06/attachment.html>

2023-06-07 17:36:35

- reply

📅 Original date posted:2015-08-21
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I submitted the pull-request for the median-past timelock BIP just now
https://github.com/bitcoin/bips/pull/182
Any luck finding the link to this discussion? It would be nice to
include this for posterity.
On 19/08/15 02:08, Mark Friedenbach wrote:
> You are absolutely correct! My apologies for the oversight in editing. If you could dig up the link
though that would be really helpful.
>
> On Tue, Aug 18, 2015 at 6:04 PM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org
<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Tue, Aug 18, 2015 at 02:22:10AM +0100, Thomas Kerin via
bitcoin-dev wrote:
> > ==Acknowledgements==
> >
> > Mark Friedenbach for designing and authoring the reference
> > implementation of this BIP.
> >
> > Thomas Kerin authored this BIP document.
>
> IIRC Gregory Maxwell came up with the actual idea in question,
during a
> discussion between myself and Luke-Jr about incentives related to
nTime
> on #bitcoin-dev or #bitcoin-wizards. He should get credit for it; I'll
> see if I can dig up a link to the discussion for historical interest.
>
> --
> 'peter'[:-1]@petertodd.org <http://petertodd.org>
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
<mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJV1we8AAoJEAiDZR291eTlkdwP/Rv3wE1kUSGe62Im9VIm49ZW
hL71+9+C9BMyRWfUjizqGi/FgWzKlS5dVrKJdNnzV5g1KjZYIWF7Zy824Gnv8hrE
zW2pJc4vgu8igjtO+Qm/Wi+yy5WNjQ9qhRO+chELx4JLvD5JalagrBP2V693gNNd
g2K6fjXlogx/Rw4mK2pxYlUxgaWf2j+iJ2v09238+aWuXruTirpf/HJ70Pxwm4oq
LvJervkEUtUJLiwqsiwAQwqjesFPfuV1nYCi48G0/QfYK7tpajGD7NkO89RBNnP8
P6XGouBqulSvzc3QgtQqPIfOdEtV2Qi8Aohv+ebttaxFM8LSycvG9wxrQ+5Y/F4w
h7HDkn7ziM8MVS+KfFuuyfKxhDKdfpgu61r1YTzt7TyMSzdvQ8c9XhYCN3/AvL9S
6kwOeWTONVNpQbhI3WkzRPpTpaInLm1LkeXWuZVy9jbUtD8tlI0a6HmLzIrhcpdS
keOZiH1eV1nritrEFeToaTNL09MjyfdJk0kN9dr6fI3eOV/cPQkY52iCHWLMj+WY
X2wWwMPiNzfkgmMC+GvcQNmGSklaIr2OoUuT92q4M1pVi24vPNSvVy00W4+klXgK
UsCIMzo+n1OLRV8I1zuYkCAwOKzzJlvMw/7bggLxhuNsLubtM0HvDjq0uquE+zu6
BO12PmW8qOA2KqyeYEVn
=1Fst
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/8b3a13b1/attachment-0001.html>

2023-06-07 17:36:33

- reply

📅 Original date posted:2015-08-17
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
In collaboration with Mark Friedenbach, we have drawn up a proposal for
using
the median time of the past 11 blocks in locktime calculations.
<pre>
BIP: XX
Title: Median time-past as endpoint for lock-time calculations
Author: Thomas Kerin <me at thomaskerin.io>
Mark Friedenbach <mark at friedenbach.org>
Status: Draft
Type: Standards Track
Created: 2015-08-10
</pre>
==Abstract==
This BIP is a proposal to redefine the semantics used in determining a
time-locked transaction's eligibility for inclusion in a block. The
median of the last 11 blocks is used instead of the block's timestamp,
ensuring that it increases monotonically with each block.
==Motivation==
At present, transactions are excluded from inclusion in a block if the
present time or block height is less than or equal to that specified
in the locktime. Since the consensus rules do not mandate strict
ordering of block timestamps, this has the unfortunate outcome of
creating a perverse incentive for miners to lie about the time of
their blocks in order to collect more fees by including transactions
that by wall clock determination have not yet matured.
This BIP proposes comparing the locktime against the median of the
past 11 block's timestamps, rather than the timestamp of the block
including the transaction. Existing consensus rules guarantee this
value to monotonically advance, thereby removing the capability for
miners to claim more transaction fees by lying about the timestamps of
their block.
This proposal seeks to ensure reliable behaviour in locktime calculations as
required by BIP65, BIP68, and BIPXX (OP_CHECKSEQUENCEVERIFY).
==Specification==
The values for transaction locktime remain unchanged. The difference is
only in
the calculation determining whether a transaction can be included.
Instead of
an unreliable timestamp, the following function is used to determine the
current
block time for the purpose of checking lock-time constraints:
enum { nMedianTimeSpan=11 };
int64_t GetMedianTimePast(const CBlockIndex* pindex)
{
int64_t pmedian[nMedianTimeSpan];
int64_t* pbegin = &pmedian[nMedianTimeSpan];
int64_t* pend = &pmedian[nMedianTimeSpan];
for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex =
pindex->pprev)
*(--pbegin) = pindex->GetBlockTime();
std::sort(pbegin, pend);
return pbegin[(pend - pbegin)/2];
}
Lock-time constraints are checked by the consensus method IsFinalTx(),
or LockTime() under BIP68. These methods take the block time as one
parameter. This BIP proposes that after activation calls to
IsFinalTx() or LockTime() within consensus code use the return value
of `GetMedianTimePast(pindexPrev)` instead.
A reference implementation of this proposal is provided in the
following git repository:
https://github.com/maaku/bitcoin/tree/medianpasttimelock
==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and 66,
with the
same thresholds, but for block.nVersion = 4. The new rules are in effect for
every block (at height H) with nVersion = 4 and at least 750 out of 1000
blocks
preceding it (with heights H-1000...H-1) also have nVersion = 4.
Furthermore,
when 950 out of the 1000 blocks preceding a block do have nVersion = 4,
nVersion = 3 blocks become invalid, and all further blocks enforce the
new rules.
It is recommended that this soft-fork deployment trigger include other
related
proposals for improving Bitcoin's lock-time capabilities, such as BIP
65, BIP68
and CHECKSEQUENCEVERIFY.
==Acknowledgements==
Mark Friedenbach for designing and authoring the reference
implementation of this BIP.
Thomas Kerin authored this BIP document.
==Compatibility==
Transactions generated using time-based lock-time will take
approximately an hour longer to confirm than would be expected under
the old rules. This is not known to introduce any compatibility
concerns with existing protocols.
==References==
[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65:
OP_CHECKLOCKTIMEVERIFY]
[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68:
Consensus-enforced transaction replacement signaled via sequence numbers]
[https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIPXX:
CHECKSEQUENCEVERIFY]
==Copyright==
This document is placed in the public domain.
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJV0oi8AAoJEAiDZR291eTl2soP/1MOjgQDncoUdMptqfeqMLfU
ewENNPLQwXXje7PFn/gIVa+Ghxu+f9rrRHt6v8Udd4wsnDTqhz2gV6dKCyF0K4IS
seLTH2kyTfPGm1KOp6WSwvxoyc5iWLBH4wkSm4oI9WmXkLzDq0yEYUDE8t9yNYwf
0Fgrg1KPIP4bhoxWchEa237rrH/qTh0Zdxdj/N0YCrX9u4fBy+xoTM6gnt0bFCK2
SaGXvC8PsA23gkJjjwFnWh/JU0Q5BJTElUsq1re3gmwcnLNKyB5cx0bFephk2pFd
NC3rqEIIVPd7aLs+lWmD4/NXdm+VtUEQo3MmQ1YW5zwjeoJxZhfMfXwmQw3vw2f7
FSyExUXNNwh2lMoLCcWvWWEOKYaSV9iLX4TacvpbOSDQgz3rDl3iqeLmSgp3S8M3
Se1S9AzilJsT0jIe2Ob2hu/gXEXeBmI9k2kRJELSaIFgCWadUky63NwNNfRipiBq
USroBIym2dpXFLygcwgwf6F/yAYYg6/5QiUKclhqvxArxVEcijw18SHGZVYpW83S
Q0mzJnRVGF7yscJl84zHyAj5QMWoMFgKSqFbOLcmNDUPLoaFJxAGezGCLXNaHinA
LY5Qp0t0Vg4hXi6QcCiWv2U8E1K4oN5VZNSlagUyXsAHd3c4icZTVj+TTWKJ7GLB
Gmbe3i9G90rpgDbHWXFq
=EQdY
-----END PGP SIGNATURE-----

2023-06-07 15:48:09

- reply

2023-06-07 15:48:08

- reply

2023-06-07 15:43:17

- reply

📅 Original date posted:2015-07-31
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I really think there should be a document before a BIP number is assigned.
On 23/07/15 12:10, Jorge Timón via bitcoin-dev wrote:
> Discussions about whether to get miner's confirmation on
> uncontroversial hardforks or not, and about whether to use nHeight,
> nMedianTime or just use nTime are spreading all around. Hopefully
> getting a BIP number (even though this is still a draft) will help
> concentrating discussions about deployment of uncontroversial
> hardforks to a single place.
> Greg, can I get a BIP number for this?
>
> On Sun, Jun 21, 2015 at 12:54 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>> On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>>
>>> You mean the timewarp fix can be coded as a softfork instead of a
>>> hardfork? How so?
>>
>>
>> The easiest would be a rule requiring that all blocks are within 1 day of
>> the median of the previous 11 blocks. At the moment, you need to be
greater
>> than that value. This would add a condition at the other end.
>>
>> It wouldn't be a total fix, but it would protect against the exploit.
>>
>> A stricter soft fork would be that the two blocks in question have to
have
>> the same timestamp. This would force the off by 1 and the correct
value to
>> give the same result.
>>
>>> If that's the case, do you have a better candidate?
>>
>>
>> I think it is fine, since fixing it "right" does require a hard fork,
>> especially if it is only to show a non controversial hard fork.
>>
>>
------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVu7MlAAoJEAiDZR291eTlGnkP/jG/oW2PfPwDt6t+1UJ7P1LO
/NDtpUI5wiPQ6aXBmqKSx7FxZ9QJQM1tB1SpGhFosOXXSiYLjNos0l0S6oRw7yGC
LzXmbNTL863F0vOfRU35yxQJbcUi6gOHk8E/oo2X/V+BgAoc4cweK4080C8k1vki
7kPPiSek4erMo7TVNb5vsHkOI6QXhKNV/lFuSOuRAwklRY5vL2BZi56HekOnoFdr
iHebmRrjL7R+IFzasnWtHh6KGs51tg02SOPTMXwJ/H+xDqN9LXk/DJUbp9QhEa+t
TwojQBj7D+HMWavaLRVjVQOcvxxm3PTwZHmHxzfrx3kG5nsZNWrebWElHikW8BuW
dg6Yq/6mIW59HPyNSc5HCBnNonKpZebsQU0rdzOcwWFdk0SZ1TuKrYjNu9uDVGpo
od21hIpGYa1FTxk1HQ63PMf5SKmLunvHOehWw8pmXy44k3WVkABAhi7YNIbA8Qvj
DJ+k9wtypDBraoQh1yur4r1cBbBVcbaxRwv42MBGhtTXPVzRu6CikJNwa65z1AqT
AM3av8+IIgiq9dYn1uzDh1BQGSsB5YYQZ3QDHpM1DxCvjXvmgf4RdFwC0Q0B0X3S
jnWebazQvxN9qsylHAJeTZ0+rJCsx+R3Fl2Myasz/c3a6uaYJVi9/N0j3yRm1EYt
3Py8BGrArkIe3CeXaTCV
=Yh0o
-----END PGP SIGNATURE-----

2023-06-07 15:43:13

- reply

📅 Original date posted:2015-07-25
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
FWIW, the 6 confirmations figure came from a modest estimate of a miner
with 10% of the hash rate, such that there is < 0.1% probability of the
transaction being undone.
I wonder at times if this figure should fluctuate with the hashrate of
the largest player. Presently, AntMiner has 20% of the hashrate,
requiring 11 blocks to give you the same certainty. And previously when
GHash.io had 45%, the number of blocks to wait would be 340 - over two days!
With this in mind, I would be wary about publishing these numbers as
they are prone to change.
On 25/07/15 03:18, gb via bitcoin-dev wrote:
>
> Validated - (seen on network)
>
> Settled/Cleared - 1 conf
>
> Finalised - 6 confs
>
> On Sat, 2015-07-25 at 00:37 +1000, Vincent Truong via bitcoin-dev wrote:
>>
>> "Fast transactions"
>> Fast transactions implies it is slower than Visa, and Visa is
>> 'instant' by comparison from the spender's POV. Bitcoin is still very
>> instant because wallets still send notifications/pings when
>> transactions are first seen, not when it goes into a block. We
>> shouldn't mislead people into thinking a transaction literally takes
>> 10 minutes to travel the globe.
>>
>> Maybe this feels like PR speak. But being too humble about Bitcoin's
>> attributes isn't a good idea either.
>>
>> If we're going to look at perception, image and expectations, perhaps
>> we can start to look at redefining some terminology too. Like
>> confirmations, which is an arbitrary concept. Where possible we should
>> describe it with finance terminology.
>>
>> "0 conf transaction"
>> 0 conf is the 'transaction' - just the act of making an exchange. It
>> doesn't imply safe and I believe using the word 'settle' in place of
>> confirmations will automatically click with merchants.
>>
>> "1st conf"
>> A 'confirmation' is a 'settlement'. If it is 'settled', it implies
>> final (except by court order), whereas confirmation usually means 'ah,
>> I've seen it come through'. I rarely hear any sales clerk call credit
>> card transactions confirmed. More often you will hear 'approved'
>> instead. Although 1st conf can be overtaken, so...
>>
>> "n confirmations"
>> This term can probably stay since I can't come up with a better word.
>> Settlements only happen once, putting a number next to it breaks the
>> meaning of the word. "Settled with 4 confirmations" seems pretty
>> clear. Alternatively I think instead of displaying a meaningless
>> number we ought to go by a percentage (the double spend improbability)
>> and go by 'confidence'. "Settled with 92% confidence." Or we can pick
>> an arbitrary number like 6 and use 'settling...' and 'settled' when
>> reached.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVs6WBAAoJEAiDZR291eTlmA4P/1uARaRISbq6ZN9gSy+Tsq+N
aooU/irB06IdTnOrxqW/iAS2M2SxqTq5/M6PVMK6LAefRuAAYE6KeDQb5/n2QWIM
vBgVeDPBVkq+KHOJlaswO962kl/Mr9TC9xb9hbfB9IdQACLbSwfyQ+cYNY3RRnvl
Jkgj7boVjA4o/lE/BxTshPTriQNtVl9c6OxOfXsZotpTphSlMGIUrEHR/t2rjbcV
yPeTwHFIAaqcCMivYvfsk24JD9DiygwGVvjqwQPsNF8H9y6xor+QAc23aaD8WPi1
1J91bfRxJWghxyGmsPx1G/EVi/0retE1tZdkyqlahThdSACZtUfA997V0KT/DrdH
svHjNclViHExWGL7cUd2s9AMjIz1vr0tUGxvU7KsZT2kEXP0qp96mjIfo0TkZbUb
xsYMKujE8ZRpn8+CakfeT7RMtAhGIRvtPDQDm+Qv84A6JOufrgF4C0B00/9kERIe
g5hH2YG2R4YD40G4wtxEGpk/2jcdWc37CJ+T17+7m8MgPFNmX8V5YsAFwfPe6iAt
1QON3crilFRYCawYcOypbjh4hb5O5Usvg0msUrvzaRJ7Gj6K/SmFdG4hOepCHbPc
g2Bu15ifdmaCa8ssZHK+HJmhbGTMkDqdBnv2lziR8TXIC/se2+y7Iasz4eVkfG1/
RkDgokFOv7YA5aqp5ZHn
=VgWS
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150725/efb395b9/attachment.html>

2023-06-07 15:35:32

- reply

📅 Original date posted:2015-05-22
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I wonder are there any other blockers or modifications that need to be
made for this to be merged?
Latest version of the document:
https://github.com/afk11/bips/blob/213e8a27a3a2eaaf44f79221a9f9f888af002801/bip-0067.mediawiki
On 13/02/15 23:43, Thomas Kerin wrote:
>
> On 12/02/15 22:13, Luke Dashjr wrote:
>> Where is the Specification section?? Does this support arbitrary
scripts, or
>> only the simplest CHECKMULTISIG case?
>
> The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.
>
> You're right, we're missing a Specification. I have tweaked the
document to cover this now.
>
>
>
> On 13/02/15 07:53, Peter Todd wrote:
>> It might be enough to rewrite this BIP to basically say "all pubkeys
executed by all CHECKMULTISIG opcodes will be in the following canonical
order", followed by some explanatory examples of how to apply this
simple rule. OTOH we don't yet have a standard way of even talking about
arbitrary scripts, so it may very well turn out to be the case that the
above rule is too restrictive in many cases - I certainly would not want
to do a soft-fork to enforce this, or even make it an IsStandard() rule.
>
> It would be interesting, but I agree it should not be brought into
these validation rules - just a convention for people to follow for now.
I think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons.
>
>
> --
> Thomas Kerin
> -------------------------
> My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQJ8BAEBCgBmBQJVX2ciXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVlOwP/1w/Omr/6jGyi7spqW22HQ7P
4+lNNzcsWp5/pv8e6YelUOSYiHuh/KxRoFfWL+wF+PNS2EtjRxSsXxg/R2nMft7B
JQLNmIG6zTzVg/lhVObeSslXaia7repZxZ1S4nyEcs8rDVt7kkNnNguFOeONF95O
3usCnrch+QbQacIt9StySAz155u1SuHeSmGmA/fRGLfArndXDdN0fYwE1KGyv5wm
LqZ1PQfmYaCc0TUKRvpDRuc/+KF7q1fDMzuP9mZ3WiPdvTDKCXSRxYfbQYJdxplg
AC0CFiOne+DXgiBdTOIcs9pcp1/6SyZs75Bkpv71AxBCmTlRTuYpsfH7O3VuZBGP
FrN/4BMYnzMbGnNmvZwerUKH59MmzZTAzLSwZlpvj7ZxRks6KOp1CHInFWQlHAXJ
O5c5McvqSdQ0rPHLcQ4DwB00Q1els18NRULjxdsTfLrT32birIXn3M1Hn/Q9d8Sa
N+Y/cfXkojf4rJt75+XwjLyHECwS378ZFC8lfs1m/B3VSQxTtTZWA8905a1IRv/F
nPQ2eaxBrFjm4OatE5lx+I/xmVAQuybG54UdcZGaKVXJbMg3sOslcYg7eA77pmR5
7jRoRU+q7GhiRsUmxSkD+57FfhaMzX7iUl4xe3YK14KUS/pONuv0USC9to8a62kA
gz9kb4pJMEhTtZNv7z9C
=iq37
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150522/09d9bd89/attachment.html>

2023-06-07 15:32:36

- reply

📅 Original date posted:2015-04-30
📝 Original message:When dealing with any of the libraries or API's it's helps to know
what's going on under the hood. I find these pages to be invaluable.
https://en.bitcoin.it/wiki/Transactions
https://en.bitcoin.it/wiki/Protocol_specification
https://en.bitcoin.it/wiki/Script
On 30/04/15 11:28, Jorge Timón wrote:
> Well, if you're interested in learning java while learning bitcoin,
> probably you should be looking at https://github.com/bitcoinj/bitcoinj
> or one of its related project (like the android bitcoin wallet based
> on it).
> There's a getting sterted page: https://bitcoinj.github.io/#getting-started
>
> These links my be useful too:
>
> https://bitcoin.org/en/bitcoin-for-developers
> https://bitcoin.org/en/developer-documentation
>
>
> On Thu, Apr 30, 2015 at 11:35 AM, Telephone Lemien
> <lemientelephone at gmail.com> wrote:
>> Hello,
>> I'm a beginner in Bitcoin and I want to know, what are things those allo me
>> to understand Bitcoin protocol and make progress in java to become a good
>> developper.
>> Please tell me how I can begin.
>> Best regards
>>
>> 2015-04-30 10:08 GMT+02:00 Jorge Timón <jtimon at jtimon.cc>:
>>> As Mike says it depends on your interests. But one thing that is almost
>>> always welcomed is improving the tests, and it is unlikely that it conflicts
>>> with other people's PRs (unless they're changing that part of the code and
>>> need to update those tests. Improving documentation is also good and you can
>>> do that while reading the code. Usually I just start cloning, compiling and
>>> changing things as I read, "if I understand this correctly, this change
>>> should not break the tests, if I understand this, this other change should
>>> break the build", etc.
>>> But again, is up to you.
>>>
>>> On Apr 16, 2015 2:34 PM, "Mike Hearn" <mike at plan99.net> wrote:
>>>> Hey Gabe,
>>>>
>>>> That's diving into the deep end for sure! :)
>>>>> What are some current things that are lacking in Bitcoin core? Or am I
>>>>> better off making something else for the ecosystem?
>>>> That depends on your interests.
>>>>
>>>> Many of the highest priority tasks in Bitcoin Core are rather
>>>> complicated, unfortunately, even for people with experience. You can consult
>>>> the issue tracker to get a feel for it.
>>>>
>>>> Alternatively, there are lots of wallet apps out there and plenty of more
>>>> straightforward projects on them. However they may have less of a research
>>>> flavour.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>>>> Develop your own process in accordance with the BPMN 2 standard
>>>> Learn Process modeling best practices with Bonita BPM through live
>>>> exercises
>>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
>>>> event?utm_
>>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Thomas Kerin
------------------------------------------------------------------------
My PGP key can be found here <http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150430/8e0c1ee5/attachment.html>

2023-06-07 15:31:46

- reply

📅 Original date posted:2015-03-11
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
I just created a PR on bitcoin/bips for a proposed standard for creating
standard multisignature P2SH addresses given m, and a set of public keys.
https://github.com/bitcoin/bips/pull/146
I used BIP0090 as a place-holder, but I would like to request a BIP
number for this now.
All the best,
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQJ8BAEBCgBmBQJVACrVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVkGgQAIUpyA3PsNjCA99W1HwFI7Ra
+g+JTtXBdhJSvVpv67TlaPZzp4LP7rRW/U1Nv0JYvhpQZTsV/xcMSKpy56d3S50M
Yvxwy51Aco1LEPC1vuiE2aJ8lDwCrXJMxJwfdBp6iNwf0huZNrsqZNKUHwMepePj
PYlGBkyfnp7QXo0ZkYBCJ2yerir5emKap3AibijRtkTrq6K1+YRk/9UZHllZSmmk
/B8n6xy/+v65uoAriVwKkX7H0bXmNTjleMzXbm/+Zhh9qfEnp2zqGmBIk5ooV5x4
3Flb76EYAMXibfAQ2+NPoCiPxCDIEWIsWqyzOC9zWX1QZN55qT3s/p7olYtaYheD
mf2xZ2pI/cIxpiYGfFEn4C/l0dOCNFLfElgsFcn4RsqRE41Grm+MGAPrf7S5bstp
TPIALOoVShucHaMvD/6sdK51hC54MKktNDtzTIumnWtOMwTy9qbELIcNvD8DaFe8
7FVZ7Vndj2FfXCNBF2EHzmy4D4+BE2YZ07pLQVUrc79oidUTs/099PsnUNOEYz0l
Y4IL/5qJMep9PJlj+IlbfXFX0zfTLJF7vJgjYMybr0iKP66iTtuHc46QFxTRyIhC
dMLXbSqm9X5zEc1j9Q50dSE5rqIT3/gkQe7nWFwf4xC7hlLAXSm8HuqwRSkZdP19
2byvsvoZ+4D4drXHXXpi
=QU8i
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150311/9a51df90/attachment.html>

2023-06-07 15:30:31

- reply

📅 Original date posted:2015-02-12
📝 Original message:Not sure what happened there - I'll drop the PGP.
Hi all,
I have drafted a BIP with Jean Pierre and Ruben after the last
discussion, related to a standard for deriving a canonical
pay-to-script-hash address given a set of public keys and the number of
signatures required. There have been two or three discussions about it
on the mailing list to date, and various services already carry out this
process. I hope a BIP to describe this process will allow services to
declare themselves as BIPXX compliant, working towards interoperability
of services and simplifying the derivation of scripts and their
addresses by all parties.
BIP: XX
Title: Deterministic Pay-to-script-hash multi-signature addresses
through public key sorting
Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
Status: Draft
Type: Standards Track
Created: 8 February 2015
==Abstract==
This BIP describes a method to deterministically generate
multi-signature transaction scripts. It focuses on defining how the
public keys must be encoded and sorted so that the redeem script and
corresponding P2SH address are always the same for a given set of keys
and number of required signatures.
==Motivation==
Most multi-signature transactions are addressed to P2SH
(pay-to-script-hash) addresses, as defined in BIP-0016.
Multi-signature redeem scripts do not require a particular ordering or
encoding for public keys. This means that for a given set of keys and
number of required signatures, there are as many as 2(n!) possible
standard redeem scripts, each with its separate P2SH address. Adhering
to a an ordering scheme and key encoding would ensure that a
multi-signature “account” (set of public keys and required signature
count) has a canonical P2SH address.
By adopting a sorting and encoding standard, compliant wallets will
always produce the same P2SH address for the same given set of keys and
required signature count, making it easier to recognize transactions
involving that multi-signature account. This is particularly attractive
for multisignature hierarchical-deterministic wallets, as less state is
required to setup multi-signature accounts: only the number of required
signatures and master public keys of participants need to be shared, and
all wallets will generate the same addresses.
While most web wallets do not presently facilitate the setup of
multisignature accounts with users of a different service, conventions
which ensure cross-compatibility should make it easier to achieve this.
Many wallet as a service providers use a 2of3 multi-signature schema
where the user stores 1 of the keys (offline) as backup while using the
other key for daily use and letting the service cosign his transactions.
This standard will help in enabling a party other than the service
provider to recover the wallet without any help from the service provider.
==Implementation==
For a set of public keys, ensure that they have been received in
compressed form, sort them lexicographically according to their binary
representation before using the resulting list of keys in a standard
multisig redeem script. Hash the redeem script according to BIP-0016 to
get the P2SH address.
==Compatibility==
* Uncompressed keys are incompatible with this specificiation. A
compatible implementation should not automatically compress keys.
Receiving an uncompressed key from a multisig participant should be
interpreted as a sign that the user has an incompatible implementation.
* P2SH addressses do not reveal information about the script that is
receiving the funds. For this reason it is not technically possible to
enforce this BIP as a rule on the network. Also, it would cause a hard
fork.
* Implementations that do not conform with this BIP will have
compatibility issues with strictly-compliant wallets.
* Implementations which do adopt this standard will be cross-compatible
when choosing multisig addressses.
* If a group of users were not entirely compliant, there is the
possibility that a participant will derive an address that the others
will not recognize as part of the common multisig account.
==Test vectors==
The required number of signatures in each case is 2.
Vector 1
* List
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
* Sorted
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
* Script
**
522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae
* Address
** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
Vector 2 (Already sorted, no action required)
* List:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Sorted:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Script
**
522102632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed021027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e772102e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b40453ae
* Address
** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
Vector 3:
* List:
** 030000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414140
* Sorted:
** 020000000000000000000000000000000000004141414141414141414141414140
** 020000000000000000000000000000000000004141414141414141414141414141
** 030000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414141
* Script
**
522102000000000000000000000000000000000000414141414141414141414141414021020000000000000000000000000000000000004141414141414141414141414141210300000000000000000000000000000000000041414141414141414141414141402103000000000000000000000000000000000000414141414141414141414141414154ae
* Address
** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
Vector 4: (from bitcore)
* List:
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
* Sorted:
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
* Script
**
5221021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc1821022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da2103e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e953ae
* Address
** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
==Usage & Implementations==
* BIP45 - Structure for Deterministic P2SH Multisignature Wallets -
https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure
* Bitcore -
https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541
* Haskoin -
https://github.com/haskoin/haskoin/blob/master/Network/Haskoin/Script/Parser.hs#L112-122
* Armory -
https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441
* Multisignature Brainwallet - http://ms-brainwallet.org/
For now, the BIP will live here:
https://github.com/afk11/bips/blob/bip0090/bip-0090.mediawiki/
Looking forward to any feedback and discussions that arise!
- --
Thomas Kerin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xA2966155.asc
Type: application/pgp-keys
Size: 5712 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/a4aa3085/attachment.bin>

2023-06-07 15:30:30

- reply

📅 Original date posted:2015-02-13
📝 Original message:On 12/02/15 22:13, Luke Dashjr wrote:
> Where is the Specification section?? Does this support arbitrary scripts, or
> only the simplest CHECKMULTISIG case?
The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.
You're right, we're missing a Specification. I have tweaked the document
to cover this now.
On 13/02/15 07:53, Peter Todd wrote:
> It might be enough to rewrite this BIP to basically say "all pubkeys
> executed by all CHECKMULTISIG opcodes will be in the following
> canonical order", followed by some explanatory examples of how to
> apply this simple rule. OTOH we don't yet have a standard way of even
> talking about arbitrary scripts, so it may very well turn out to be
> the case that the above rule is too restrictive in many cases - I
> certainly would not want to do a soft-fork to enforce this, or even
> make it an IsStandard() rule.
It would be interesting, but I agree it should not be brought into these
validation rules - just a convention for people to follow for now. I
think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons.
--
Thomas Kerin
------------------------------------------------------------------------
My PGP key can be found here <http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150213/38ec3d07/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xA2966155.asc
Type: application/pgp-keys
Size: 5712 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150213/38ec3d07/attachment.bin>

2023-06-07 15:30:29

- reply

📅 Original date posted:2015-02-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
I have drafted a BIP with Jean Pierre and Ruben after the last
discussion, related to a standard for deriving a canonical
pay-to-script-hash address given a set of public keys and the number of
signatures required. There have been two or three discussions about it
on the mailing list to date, and various services already carry out this
process. I hope a BIP to describe this process will allow services to
declare themselves as BIPXX compliant, working towards interoperability
of services and simplifying the derivation of scripts and their
addresses by all parties.
BIP: XX
Title: Deterministic Pay-to-script-hash multi-signature addresses
through public key sorting
Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
Status: Draft
Type: Standards Track
Created: 8 February 2015
==Abstract==
This BIP describes a method to deterministically generate
multi-signature transaction scripts. It focuses on defining how the
public keys must be encoded and sorted so that the redeem script and
corresponding P2SH address are always the same for a given set of keys
and number of required signatures.
==Motivation==
Most multi-signature transactions are addressed to P2SH
(pay-to-script-hash) addresses, as defined in BIP-0016.
Multi-signature redeem scripts do not require a particular ordering or
encoding for public keys. This means that for a given set of keys and
number of required signatures, there are as many as 2(n!) possible
standard redeem scripts, each with its separate P2SH address. Adhering
to a an ordering scheme and key encoding would ensure that a
multi-signature “account” (set of public keys and required signature
count) has a canonical P2SH address.
By adopting a sorting and encoding standard, compliant wallets will
always produce the same P2SH address for the same given set of keys and
required signature count, making it easier to recognize transactions
involving that multi-signature account. This is particularly attractive
for multisignature hierarchical-deterministic wallets, as less state is
required to setup multi-signature accounts: only the number of required
signatures and master public keys of participants need to be shared, and
all wallets will generate the same addresses.
While most web wallets do not presently facilitate the setup of
multisignature accounts with users of a different service, conventions
which ensure cross-compatibility should make it easier to achieve this.
Many wallet as a service providers use a 2of3 multi-signature schema
where the user stores 1 of the keys (offline) as backup while using the
other key for daily use and letting the service cosign his transactions.
This standard will help in enabling a party other than the service
provider to recover the wallet without any help from the service provider.
==Implementation==
For a set of public keys, ensure that they have been received in
compressed form, sort them lexicographically according to their binary
representation before using the resulting list of keys in a standard
multisig redeem script. Hash the redeem script according to BIP-0016 to
get the P2SH address.
==Compatibility==
* Uncompressed keys are incompatible with this specificiation. A
compatible implementation should not automatically compress keys.
Receiving an uncompressed key from a multisig participant should be
interpreted as a sign that the user has an incompatible implementation.
* P2SH addressses do not reveal information about the script that is
receiving the funds. For this reason it is not technically possible to
enforce this BIP as a rule on the network. Also, it would cause a hard
fork.
* Implementations that do not conform with this BIP will have
compatibility issues with strictly-compliant wallets.
* Implementations which do adopt this standard will be cross-compatible
when choosing multisig addressses.
* If a group of users were not entirely compliant, there is the
possibility that a participant will derive an address that the others
will not recognize as part of the common multisig account.
==Test vectors==
The required number of signatures in each case is 2.
Vector 1
* List
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
* Sorted
** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
* Script
**
522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae
* Address
** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
Vector 2 (Already sorted, no action required)
* List:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Sorted:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Script
**
522102632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed021027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e772102e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b40453ae
* Address
** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
Vector 3:
* List:
** 030000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414140
* Sorted:
** 020000000000000000000000000000000000004141414141414141414141414140
** 020000000000000000000000000000000000004141414141414141414141414141
** 030000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414141
* Script
**
522102000000000000000000000000000000000000414141414141414141414141414021020000000000000000000000000000000000004141414141414141414141414141210300000000000000000000000000000000000041414141414141414141414141402103000000000000000000000000000000000000414141414141414141414141414154ae
* Address
** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
Vector 4: (from bitcore)
* List:
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
* Sorted:
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
* Script
**
5221021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc1821022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da2103e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e953ae
* Address
** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
==Usage & Implementations==
* BIP45 - Structure for Deterministic P2SH Multisignature Wallets -
https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure
* Bitcore -
https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541
* Haskoin -
https://github.com/haskoin/haskoin/blob/master/Network/Haskoin/Script/Parser.hs#L112-122
* Armory -
https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441
* Multisignature Brainwallet - http://ms-brainwallet.org/
For now, the BIP will live here:
https://github.com/afk11/bips/blob/bip0090/bip-0090.mediawiki/
Looking forward to any feedback and discussions that arise!
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQJ8BAEBCgBmBQJU3R43XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVKwUP/3MS++5D+YJAPZG/a7PhY3hf
8UvBkaAp7YqCVvZkHhpQ3+7AF+c6nAfu9JRFSdGP5hNvApagbZoC2oeLQ5rHBfXC
MbkbqOSp0z7C4MvEqmncTSgqNykxanVfiypV2S7hU2fbiylVi2jIaGrjqQt32jT7
kdFw5wqAS3zVHJVZhnUufLj/VYC94vdfrgpL22WI9oNH/nOvO6uG3YwZ9rc63ZH/
cwTmUnjOqDUlJWtYsfcoDL41RkmeBtGqD+6gTe3BtVHJQqlsEWpB1hsucOv5XdEk
V0teRUQ8+hFnU86+S4VJ8+qy/QjYflHnfy7vcA3M6LhAkle3scCs7ZCpDb9EGFM+
yAZivS4vrcVaYgY+oBdSnMEyvudwDKHwdy/rNjTskCLsHzcZX5jAoIxT2XskAXMD
UcWRelpN7Wth5jnSXeB89Wg1DqBwyl0LF7ZXepglopfHbAIsZ1oms252f5G7cfFq
+11HR3JswvVN4otqNAZzYaN7wEBEZwlcD+a/VKoNE0uPVuBS08phhNGjHmidXCOZ
wC11biStwjt1tv1lUNcK0HkkNReuUrUDK1dNKxGGfUHk+Qcka+cQ1ap47lLx06+U
LskPwJKR1tvoHkVMLy4UutX8bIRtXE3WbSOQlV9Q/4/os3tTpVlH5AX47W+2CikV
t3pTmdJy0FubCrHSJ63C
=5H5A
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d4a3d521/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xA2966155.asc
Type: application/pgp-keys
Size: 5712 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d4a3d521/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xA2966155.asc.sig
Type: application/pgp-signature
Size: 639 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d4a3d521/attachment.sig>

2023-06-07 15:29:11

- reply

📅 Original date posted:2015-01-31
📝 Original message:Ooh, I had a very similar proposal, except it involved sharing generic P2SH scripts. It also involved facilitating requesting of signatures.. We should talk.On 31 Jan 2015 01:30, Martin Habovštiak <martin.habovstiak at gmail.com> wrote:
>
> Hello,
>
> I've been thinking about how to solve security problems of the servers
> holding huge amounts of bitcoins (exchanges, markets...) and came up
> with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5
>
> TL;DR: it's extension of BIP70 (but not fully compatible due to security
> reasons) which supports making of multisig transactions dynamically.
> (The most important thing is that the user provides his address.)
>
> What do you think? Is it a good way to solve the problem or do you know
> about something better? I would really like this or something similar
> implemented by wallets.
>
> Thank you for your feedback!
>
> Martin
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:28:32

- reply

📅 Original date posted:2015-01-16
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
It would - it assumes you have the set of keys and are sorting before
you derive and send funds to such a P2SH address.
It seems there is scope for further narrowing down how a multisig
scripthash address should be determined - what do people think of
anticipating only compressed keys for scripts?
It's possible to cause confusion if one put forward a compressed key at
some time, and an uncompressed key at another. A different script hash
would be produced even though there is no difference to the keys
involved. The client will not search for this.
Having spoken with Jean-Pierre and Ruben about this for quite some time
now, there is 100% the need for a BIP outlining this. Everyone has had
the idea at some point, and some of us already using it, but people
shouldn't have to go digging in BIP45 for the two lines which mention
it. All we need is a place to put the docs.
I am building up a list of implementations which currently support
sorting, and briefly describing a motivation for such a BIP.
On 16/01/15 10:16, Ruben de Vries wrote:
> Since we only need the sorting for creating the scriptPubKey,
> wouldn't it make the most sense to sort it by the way it represented
in that context?
>
>
> On Thu, Jan 15, 2015 at 2:03 PM, Wladimir <laanwj at gmail.com
<mailto:laanwj at gmail.com>> wrote:
>
> On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock
<bip at mattwhitlock.name <mailto:bip at mattwhitlock.name>> wrote:
> > On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
> >> Internally, pubkeys are DER-encoded integers.
> >
> > I thought pubkeys were represented as raw integers (i.e.,
they're embedded in Script as a push operation whose payload is the raw
bytes of the big-endian representation of the integer). As far as I
know, DER encoding is only used for signatures. Am I mistaken?
>
> OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
> DER-encoded signature on the stack.
>
> Possibly you're confused with OP_HASH160 <hash160> OP_EQUALVERIFY as
> used in outputs, which compares the 160-bit hash of the pubkey against
> the given hash (usually taken from a bitcoin address).
>
> It doesn't help understanding to consider either as integers. They are
> binary blob objects with either a fixed format (DER) or a fixed size
> (hashes).
>
> Wladimir
>
>
>
>
> --
> BlockTrail B.V.
> Barbara Strozzilaan 201
> 1083HN Amsterdam
> The Netherlands
>
> Phone:+31 (0)612227277
> E-mail:ruben at blocktrail.com <mailto:ruben at blocktrail.com>
> Web:www.blocktrail.com
> <http://www.blocktrail.com/>
> Github:www.github.com/rubensayshi <http://www.github.com/rubensayshi>
>
> BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in
Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01
>
>
>
------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQJ8BAEBCgBmBQJUuT2EXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFV4GgP/Rr955cDBA34e58lLdjXkqzi
EYDH5QfsTdUQQVUvkK0OBq7RQwkbb7Kn5u6U8UD3hEhaWwQGhrQ/gOJrqM68glma
YfYupugMesTTu4Fxm/AtNv4Cifr29EZB1gu9hBeZGT4FL863+0ShvWHdHvscOcmg
3SGv0De+1bd93j7p+9jyWh/sYpHEdi0lQBMkkCzSzhXPZzoHEglUmVYBRcmrjaag
ycHuQfN5zjM0fJ18R6f7PCOOAhDi9+7xpikDArvHmKb4BZjOuMBTprN2Mzdg98Uz
Rw4LRsLuht5VCnWHvC8+TUUEMUO8QOMrRxLYJSDVGcl0XYXT0EiRfnkqCr5ab8mm
KqLcxpSLxrDGd4OiHwWB7oDsg9tWXwVmyQgFsTLsxaNkL8AFRG59mAhbK9j+0+1E
Bd/pMx0VgGXpn1Urism5YlrR4FZ5USbYn9O0NxhUkQb550qvRtaAQNUVSJPEW0AG
/2pQdFOOqkI1wI0g2L/ZcC+fwBqUok+5MyMTb4NuuvaMDpR7vOeeobIpYLjL0VVZ
dNzfnlCQxGw/7QrFIbvnye8fNIMZZ9qtJx00bvXYizRyUhrF/FrRgwj2DhEjz6xM
3+CHKXNmb0qGg6jKgHvXQFic2DVo3IaNmZtVDBqyqCBKmC/A65rRws5uxIimUsIC
k4af62ZBGpSAhJ4ajCIY
=Ni9V
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150116/12059b7e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xA2966155.asc
Type: application/pgp-keys
Size: 5712 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150116/12059b7e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xA2966155.asc.sig
Type: application/pgp-signature
Size: 639 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150116/12059b7e/attachment.sig>

2023-06-07 15:16:22

- reply

📅 Original date posted:2014-03-27
📝 Original message:Isn't the length of the seed arbitrary anyway? Once decoded using whatever
mnemonic implementation (electrums, or BIP0039) the bytestream is
immediately passed to HMAC-SHA256 to generate the master key. No matter
what your initial entropy is, it would be hashed anyway.
On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn <mike at plan99.net> wrote:
> Ah, BIP32 allows for a range of entropy sizes and it so happens that they
> picked 256 bits instead of 128 bits.
>
> I'd have thought that there is a right answer for this. 2^128 should not
> be brute forceable, and longer sizes have a cost in terms of making the
> seeds harder to write down on paper. So should this be a degree of freedom?
>
>
> On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> By the way, I just noticed that greenaddress.it is creating seeds that
>> have 24 words instead of 12. Does anyone know what's up with that? They
>> claim to be using BIP32 wallets so I wanted to see if they were using the
>> default structure and if so, whether bitcoinj was compatible with it
>> (before I switch to the one discussed here). But it seems we fall at the
>> first hurdle ...
>>
>>
>> On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
>>
>>>
>>>
>>> Le 27/03/2014 12:30, Marek Palatinus a écrit :
>>> > Ah, I forget to two things, which should be into the BIP as well:
>>> >
>>> > a) Gap factor for addresses; as Thomas mentioned, although some
>>> software
>>> > can watch almost unlimited amount of unused addresses, this is serious
>>> > concern for lightweight or server-based wallets like Electrum or
>>> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
>>> > experience so far) quite sane for most of users.
>>>
>>>
>>> Yes, I was planning to increase the number of available unused addresses
>>> to 10 or 20 in the bip32 version of Electrum.
>>>
>>> Related to this, here is another idea I would like to submit:
>>>
>>> Instead of using a "gap limit" (maximal number of consecutive unused
>>> addresses), I think we should get rid of the topology, and simply count
>>> the number of unused addresses since the beginning of the sequence.
>>> Indeed, the topology of the sequence of addresses is of no interest to
>>> the user. Users often misinterpret "gap limit" as the "number of unused
>>> addresses available", so I think we should just give them what they want
>>> :) This is easier to understand, and it makes things more predictable,
>>> because the wallet will always display the same number of unused
>>> addresses (except when it is waiting for confirmations).
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/1de2fe0e/attachment.html>