William Swanson [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-03-06 to 2015-06-12
💬 Posted a total of 10 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:32:32 CEST

- reply

📅 Original date posted:2015-04-24
📝 Original message:On Thu, Apr 16, 2015 at 9:12 AM, s7r <s7r at sky-ip.org> wrote:
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
The BIP 62 approach to malleability isn't the only option. Another
approach is to sign the transaction in such a way that the input
txid's are allowed to change without invalidating the signatures. That
way, if malleability happens, you just adjust you transaction to match
and re-broadcast. That proposal is here:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
The "Build your own nHashType" thread on this mailing list contains
the discussion.
I personally prefer this solution, since it nails the problem
completely with one simple and obvious change. The BIP 62 approach is
more like a game of wac-a-mole.
-William

2023-06-07 17:32:20 CEST

- reply

📅 Original date posted:2015-04-08
📝 Original message:It's not really clear why this is better than BIP 44 as it already
stands. You have the same fields, but they are just in a different
order. Couldn't you just use the existing BIP 44 hierarchy, but add
the convention that "wallet/account N" is the same wallet in each
supported currency?
For example, if I have a wallet called "business expenses", which
happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
for Litecoin.
I am trying to think of examples where your proposal is better than
BIP 44, but I can't think of any. Even backup recovery works fine. I
assume that your idea is to continue iterating over the different
wallet indices as long as you are finding funds in *any* currency.
Well, you can still do that with BIP 44. The fields are in a different
order, but that doesn't affect the algorithm in any way.
Maybe you have some deeper insight I'm not seeing, but if so, you need
to clearly explain that in your motivation section. The current
explanation, "This limits the possible implementations of
multi-currency, multisignature wallets," is pretty vauge. Also, there
is nothing in this spec that addresses the multisignature use-case.
The BIP 45 spec does a lot of extra work to make multisignature work
smoothly.
I'm not trying to criticize your proposal. I'm just trying to
understand what it's trying to accomplish.
-William Swanson
On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius at maza.club> wrote:
> I have a potential BIP, "Multi-Currency Hierarchy For Use In
> Multisignature Deterministic Wallets." I'm requesting discussion on it,
> and possibly assignment of a BIP number.
>
> It's located in this github gist:
> https://gist.github.com/Kefkius/1aa02945e532f8739023
>
> ------------------------------------------------------------------------------
> 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

2023-06-07 17:32:20 CEST

- reply

📅 Original date posted:2015-04-08
📝 Original message:Oops, sorry I missed that.
Since that's the reason this proposal exists, I would consider putting
it right up top where people can see it. Also, since this proposal is
specifically designed for multi-sig, I would look at what BIP45 is
doing and maybe incorporate a "cosigner_index" branch. Otherwise, this
idea seems like a reasonable way to organize a wallet.
-William
On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな <kinoshitajona at gmail.com> wrote:
> William,
>
> I believe the reasoning for this is stated in the Coin Type section.
>
> "Public derivation is used so that cosigners need only know one of each
> other's public keys, rather than needing to distribute public keys for each
> coin."
>
> BIP44 has a coin level, but it's a private derived level, so cosigners would
> not be able to generate multiple crypto currencies of each others' without
> giving each other n xpubs where n is the number of currencies shared. This
> new proposal basically sticks coin type on the public derivation side of
> things so that I could generate litecoin or darkcoin multisigs without your
> permission...
>
> Kefkius,
>
> This BIP seems like a good fit for multi-currency wallets based on multisig.
> So kudos for putting it in writing.
>
> However, I don't know if this is really a BIP thing. It's not improving
> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition
> it is improving altcoin usability.
>
> For that reason alone I will say I disagree for a BIP for this.
> - Jona
>
>
> 2015-04-08 16:46 GMT+09:00 William Swanson <swansontec at gmail.com>:
>>
>> It's not really clear why this is better than BIP 44 as it already
>> stands. You have the same fields, but they are just in a different
>> order. Couldn't you just use the existing BIP 44 hierarchy, but add
>> the convention that "wallet/account N" is the same wallet in each
>> supported currency?
>>
>> For example, if I have a wallet called "business expenses", which
>> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
>> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
>> for Litecoin.
>>
>> I am trying to think of examples where your proposal is better than
>> BIP 44, but I can't think of any. Even backup recovery works fine. I
>> assume that your idea is to continue iterating over the different
>> wallet indices as long as you are finding funds in *any* currency.
>> Well, you can still do that with BIP 44. The fields are in a different
>> order, but that doesn't affect the algorithm in any way.
>>
>> Maybe you have some deeper insight I'm not seeing, but if so, you need
>> to clearly explain that in your motivation section. The current
>> explanation, "This limits the possible implementations of
>> multi-currency, multisignature wallets," is pretty vauge. Also, there
>> is nothing in this spec that addresses the multisignature use-case.
>> The BIP 45 spec does a lot of extra work to make multisignature work
>> smoothly.
>>
>> I'm not trying to criticize your proposal. I'm just trying to
>> understand what it's trying to accomplish.
>>
>> -William Swanson
>>
>>
>> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius at maza.club> wrote:
>> > I have a potential BIP, "Multi-Currency Hierarchy For Use In
>> > Multisignature Deterministic Wallets." I'm requesting discussion on it,
>> > and possibly assignment of a BIP number.
>> >
>> > It's located in this github gist:
>> > https://gist.github.com/Kefkius/1aa02945e532f8739023

2023-06-07 17:29:44 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric at voskuil.org> wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming the
> original. You then only see one.
You are right, of course. There is no way to make Bluetooth 100%
secure, since it is an over-the-air technology. You could try securing
it using a CA or other identity server, but now you've excluded ad-hoc
person-to-person payments. Plus, you need an active internet
connection to reach the CA.
You can try using proximity as a substitute for identity, like
requiring NFC to kick-start the connection, but at that point you
might as well use QR codes.
This BIP is not trying to provide absolute bullet-proof security,
since that's impossible given the physical limitations of the
Bluetooth technology. Instead, it's trying to provide the
best-possible security given those constraints. In exchange for this,
we get greatly enhanced usability in common scenarios.
There are plenty of usable, real-world technologies with big security
holes. Anybody with lock-picking experience will tell you this, but
nobody is welding their front door shut. The ability to go in and out
is worth the security risk.
Bluetooth payments add a whole new dimension to real-world Bitcoin
usability. Do we shut that down because it can't be made perfect, or
do we do the best we can and move forward?
-William

2023-06-07 17:27:41 CEST

- reply

📅 Original date posted:2014-12-04
📝 Original message:Yes. A few of us over here in San Diego actually started working on a
format like this a few months ago, but it's been on the back burner
for a while.
Our motivation was to come up with a shared HD wallet format. Say I
would like create a 2-of-3 multisig wallet using my phone, PC, and
hardware key fob. All three devices would presumably be running
different wallet software, so we need some sort of standardized HD
multisig chain-description format that all three wallets can
understand. That way, regardless of their other differences, the
wallets can at least agree on how to generate new addresses.
Of course, once you share this chain-description file with a third
party, they too can generate addresses out of the wallet. This can be
used for auditing (like for charities), for receive-only wallets (like
a merchant kiosk), and for recurring payments. The recurring payment
case is a little problematic, since you need to trust the payee with
your privacy. I imagine this would only be useful for payouts you
manage yourself, like a mining pool, and not something you share with
the general public.
Our format is very similar to yours. We have a script template, just
like you do, but we describe the HD chains in a separate section
rather than in-line with the script. The script template only comes
into being once the chains have been gathered together into one place,
so the chain descriptions need to stand alone.
Unfortunately, we still have a lot of details to work through before
we have a concrete proposal that's ready for this mailing list.
Perhaps we can work together to come up with something.
-William
On Thu, Dec 4, 2014 at 7:42 AM, Luke Dashjr <luke at dashjr.org> wrote:
> Is anyone working on a serialisation format to convey P2SH HD chains? For
> example, to give someone who wants to make recurring payments a single token
> that can be used to generate many P2SH addresses paying to a multisig script.
>
> I'm thinking of something along the lines of a simple series of tokens, each
> indicating either a HD chain or literal script content. For all HD chains in
> the data, a child key would be generated based on the payment number, and all
> tokens concatenated to form the P2SH serialised script. Eg, for a simple 2-
> of-2, you would do something like this:
> literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG)
> Does this sufficiently cover all reasonable use cases?
>
> Luke

2023-06-07 17:14:59 CEST

- reply

📅 Original date posted:2014-03-06
📝 Original message:Hello,
I am attempting to write a parser for bip-0021 URI's, including
support for the new bip-0072 payment parameters. My goal is absolute
correctness. Unfortunately, these BIP's have a few ambiguities and
mistakes which ought to be corrected.
First, I would like to point out that internet RFC 3986 governs the
general syntax for URI's. It obsoletes RFC 1738 and various other
early RFC's. Since RFC 3986 came out in 2005, I think we can agree
that any bitcoin URI scheme should use this and not the earlier ones.
Unfortunately, bip-0021 never actually mentions RFC 3986, which is a
big omission. Even worse, bip-0072 explicitly refers to RFC 1738,
which is obsolete. This is a problem, since the old, obsolete standard
requires more escapes than are actually necessary. Updating bip-0072
to refer to RFC 3986 instead would allow shorter, more readable
bitcoin URI's (things like slashes in payment addresses wouldn't need
to be escaped).
Secondly, neither of the bip's describe what to do with international
characters. I doubt anybody wants to limit the "label" and "message"
parameters to 7-bit ASCII, so a character encoding needs to be
defined. RFC reccomends that all new URI schemes use UTF-8 as their
encoding, which is perfectly reasonable. The bip-0021 standard just
needs to actually say so.
Finally, there is an error in the bip-0021 BNF grammar, which never
mentions the '&' separator between query elements.
What is the procedure for getting these BIP's corrected? Submit a pull
request with the changes? Hopefully we can all agree that these fixes
are useful and necessary.
-William
P.S. The bitcoin-qt client uses QUrl to parse bitcoin uri's, and that
is based on RFC 3986. Thus, the bitcoin-qt client is probably already
implementing these suggestions.