<unnamed>

Public Key

npub1ymm7v2axmjgetkqvh6l7900qnk5za089fcu7snzsw6f5wzy55e5s3v30qh

Profile Code

nprofile1qqszdalx9wndeyv4mqxta0lzhhsfm2pwhnj5uw0gf3g8dy68pz22v6gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds56ryj7

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:42:22 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:When I talk about multisig account I mean an arrangement among a set of
cosigners to be signatories of multi-signature transactions requiring a
set number of signatures, as specified in BIP-45.
Example:
Juan: xpub123...
Pedro: xpub456...
José: xpub789...
They all agree to create a 2-of-3 multisig “account” following BIP-45.
Their extended public keys are all path m/45' from their wallet’s master
private key, as per the standard.
Perhaps Pedro wants to also participate in a 2-of-2 cosigning
arrangement with a merchant that will deliver a laptop to him, so Pedro
provides this merchant with the same extended public key derived from
path m/45', and the merchant provides Pedro with his own:
Pedro: xpub456...
ElCheapoPC: xpub987...
Now, suppose that the first cosigner[1] in each of the accounts
generates a set of public keys for a multisig redeem script to obtain a
P2SH address from. The derivation path m/45'/0/0/1 is used as per
BIP-45. Pedro’s public key for that address in each account will be the
same.
Every cosigner’s address public key is obtained following the same
derivation path from the cosigner’s master key, therefore, it is easy to
know what public keys Pedro is likely to use in both 2-of-3 account
{Juan, Pedro, José} and 2-of-2 account {Pedro, ElCheapoPC}, by only
knowing Pedro’s m/45' purpose-specific extended public key. By scanning
the blockchain for Pedro’s public keys, José can see that Pedro had a
2-of-2 multi-signature arrangement with somebody else (ElCheapoPC),
although he does not necessarily know its identity, and how much money
was transacted in that arrangement, without having to know the extended
public key from ElCheapoPC.
By adopting the scheme I proposed earlier as an improvement, cosigners
with Pedro would have to know ElCheapoPC’s extended public key in order
to eavesdrop on any transaction between Pedro and ElCheapoPC.
[1] According to lexicographic order of serialized public keys contained
in each of the xpubs, as per BIP-45 specification.
On 05/10/15 07:57, Matias Alejo Garcia wrote:
>
> Hi,
>
> Sorry the late response. Going back to the original message:
>
>
> > On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
> >> 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.
>
>
> I am not completely sure what you mean by 'account' and 'mutisig
> activity'. You seem to imply
> that the same set of extended public keys will be used in more that one
> wallet, which it is
> not required (and certainly not recommended) by BIP45.
>
> According to BIP45, a singing party, in order to generate a wallet
> address, needs the extended public keys of all the other parties, so
> each party will be able to see the transaction history of the wallet
> they are sharing, but if the party has other wallets with other copayers
> the xpub should be completely different.
>
> matías
>
>
>
> --
> BitPay.com

2023-06-07 19:42:22 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:Sure,
You always have these alternatives, but the problem is that it starts to
become harder to restore your wallet from the initial mnemonic if
something goes wrong.
Say you lose all your wallet information except for your mnemonic,
extended public keys from all people you established multi-signature
accounts with, and you know which arrangement you had with each of your
cosigners (2-of-3, 2-of-2, etc.). Your software will not have a hard
time rebuilding all accounts from information obtained from the public
blockchain. Adding a new dimension, here the i' derivation, will make
things harder. You would need to know this piece of data too.
Another good thing about using the same derivation always is that you
can give every cosigner only that single piece of information, that
single xpub, in order to establish multisig relationships. There is no
need to use a different one per relationship. This simplifies the
workflow for establishing new multi-signature accounts significantly.
Greetings
On 05/10/15 13:32, Jonas Schnelli wrote:
> What holds you back from using m/i'/45' where i' is your multisig
> "account" number?
>
> Within your BIP45 wallet (lets assume Copay), you would not provide
> the xpubkey at m/45', instead you would provide your xpubkey at m/i'/45'
> .
>
> It's probably no longer pure BIP45.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/2cb6453b/attachment-0001.sig>

2023-06-07 19:42:21 CEST

- reply

📅 Original date posted:2015-10-04
📝 Original message: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

2023-06-07 19:42:20 CEST

- reply

📅 Original date posted:2015-10-03
📝 Original message: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
On 25/04/14 23:27, Manuel Araoz wrote:
> Hi, I'm part of the team building copay
> <https://github.com/bitpay/copay>, a multisignature P2SH HD
> wallet. We've been following the discussion regarding standardizing the
> structure for branches both on this list and on github (1
> <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>, 2
> <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>, 3
> <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>, 4
> <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>, 5
> <https://github.com/bitcoin/bips/pull/52>). Soon, we realized the
> assumptions in the discussions were not true for a multisig hd wallet,
> so we wanted to share our current approach to that, to get feedback and
> see if we can arrive to a new standard (and possibly a new BIP)
>
> These are our assumptions:
> - N parties want to share an m-of-n wallet.
> - Each party must generate their master private keys independently.
> - Use multisig P2SH for all addresses.
> - Use BIP32 to derive public keys, then create a multisig script, and
> use the P2SH address for that.
> - The address generation process should not require communicating with
> other parties. (Thus, all parties must be able to generate all public keys)
> - Transaction creation + signing requires communication between
> parties, of course.
>
> -------------------------------------------------
>
> Following BIP43, we're be using:
>
>
> m / purpose' / *
>
> where /purpose/ is the hardened derivation scheme based on the new BIP
> number.
> We then define the following levels:
>
>
> m / purpose' / cosigner_index / change / address_index
>
> Each level has a special meaning detailed below:
>
> /cosigner_index/ <http://en.wikipedia.org/wiki/Co-signing>: the index of
> the party creating this address. The indices can be determined
> independently by lexicographically sorting the master public keys of
> each cosigner.
>
> /change/: 0 for change, 1 for receive address.
>
> /address_index/: Addresses are numbered from index 0 in sequentially
> increasing manner. We're currently syncing the max used index for each
> branch between all parties when they connect, but we're open to
> considering removing the index sync and doing the more elegant
> used-address discovery via a gap limit, as discussed in BIP44
> <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit>.
> We feel 20 might be too low though.
>
> *Wallet high-level description:*
> Each party generates their own extended master keypair and shares the
> extended purpose' public key with the others, which is stored encrypted.
> Each party can generate any of the other's derived public keys, but only
> his own private keys.
>
> *General address generation procedure:*
> When generating an address, each party can independently generate the N
> needed public keys. They do this by deriving the public key in each of
> the different trees, but using the same path. They can then generate the
> multisig script and the corresponding p2sh address. In this way, each
> path corresponds to an address, but the public keys for that address
> come from different trees.
>
> *Receive address case:*
> Each cosigner generates addresses only on his own branch. One of the n
> cosigners wants to receive a payment, and the others are offline. He
> knows the last used index in his own branch, because only he generates
> addresses there. Thus, he can generate the public keys for all of the
> others using the next index, and calculate the needed script for the
> address.
>
> /Example: /Cosigner #2 wants to receive a payment to the shared wallet.
> His last used index on his own branch is 4. Then, the path for the next
> receive address is m/$purpose/2/1/5. He uses this same path in all of
> the cosigners trees to generate a public key for each one, and from that
> he gets the new p2sh address.
>
> *Change address case:*
> Again, each cosigner generates addresses only on his own branch. One of
> the n cosigners wants to create an outgoing payment, for which he'll
> need a change address. He generates a new address using the same
> procedure as above, but using a separate index to track the used change
> addresses.
> /
> Example: /Cosigner #5 wants to send a payment from the shared wallet,
> for which he'll need a change address. His last used change index on his
> own branch is 11. Then, the path for the next change address is
> m/$purpose/5/0/12. He uses this same path in all of the cosigners trees
> to generate a public key for each one, and from that he gets the new
> p2sh address.
>
>
> *Transaction creation and signing:*
> When creating a transaction, first one of the parties creates a
> Transaction Proposal. This is a transaction that spends some output
> stored in any of the p2sh multisig addresses (corresponding to any of
> the copayers' branches). This proposal is sent to the other parties, who
> decide if they want to sign. If they approve the proposal, they can
> generate their needed private key for that specific address (using the
> same path that generated the public key in that address, but deriving
> the private key instead), and sign it. Once the proposal reaches m
> signatures, any cosigner can broadcast it to the network, becoming
> final. The specifics of how this proposal is structured, and the
> protocol to accept or reject it, belong to another BIP, in my opinion.
>
> *Final comments:*
> - We're currently lexicographically sorting the public keys for each
> address separately. We've read Mike Belshe's comments about sorting the
> master public keys and then using the same order for all derived
> addresses, but we couldn't think of any benefits of doing that (I mean,
> the benefits of knowing whose public key is which).
> - We originally thought we would need a non-hardened version of purpose
> for the path, because we needed every party to be able to generate all
> the public keys of the others. With the proposed path, is it true that
> the cosigners will be able to generate them, by knowing the extended
> purpose public key for each copayer? (m/purpose')
> - The reason for using separate branches for each cosigner is we don't
> want two of them generating the same address and receiving simultaneous
> payments to it. The ideal case is that each address receives at most one
> payment, requested by the corresponding cosigner.
>
>
> Thoughts?
> Manuel
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:17:29 CEST

- reply

📅 Original date posted:2014-04-10
📝 Original message:By deciding to use a decentralized network to hold your assets, it may
make more sense to emit less shares. Two billion shares backed by
coloured coins makes less sense than a more conservative number, like
10,000. That costs a negligible amount of money, at least until the day
when Bitcoin takes over the world and a satoshi becomes very expensive.
But it is irrelevant now.
If you have already created a massive amount of shares for your company,
then the only reasonable solution is for a coloured coin to represent a
bundle of shares as Flavien suggested. Some shareholder could emit
another coloured coin instrument with a genesis block based on a smaller
set of shares to trade among smaller investors unwilling to deal in
terms of the bundled shares.
We need to understand that coloured coins provide benefits, but also has
constraints that are not difficult to live with.
On 10/04/14 13:19, Flavien Charlon wrote:
> By the way, padding doesn't solve the issue entirely (issuing 10 billion
> shares sill takes you 100 BTC, even with padding and 1 satoshi = 1
> share), so I am going for the solution where the asset quantity of every
> output is explicitly encoded in the OP_RETURN output. That way, whether
> you are issuing 1 share or 100 trillions, you never need to pay more
> than 540 satoshis.
--
haskoin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFF4BF34C.asc
Type: application/pgp-keys
Size: 20252 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/ce7c983f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: root.vcf
Type: text/x-vcard
Size: 227 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/ce7c983f/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/ce7c983f/attachment.sig>

2023-06-07 17:15:08 CEST

- reply

📅 Original date posted:2014-03-11
📝 Original message: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 there will soon be
BIP-0039 support for keys compatibility.
Our wallet uses synced trees rooted at the extended pubkeys of the
participants. Currently we are sorting public keys in the scripts to
avoid ambiguity.
Download haskoin-wallet:
cabal install haskoin-wallet
Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to
bring transactions into the wallet. You must initialize first with a
seed and create an account. It supports both regular and multisig accounts.
Perhaps this can lead to interesting discussions on key exchange, and
the appropriate handling of wallet metadata. I’d love to work on a
proper standard that could lead us to compatible implementations.
This document explains how we do it now:
http://haskoin.com/~xeno/hd-multisig-wallet.html
Cheers!
--
Be Happy :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFF4BF34C.asc
Type: application/pgp-keys
Size: 20270 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/86dc878d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFF4BF34C.asc
Type: application/pgp-keys
Size: 20269 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/86dc878d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/86dc878d/attachment.sig>

2023-06-07 05:13:29 CEST

- reply

📅 Original date posted:2012-03-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Una potencial falla de seguridad ha sido descubierta en Bitcoin-Qt
para Windows. Si tienes Bitcoin-Qt para Windows en alguna versión
entre 0.5 y 0.6, deberías salir del programa, y actualizar a la
versión 0.5.3.1 o 0.6rc4 AHORA.
La aplicación de línea de comandos (bitcoind), las versiones Mac y
Linux de Bitcoin-Qt, y las versiones anteriores a 0.5 no están afectadas.
Debido a la naturaleza de esta falla, creemos que sería muy difícil
para un atacante hacer algo más que colgar (cerrar) el proceso de
Bitcoin-Qt. Sin embargo, porque existe la posibilidad que un cierre
inesperado permita la ejecución de código remoto, consideramos esto un
incidente crítico.
Si tienes alguna pregunta, visita el canal IRC #bitcoin-dev en Freenode.
Puedes descargar el software actualizado desde SourceForge:
0.6rc
[https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/]
0.5.3.1 para Windows y 0.5.3 para Linux
[https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/]
- --
Be Happy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9m4DYACgkQ77Wxq1L+vC74wgCfX4kF+BiKjO51UOgZmRib4kMP
W6sAn016/jDXOfV/WeonqtqB3GuhzG+t
=pqWY
-----END PGP SIGNATURE-----