<unnamed>

Public Key

npub1xtqansnal58rjnnxvyke6kzuvxsz0twg4456awy6ff0525yqgjxqjacz68

Profile Code

nprofile1qqsr9swecf7l6r3efenxztvatpwxrgp84hy266dwhzdy5h692zqyfrqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds4vy3w4

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:52:52 CEST

- reply

📅 Original date posted:2016-08-18
📝 Original message:On Thu, Aug 18, 2016 at 11:35 AM, Jonas Schnelli <dev at jonasschnelli.ch>
wrote:
> I agree that BIP70 is a mess (including the bitcoin:// additions). The
> proposed URI scheme would be completely different.
This reminds me https://xkcd.com/927/
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.
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/2fd8ecbe/attachment.html>

2023-06-07 19:52:51 CEST

- reply

📅 Original date posted:2016-08-18
📝 Original message:> Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?
The main benefit is that you don't need "standard" to solve problem, but
use natural tools in given environment and programming stack. Build a
"standard" on top of URI protocol is a huge limitation, which does not give
any advantage.
We already see issues with dead simple "bitcoin uri" standard, it barely
works in most of bitcoin apps. Think of vague definitions of parameters or
ability to send payment requests over it. HW API would be complicated by an
order of magnitude and I have serious concerns that it will be helpful for
anything. So why complicate things.
> How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?
Interprocess communication/libraries/dependencies on Android are not bound
to specific transport anyhow. Such library could be used by any android
app, and the library would implement proper transports for various
supported vendors. USB for Trezor, NFC for something different etc. If the
point is "make life of app developers easier", let's do this and do not
define artifical "standards".
slush
On Thu, Aug 18, 2016 at 8:54 AM, Jonas Schnelli <dev at jonasschnelli.ch>
wrote:
> Hi
>
> > I fundamentally disagree with the concept of driving signing workflow by
> > the wallet software. Wallet software does not know in advance all data
> > necessary for the signer to do the job. As Jochen mentioned above,
> > Segwit vs Non-segwit use cases are a good example, but there may be many.
>
> I think this is easily solvable. The required data to verify and sign a
> (standard) bitcoin transaction (including P2WSH multi-sig) is manageable.
>
> IMO what a signing devices requires in order to sign a (standard)
> transaction:
> -> serialized tx
> -> serialized tx of the inputs
> -> scriptPubKey of the inputs
> -> inputs redeem-Scripts
> -> input amounts
> -> position of the change output any maybe its keypath
> -> cosigners pubkeys for inputs and changeaddress
>
> This seems to be manageable for a 1 round communication?
> Or do I miss something?
>
>
> > Currently the TREZOR protocol works like device is a server and wallet
> > is a client calling methods on it. It's like: "Sign this for me,
> > please", "Ok, give me this information", "Here it is", "Now I need this
> > another piece".... "There is the signature". Wallet does not know in
> > advance what will go next, and it is for sake of simplicity. I'm quite
> > happy with the protocol so far.
>
> I think multiple rounds would still be possible with a clever design.
> Although I could imaging that >95% of the users transaction would
> require only a single "shot".
>
> Whats the benefits of the multiple rounds communication? Would a single
> round result in to many data transported?
>
> Passing a 300kb chunk (assuming a large transaction) over a URI scheme
> requires a couple of milliseconds on standard Smartphones or PCs.
>
> > Considering the difference in between current hardware, I really don't
> > think it is possible to find any minimal URI-based API good enough for
> > communicating with all vendors. What I see more likely is some 3rd party
> > libraries (JS, C++, Python, ...) defining high-level API and
> > implementing hardware-specific protocols and transports as plugins. That
> > way vendors are not limited by strict standard and application
> > developers and services can integrate wide range of hardware wallets
> > easily. However, this can be done already and we do not need any
> > standardization process (yet).
>
> The URI-based API allows transmitting data of multiple megabytes while
> there is no need for...
> * dependencies of any form (library, etc.)
> * library support for a particular language
> * platform that supports the dependencies of the library (like USBHID,
> not supported by iOS)
>
> Can you elaborate what benefits you would get from the library approach
> and how the library API would be different form the proposed URI-scheme?
>
> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
>
> Thanks
> --
> </jonas>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/59c71c94/attachment-0001.html>

2023-06-07 19:50:09 CEST

- reply

📅 Original date posted:2016-04-21
📝 Original message:Sipa, you are probably the most competent to answer this. Could you please
tell us your opinion? For me, this is straightforward, backward compatible
fix and I like it a lot. Not sure about the process of changing "Final" BIP
though.
Slush
On Wed, Apr 20, 2016 at 6:32 PM, Jochen Hoenicke via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Bitcoin Developers,
>
> I would like to make a proposal to update BIP-32 in a small way.
>
> TL;DR: BIP-32 is hard to use right (due to its requirement to skip
> addresses). This proposal suggests a modification such that the
> difficulty can be encapsulated in the library.
>
> #MOTIVATION:
>
> The current BIP-32 specifies that if for some node in the hierarchy
> the computed hash I_L is larger or equal to the prime or 0, then the
> node is invalid and should be skipped in the BIP-32 tree. This has
> several unfortunate consequences:
>
> - All callers of CKDpriv or CKDpub have to check for errors and handle
> them appropriately. This shifts the burden to the application
> developer instead of being able to handle it in the BIP-32 library.
>
> - It is not clear what to do if an intermediate node is
> missing. E.g. for the default wallet layout, if m/i_H/0 is missing
> should m/i_H/1 be used for external chain and m/i_H/2 for internal
> chain? This would make the wallet handling much more difficult.
>
> - It gets even worse with standards like BIP-44. If m/44' is missing
> should we use m/45' instead? If m/44'/0' is missing should we use
> m/44'/1' instead, using the same addresses as for testnet?
> One could also restart with a different seed in this case, but this
> wouldn't work if one later wants to support another BIP-43 proposal
> and still keep the same wallet.
>
> I think the first point alone is reason enough to change this. I am
> not aware of a BIP-32 application that handles errors like this
> correctly in all cases. It is also very hard to test, since it is
> infeasible to brute-force a BIP-32 key and a path where the node does
> not exists.
>
> This problem can be avoided by repeating the hashing with slightly
> different input data until a valid private key is found. This would
> be in the same spirit as RFC-6979. This way, the library will always
> return a valid node for all paths. Of course, in the case where the
> node is valid according to the current standard the behavior should be
> unchanged.
>
> I think the backward compatibility issues are minimal. The chance
> that this affects anyone is less than 10^-30. Even if it happens, it
> would only create some additional addresses (that are not seen if the
> user downgrades). The main reason for suggesting a change is that we
> want a similar method for different curves where a collision is much
> more likely.
>
> #QUESTIONS:
>
> What is the procedure to update the BIP? Is it still possible to
> change the existing BIP-32 even though it is marked as final? Or
> should I make a new BIP for this that obsoletes BIP-32?
>
> What algorithm is preferred? (bike-shedding) My suggestion:
>
> ---
>
> Change the last step of the private -> private derivation functions to:
>
> . In case parse(I_L) >= n or k_i = 0, the procedure is repeated
> at step 2 with
> I = HMAC-SHA512(Key = c_par, Data = 0x01 || I_R || ser32(i))
>
> ---
>
> I think this suggestion is simple to implement (a bit harder to unit
> test) and the string to hash with HMAC-SHA512 always has the same
> length. I use I_R, since I_L is obviously not very random if I_L >= n.
> There is a minimal chance that it will lead to an infinite loop if I_R
> is the same in two consecutive iterations, but that has only a chance
> of 1 in 2^512 (if the algorithm is used for different curves that make
> I_L >= n more likely, the chance is still less than 1 in 2^256). In
> theory, this loop can be avoided by incrementing i in every iteration,
> but this would make an implementation error in the "hard to test" path
> of the program more likely.
>
> The other derivation functions should be updated in a similar matter.
> Also the derivation of the root node from the seed should be updated
> in a similar matter to avoid invalid seeds.
>
> If you followed until here, thanks for reading this long posting.
>
> 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/20160421/1b0958b3/attachment.html>