Marek Palatinus [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-04-06 to 2021-08-31
💬 Posted a total of 11 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 22:58:12

- reply

📅 Original date posted:2021-08-31
📝 Original message:I fully agree with sipa and his reasoning that this proposal is not solving
any particular problem, but making it actually a bit worse.
Also, do you know what I hate more than copy&pasting bitcoin addresses?
Copy pasting zillion random fields for SEPA/wire transfers. And I believe
that a single copy pasta of a bitcoin address is a much better user
experience after all.
Best,
slush
On Tue, Aug 31, 2021 at 9:08 AM ts via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Pieter, thanks for your comments. Here my thoughts:
>
> Pieter Wuille wrote on 8/29/21 9:24 AM:
> > On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> Following up on my original proposal, I would like to get some more
> feedback of the community
> >>
> >> to see if this could be realized at some point. Also, any
> recommendations as to who to contact
> >>
> >> to get things rolling?
> >
> > I honestly don't understand the point of what you're suggesting.
>
> It is about creating a simple technical assistance that makes it more user
> friendly and less
> error prone to verify the entered address. For all types of users,
> including those who are
> less tech savvy.
>
>
> > * If you're concerned about random typos, this is something already
> automatically protected against through the checksum (both base58check or
> bech32/bech32m).
>
> I agree, but as mentioned in the original proposal, it is not about random
> typos (although
> this would help for other coins without integrated checksum of course),
> but rather about
> copy&paste errors (both technical or user caused).
>
>
> > * If you're concerned about accidentally entering the wrong - but
> honestly created - address, comparing any few characters of the address is
> just as good as any other. It doesn't even require the presence of a
> checksum. Looking at the last N characters, or the middle N, or anything
> except the first few, will do, and is just as good as an "external"
> checksum added at the end. For randomly-generated addresses (as honest ones
> are), each of those has exactly as much entropy.
>
> Correct. However, I believe that ADDITIONALLY to looking at N characters,
> a quick check of a 3
> or 4 digit code in bigger font next to the address would make for a better
> user experience.
> This gives the user the reassurance that there is definitely no error. I
> agree that most users
> with technical background including most of us here will routinely check
> the first/last N
> characters. I usually check the first 3 + last 3 characters. But I don't
> think this is very
> user friendly. More importantly, I once had the case that two addresses
> were very similar at
> precisely those 6 characters, and only a more close and concentrated look
> made me see the
> difference. Moreover, some inexperienced users that are not aware of the
> consequences of
> entering a wrong address (much worse than entering the wrong bank account
> in an online bank
> transfer) might forget to look at the characters altogether.
>
>
> > * If you're concerned about maliciously constructed addresses, which are
> designed to look similar in specific places, an attacker can just as easily
> make the external checksum collide (and having one might even worsen this,
> as now the attacker can focus on exactly that, rather than needing to focus
> on every other character).
>
> Not so concerned about this case, since this is a very special case that
> can only occur under
> certain circumstances. But taking this case also into consideration, this
> is why the user
> should use the verification code ADDITIONALLY to the normal way of
> verifying, not instead. If
> the attacker only focuses on the verification code, he will only be
> successful with users that
> ONLY look at this code. But if the attacker intends to be more successful,
> he now needs to
> create a valid address that is both similar in specific places AND
> produces the same
> verification code, which is way more difficult to achieve.
>
>
> > Things would be different if you'd suggest a checksum in another medium
> than text (e.g. a visual/drawing/colorcoding one). But I don't see any
> added value for an additional text-based checksum when addresses are
> already text themselves.
>
> Yes, a visual checksum could also work. Christopher Allen proposed to use
> LifeHash as an
> alternative. It would be a matter of balancing the more complex
> implementation and need of
> space in the app's layout with the usability and advantages of use. One
> advantage of the digit
> verification code is that it can be spoken in a call or written in a
> message.
>
> > This is even disregarding the difficulty of getting the ecosystem to
> adopt such changes.
>
> No changes are needed, only an agreement or recommendation on which
> algorithm for the code
> generation should be used. Once this is done, it is up to the developers
> of wallets and
> exchanges to implement this feature as they see fit.
>
> Greetings,
> TS
> _______________________________________________
> 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/20210831/3f498943/attachment.html>

2023-06-07 18:13:12

- reply

📅 Original date posted:2018-06-26
📝 Original message:On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> seems a bit overkill for how simple the format is, and pulling in a
> large dependency just for this is a bit silly. Although making it
> protobuf-compatible is an interesting idea, but I fear would be more
> work than is worth? I haven't looked closed enough at the protobuf
> encoding to be sure.
>
> > ...while at the same time, implementing "protobuf-based-BIP174" by
> > hand is roughly equally difficult as implementing the current BIP174.
>
> as a data point, I was able to build a simple serializer[1] in about an
> afternoon. I would much prefer to use this lib in say, clightning (my
> original goal), without having to have the larger protobuf dependency.
>
>
That was exactly matejcik's point; you can easily write protobuf-compatible
encoder/decoder for such simple structure in about an afternoon, if you
need. Or you can use existing protobuf parsers in matter of minute, if you
don't care about dependencies.
Also, many projects already have protobuf parsers, so it work in other way,
too; you need BIP174 parser as extra dependency/library, although you
already use protobuf library (like Trezor device does). For needs of
BIP174, the difference between ad-hoc format and protobuf is neglible, so
it is a mistake to introduce yet another format.
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180626/b277b69a/attachment.html>

2023-06-07 18:13:12

- reply

2023-06-07 17:54:05

- reply

📅 Original date posted:2016-10-16
📝 Original message:On Sun, Oct 16, 2016 at 10:58 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
> wrote:
> > It's not the website's fault if wallet devs aren't updating their
> > statuses. Besides, "WIP" can mean an awful lot of things.
>
> As I said, it would be nice to get an updated version so we can see more
> than 20% readyness of wallets.
> The wallet devs not caring enough to update the status should be a worrying
> sign, though.
>
WIP for TREZOR means that we've made that hard part already (firwmare) so
we know it is feasible, yet we didn't spend enough time on finalizing all
the stack like our web wallet because we don't see any actual release date
yet. Considering current battles on BU hashpower, we decided simply sit and
watch (I already have popocorn).
SegWit is probably the most disruptive and most invasive change ever made to
> Bitcoin. We have miners actively saying they don't like it and this makes
> it
> a contriversial upgrade which means the network may split and other issues.
>
>
There're also many wallets which are impatiently waiting for segwit to be
released. Segwit is blessing for hardware wallets for many reasons. I
actually think that rolling out Segwit will increase security, because it
will reduce huge complexity in hardware wallets as it is today.
Slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161016/93d827a9/attachment.html>

2023-06-07 17:53:05

- reply

📅 Original date posted:2016-08-25
📝 Original message:As Luke pointed, BIP44 is already used by many wallets and to my knowledge
people don't have any real world issues with that, including loading funds
in another BIP44 wallet. I'm not saying that BIP44 is perfect from all
points of view, but IMO it just works for most use cases. Let's set it as
final, and propose competing standards which cover all your concerns.
slush
On Thu, Aug 25, 2016 at 10:12 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > The development paradigm of "maybe detect funds" is not something we
> > should *not* encourage for Bitcoin IMO.
>
> Sorry. That was one "not" to many.
>
> </jonas>
>
>
> _______________________________________________
> 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/20160825/ffbc4f83/attachment.html>

2023-06-07 17:52:52

- 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 17:52:51

- 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 17:52:50

- reply

📅 Original date posted:2016-08-17
📝 Original message: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.
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.
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).
slush
On Wed, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Dana
>
> >> The URI scheme does not require any sorts of wallet app level
> >> configuration (where the stdio/pipe approach would require to configure
> >> some details about the used hardware wallet).
> >
> > Hi everybody, just thought I’d throw my opinion in here.
> >
> > The URI scheme is a nice idea, but this ignores the fact that hardware
> wallet vendors do most of the work on talking between the computer/mobile
> and the wallet on a lower level of communication. In the case of BitLox,
> the base protocol is Google’s ProtoBuf. The commands and transaction data
> is in a “schema” which is then encoded in different methods accessible via
> ProtoBuf (depending on the data being sent). The advantages of this
> protocol is that it can be implemented on a wide variety of platforms. (but
> that’s a whole 'nother discussion)
> >
> > The URI would be handled waaaaay up in the specific application (such as
> the mytrezor wallet software or the various standalone wallets) - nowhere
> near the actual hardware communications layer.
>
> This is maybe a question of the scope.
> The BIP I'm proposing would make a clear interface cut between
> wallet-with-unsigned-transaction and a signing-device (and maybe between
> wallet-requires-pubkey, signing-device generate some pubkeys [or
> non-hardened xpub]).
>
> The detached-signing proposal does not duplicate work. It just moves the
> current plugin design into a separate application. Plugins in security
> and privacy critical wallet software is something that should probably
> be avoided.
>
> It's intentional at a high level to allow maximum flexibility at the
> hardware interaction layer.
>
> Your protobuf example is a good use-case. You could implement your
> custom processes behind the URI scheme (which is probably way more
> efficient then writing a couple of wallet plugins where you – at the end
> – mostly don't control the deployment and the source-code).
>
> Defining a standard on the hardware interaction layer is possible, but a
> fairly different approach.
>
> </jonas>
>
>
> _______________________________________________
> 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/136eadac/attachment.html>

2023-06-07 17:50:30

- reply

📅 Original date posted:2016-05-11
📝 Original message:Ehm, I though those discussions about "ASICs are bad, because X" ended
years ago by starting "ASIC unfriendly" altcoins. ASIC industry is twisted
even without AsicBoost. I don't see any particular reason why to change
rules just because of 10% edge.
This is opening Pandora box and it is potentially extremely dangerous for
the health of the network. You cannot know in advance what you'll break by
changing the rules.
Disclaimer: I don't have any stake in any ASIC company/facility.
slush
On Wed, May 11, 2016 at 2:20 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
>
>>
>>
>> You can find it here:
>> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
>>
>> Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
>> second 64-byte chunk. That design also allows increased nonce space in the
>> first 64 bytes.
>>
>> My mistake here. I didn't recalled correctly my own idea. The idea is to
> include in the second 64-byte chunk a 4-byte hash of the first chunk, not
> the opposite.
>
>
> _______________________________________________
> 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/20160511/9940ac75/attachment.html>

2023-06-07 17:50:25

- reply

📅 Original date posted:2016-05-08
📝 Original message:I received this:
---------- Forwarded message ----------
From: Pieter Wuille <pieter.wuille at gmail.com>
Date: Fri, Apr 22, 2016 at 6:44 PM
Subject: Re: [bitcoin-dev] Proposal to update BIP-32
To: Marek Palatinus <marek at palatinus.cz>
Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
On Thu, Apr 21, 2016 at 2:08 PM, Marek Palatinus <marek at palatinus.cz> wrote:
> 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.
>>
>> 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.
>>
>
I think I change like this makes a lot of sense technically, and I wish I
had known how BIP-32 would end up being used inside higher level mechanisms
that automatically increment the position beyond the control of the
application generating them. The inclusion of the requirement was there
because ECDSA is notorious for security problems under biased secret keys,
though it's really only a certificational issue for secp256k1 (due to its
group order being so close to 2^256).
>
>> #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?
>>
>
BIPs are not supposed to be updated with new ideas, only
remarks/links/typos/clarifications/..., so that their bumbers can
unambiguously be used to refer to an idea. My suggestion would be to write
a new BIP that overrides parts of BIP32, and then put a note in BIP32 that
a better mechanism is available that is unlikely to change things in
reality for the secp256k1 curve.
I guess
> 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 chance for failure is a bit higher than that, as it only requires a
failed key (one in 2^128) in the first step, followed by an iteration that
results in the same I_R to cause a cycle. If you take multiple failures
before the cycle starts into account, the combined chance for failure is
p/(1-p)^2 / 2^256 (with p the chance for a random inadmissable key), which
is not much better than 1 in 2^128 for high values of p.
An alternative that always converges is to retry with an appended iteration
count is possible:
{
I = HMAC-SHA512(Key = c_par, Data = 0x01 || || ser32(i)) for the first
iteration
I = HMAC-SHA512(Key = c_par, Data = 0x01 || || ser32(i) || ser32(j)) for
iteration number j, with j > 0
}
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160508/f42d5ac4/attachment.html>

2023-06-07 17:50:09

- 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>

2023-06-07 17:50:09

- reply

2023-06-07 17:50:03

- reply

📅 Original date posted:2016-04-06
📝 Original message:To my understanding it is purely software thing. It cannot be detected from
outside if miner uses this improvement or not. So patenting it is worthless.
slush
On Tue, Apr 5, 2016 at 1:01 AM, Mustafa Al-Bassam via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Alternatively scenario: it will cause a sudden increase of Bitcoin mines
> in countries where the algorithm is not patented, possibly causing a
> geographical decentralization of miners from countries that already have a
> lot of miners like China (if it is patented in China).
>
> On 01/04/16 10:00, Peter Todd via bitcoin-dev wrote:
>
> On Thu, Mar 31, 2016 at 09:41:40PM -0700, Timo Hanke via bitcoin-dev wrote:
>
> Hi.
>
> I'd like to announce a white paper that describes a very new and
> significant algorithmic improvement to the Bitcoin mining process which has
> never been discussed in public before. The white paper can be found here:
> http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf
>
> What steps are you going to take to make sure that this improvement is
> available to all ASIC designers/mfgs on a equal opportunity basis?
>
> The fact that you've chosen to patent this improvement could be a
> centralization concern depending on the licensing model used. For example, one
> could imagine a licensing model that gave one manufacture exclusive rights.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://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/20160406/06ef680b/attachment.html>