<unnamed>

Public Key

npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727

Profile Code

nprofile1qqs8u4mxdnlhephegyxn84xnfme72yznjkeuwjh5wf2pm0htwslemccpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsny944u

Publishing to

relay.damus.io

nos.lol

nostr.wine

Last Notes

2023-06-07 17:32:01 CEST

- reply

📅 Original date posted:2015-03-24
📝 Original message:On Mon, 16 Mar 2015 09:29:03 -0700, Sergio Lerner
<sergiolerner at certimix.com> wrote:
> I proposed a (what I think) is better protocol for Proof of Storage that
> I call "Proof of Local storage" here
> https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
Thanks so much for publishing this. It could be useful in any application
to try to prove a keyed copy of some data.
If I understand correctly, transforming raw blocks to keyed blocks takes
512x longer than transforming keyed blocks back to raw. The key is public,
like the IP, or some other value which perhaps changes less frequently.
The verifier keeps blocks in the keyed format, and can decrypt quickly to
provide raw data, or use the keyed data for hashing to try to demonstrate
they have a pre-keyed copy.
>
> Two protocols can be performed to prove local possession:
> 1. (prover and verifier pay a small cost) The verifier sends a seed to
> derive some n random indexes, and the prover must respond with the hash
> of the decrypted blocks within a certain time bound. Suppose that
> decryption of n blocks take 100 msec (+-100 msec of network jitter).
> Then an attacker must have a computer 50 faster to be able to
> consistently cheat. The last 50 blocks should not be part of the list to
> allow nodes to catch-up and encrypt the blocks in background.
>
Can you clarify, the prover is hashing random blocks of *decrypted*, as-in
raw, blockchain data? What does this prove other than, perhaps, fast
random IO of the blockchain? (which is useful in its own right, e.g. as a
way to ensure only full-node IO-bound mining if baked into the PoW)
How is the verifier validating the response without possession of the full
blockchain?
> 2. (prover pay a high cost, verified pays negligible cost). The verifier
> chooses a seed n, and then pre-computes the encrypted blocks derived
> from the seed using the prover's IP. Then the verifier sends the seed,
> and the prover must respond with the hash of the encrypted blocks within
> a certain time bound. The proved does not require to do any PH
> decryption, just take the encrypted blocks for indexes derived from the
> seed, hash them and send the hash back to the verifier. The verifier
> validates the time bound and the hash.
The challenger requests a hash-sum of a random sequence of indices of the
keyed data, based on a challenge seed. So in a few bytes round-trip we can
see how fast the computation is completed. If the data is already keyed,
the hash of 1,000 random 1024-bit blocks should come back much faster than
if the data needs to be keyed on-the-fly.
To verify the response, the challenger would have to use the peer's
identity key and perform the slower transforms on those same 1,000 blocks
and see that the result matches, so cost to challenger is higher than
prover, assuming they actually do the computation.
Which brings up a good tweak, a full-node challenger could have to do the
computation first, then also include something like HMAC(identityKey,
expectedResult). The prover could then know if the challenger was honest
before returning a result, and blacklist them if not.
>
> Both protocols can me made available by the client, under different
> states. For instance, new nodes are only allowed to request protocol 2
> (and so they get an initial assurance their are connecting to
> full-nodes). After a first-time mutual authentication, they are allowed
> to periodically perform protocol 1. Also new nodes may be allowed to
> perform protocol 1 with a small index set, and increase the index set
> over time, to get higher confidence.
I guess a new-node could see if different servers all returned the same
challenge response, but they would have no way to know if the challenge
response was technically correct, or sybil.
I also wonder about the effect of spinning disk versus SSD. Seek time for
1,000 random reads is either nearly zero or dominating depending on the
two modes. I wonder if a sequential read from a random index is a possible
trade-off,; it doesn't prove possession of the whole chain nearly as well,
but at least iowait converges significantly. Then again, that presupposes
a specific ordering on disk which might not exist. In X years it will all
be solid-state, so eventually it's moot.

2023-06-07 17:13:30 CEST

- reply

📅 Original date posted:2014-02-19
📝 Original message:> Longer term it would be more ideal have a canonical identifier for the
> transaction before it even gets to the chain to support these use cases,
> even if >wallets are able to properly identify the status of it's
> transactions.
> -Allen
>
>
One possible work-around to get back trusted transaction chaining for
payment channels and locked refunds from multi-sig would be to make the
initial transaction include zero fee, and depend on child-pays-for-parent
in order to get the first and follow-on transactions into a block. This of
course only works for protocols where the parties don't need the initial
funding transaction to actually hit the blockchain right away.
But this relies on two assumptions; 1) that miners won't include a
zero-fee transaction in the blockchain, and 2) that miners actually
implement child-pays-for-parent. It's definitely not the same security
as-if you had immutable txid, but it's something to consider.
1) Mutants may cause wallet spam and difficulty calculating balance (and
wallets will evolve to deal with it)
2) Mutants cause DoS because they can interfere with your own transaction
chains, which for example makes batch off-line processing much more
difficult
3) Mutants introduce a 3rd party attacker into any two-party protocol that
relies on chains
There's a lot to digest in the 'v3' transaction/block proposal. It sounds
like there may be some uncertainty over whether we can *prove* that v3
transactions in v3 blocks would actually be guaranteed immutable with
these changes?
If we cannot fully prove a Tx is immutable, then is it actually worth
taking steps to make it seem immutable, or is that just a false sense of
security in the cases where chained transactions were actually expected to
be reliable? Under that thinking, maybe it's best to accept mutants as a
fact of life, and only consider protocols and techniques that cannot be
broken by mutants.
In what cases does reducing the sources of malleability, but not
necessarily eliminating from a security proof perspective, actually help?
Basically, if we don't know that we will succeed, isn't there really no
point in trying?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/d695d83f/attachment.html>

2023-06-07 17:12:42 CEST

- reply

📅 Original date posted:2014-01-27
📝 Original message:On Jan 27, 2014, at 9:39 AM, Andreas Schildbach <andreas at schildbach.de> wrote:
> On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
>
>>> SCAN TO PAY
>>> For scan-to-pay, the current landscape looks different. I assume at
>>> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>>> into a QR-code. Nevertheless, I tried to encode a payment request into
>>> the bitcoin URL. I used my existing work on encoding transactions into
>>> QR-codes. Steps to encode:
>>
>> Really interesting work. When using scan-to-pay, after the payer scans the
>> QR code with the protobuf PaymentRequest (not a URL to download the
>> PaymentRequest) are they using their own connectivity to submit the
>> Payment response?
>>
>> How about putting a Bluetooth address in the payment_url inside the
>> PaymentDetails message for the smartphone to send back the Payment
>> response and get PaymentAck?
>
> That's exactly what I have prototyped. I am putting a Bluetooth MAC
> address into the payment_url. Have a look at the TAP TO PAY paragraph
> for details, its mostly the same mechanism.
>
Same mechanism for both, of course. Sorry, that was obvious. :)

2023-06-07 17:12:42 CEST

- reply

📅 Original date posted:2014-01-27
📝 Original message:On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
<andreas at schildbach.de> wrote:
> SCAN TO PAY
> For scan-to-pay, the current landscape looks different. I assume at
> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
> into a QR-code. Nevertheless, I tried to encode a payment request into
> the bitcoin URL. I used my existing work on encoding transactions into
> QR-codes. Steps to encode:
Really interesting work. When using scan-to-pay, after the payer scans the
QR code with the protobuf PaymentRequest (not a URL to download the
PaymentRequest) are they using their own connectivity to submit the
Payment response?
If we assume connectivity on the phone, might as well just get a URL from
the QR code and re-use existing infrastructure for serving that?
How about putting a Bluetooth address in the payment_url inside the
PaymentDetails message for the smartphone to send back the Payment
response and get PaymentAck?

2023-06-07 17:11:54 CEST

- reply

📅 Original date posted:2014-01-14
📝 Original message:On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back <adam at cypherspace.org> wrote:
> I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
> typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
> and therefore that Util.SingleSHA256() multiplies by G internally?
>
> Adam
>
Thanks for reviewing this. The relevant line:
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));
SingleSHA256 is a single application of SHA256 -- named so since 'SHA256'
functions in many Bitcoin libraries too often actually run DoubleSHA256.
32 bytes are returned.
The multiplication by 'G' that you mention is part of my EC.PointAdd...
I should probably just publish all my code as MIT and be done with it ;-)
Thanks,
Jeremy
public static byte[] PointAdd(byte[] point, byte[] scalar, bool compressed
= true)
{
var point1 = new OpenSSL.Crypto.EC.Point(EcGroup, point);
var num = OpenSSL.Core.BigNumber.FromArray(scalar);
var point2 = OpenSSL.Crypto.EC.Point.Multiply(EcGroup, num,
EcBnContext);
var result = point1.Add(point2, EcBnContext);
if (compressed)
return result.GetBytes(ConversionForm.Compressed);
else
return result.GetBytes(ConversionForm.Uncompressed);
}

2023-06-07 17:11:53 CEST

- reply

📅 Original date posted:2014-01-14
📝 Original message:On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping
>> one of the pubKeys in the OP-RETURN, to prevent a malicious sender from
>> triggering false positives on your online detection key when the funds
>> are actually still fully controlled by the payer.
>>
>> You can still have a false positive (only 1 of 2 keys actually yours)
>> but the funds would be trapped so it's unlikely anyone would do it.
>
> How would they trigger false positives? The payee recovers the nonce
> with ECDH from the payor's ephemereal pubkey and their online detection
> secret key. They use BIP32 public derivation with their offline spending
> pubkey(s), if the derived pubkeys match the actual scriptPubKey they
> know the output is spendable by them. I don't see how that can go wrong.
>
Right now I have this:
byte[] e = EC.NewPrivateKey();
byte[] P = EC.GetPublicKey(e, compressed: true);
byte[] S1 = EC.DH(e, Q1);
byte[] S2 = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));
byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S2));
stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2, q1New,
q2New));
stealthTx.Vout.Add(TxOut.OpReturn(P));
In this case, you can scan with d2, calculate S2, and matching payments
will have the right 'q2New'. But you need to check again offline with d1
since it's a separate shared secret.
Maybe you are saying:
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
But the payment would have (q2New - q1New) == (Q2 - Q1), so I think not
entirely stealth? OK, let's fix that by adding a counter to the hash
function...
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1));
byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S || 2));
stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(".995"), 2, 2, q1New,
q2New));
stealthTx.Vout.Add(TxOut.OpReturn(P));
This is assuming we want to put q2New somewhere into the transaction,
which, is it even required?
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(".995"), q1New);
stealthTx.Vout.Add(TxOut.OpReturn(P));
I'll wait for ACK and then update my sample code.

2023-06-07 17:11:52 CEST

- reply

📅 Original date posted:2014-01-13
📝 Original message:> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH. The reason to use two is that it makes delegating
> detection possible and so you don't have to have you spending keys
> online to even detect these payments. Why'd that get dropped?
I think this is exactly what I've implemented.
I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer.
You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it.
Can you take a look at the Gist and TXs on TestNet I sent out, and see if that's in line with what you expected?
I would also greatly appreciate if you could review the discussion around doing two ECDH operations with a single ephemeral key.
Thanks!
--Jeremy

2023-06-07 17:11:50 CEST

- reply

📅 Original date posted:2014-01-18
📝 Original message:> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>> Isn't there a much faster asymmetric scheme that we can use? I've heard people talk about ed25519, though I'm not sure it can be used for encryption.
>
> Doing ECDH with our curve is within a factor of ~2 of the fastest
> encryption available at this security level, AFAIK. And separate
> encryption would ~double the amount of data vs using the ephemeral key
> for derivation.
>
> Using another cryptosystem would mandate carry around additional code
> for a fast implementation of that cryptosystem, which wouldn't be
> fantastic.
>
> So I'm not sure much can be improved there.
In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds...
But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it...

2023-06-07 17:11:45 CEST

- reply

📅 Original date posted:2014-01-17
📝 Original message:I hear you, and I really don't care that much what it's called, as much as, does it work and how!
> I might even try to enter in a "reusable" address in blockchain.info, which won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
>
Regardless of what it's called, Blockchain.info should tell the user, hey this address doesn't let the whole world see every single payment that's made to it! If you paid something to this address, only you know how to find the payment - look for the stealth address in your transaction list.
So if we call the address that has the pubKeys the "reusable address" and the address that's generated from the shared secret the "stealth address" then is everyone happy? :-)

2023-06-07 17:11:43 CEST

- reply

📅 Original date posted:2014-01-15
📝 Original message:Might I propose "reusable address".
I think that describes it best to any non-programmer, and even more so
encourages wallets to present options as 'one time use' vs 'reusable'.
It definitely packs a marketing punch which could help drive adoption. The
feature is only useful if/when broadly adopted.
I think it meets all the criteria required:
- Communication between parties is a single message from the payee,
which may be public
- Multiple payments to the same address are not publicly linkable on the
blockchain
- The payee has explicitly designated they expect to receive more than
one payment at that address
- Payer can publicly prove they made a payment to the reusable address
by revealing a secret
I have high hopes for this feature. The war *against* address reuse may
soon be a distant memory.
On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik at bitpay.com> wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>> <bendavenport at gmail.com> wrote:
>>> But may I suggest we consider changing the name "stealth address" to
>>> something more neutral?
>>
>> ACK. Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140115/8d3a6dc5/attachment.html>

2023-06-07 17:11:36 CEST

- reply

📅 Original date posted:2014-01-12
📝 Original message:> You can always just extend the payment protocol with the new fields as
> well, vs making very long addresses.
I should have mentioned that as Task #4. Agree it could be an optional
extension and backward compatible. I think for displaying the payment in
the UI after it's been made via PP, we have to fully support sending to a
new standard address type anyway. Probably easiest to implement in PP
after the address and transaction building code is done.
So '4a' would be building a static PP file given the necessary inputs.
When I get to that point, I'll send out a draft PP extension with
fields/formats if someone else hasn't already. '4b' would be actually
adding support for parsing those fields and generating the new transaction
type into bitcoind.
Any thoughts on the prefix, and one vs two pubkey approach? First of all,
do we try to support both equally, or favor one over the other? I was
thinking we could have two different 4 byte prefixes but that both render
as xSTL/tSTL in Base58 but correspond to the one vs two pubkeys expected.
I think the chance of finding a single prefix which looks like xSTL for
both address lengths is 1 in (58^4)^2, so that's probably not going to
happen.
From the payer/user perspective, short stealth vs. long stealth is
irrelevant; they both have the same usability properties from the payer
perspective. So giving them the same Base58 prefix seems like a good plan.
The full 4-byte prefix seems worth the usability trade-off versus 1-byte
prefix, especially since it will impact the ability to lookup the
transaction on an outside service, which I think a lot of people do to
verify their payments. IMO a longer prefix isn't "wasting bytes" anywhere
that it really counts.
We could save two bytes in the address if we required both pubkeys to
start with '03', or save one byte if we required they both start with the
same byte, but again doesn't seem worth it (to me) for the arbitrary
restriction.
The actual internal wallet code for *receiving* STL payments and updating
balances is more tricky and probably not something I can personally tackle
for bitcoind. Assuming we even want first-class support for generating STL
addresses and receiving STL payments in a standard user wallet, someone
has to decide if the STL 'd' / 'd2' keys should be...
1) Encrypted as usual, and then keep a list of blocks with interesting
transactions, and go through them when the user enters their password?
This would cause balances to update differently than how they do now, but
perhaps be more secure.
2) Kept unencrypted to allow live scanning as usual? Or keep just 'd2'
unencrypted, with some new concept of 'unconfirmed' until the user enters
their password to prove they can spend that TX? That kind of extra step
seems OK for a merchant but sounds very scary for an average user.
3) Kept encrypted under a separate password? Meh...
And last thought for now... At some point, we might want to decide on a
convention to highlight these STL addresses as 'reusable' -- but similar
questions around revocability remain. I hope we don't need anything like a
UTC expiration time baked in to the address. A static PP file will have an
expiration date either in the certificate or in 'expires' field, so I
think if you want it to expire then use PP?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140112/462cb3bc/attachment.html>

2023-06-07 17:10:56 CEST

- reply

📅 Original date posted:2013-12-20
📝 Original message:Wow there's a lot here to think about. I'm pretty sure I haven't grasped
the full implications yet.
I see it proposes to also introduce additional BIPs describing the use of
the data stucture for stateless validation & mining, the UBC address index
for "SPV+" operating modes, document timestamping and merged mining.
Can the BIP stand alone as a BIP without some specific changes to the
protocol or end-user accessible features defined within it? It seems like
an extremely useful data stucture, but as I understand it the purpose of
BIPS is defining interoperability points, not implementation details?
Unless the tree itself is becoming part of the protocol, seems like its
spec, test vectors, and reference implementation can live elsewhere, but I
would love to read about BIPS which use this tree to accomplish some
amazing scalability or security benefits.

2023-06-07 17:10:27 CEST

- reply

📅 Original date posted:2013-12-09
📝 Original message:I can provide the server hardware and colocation (space, power, and
bandwidth) if dedicated 50Mbit in 55 S. Market, San Jose, CA data center
is acceptable.
If it needs more bandwidth than that, in a few months I hope to be getting
space in LA with 1Gbit, but I can't commit to that now.
> On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
>> It's not just about trust, there is the robustness factor: what if he
>> becomes sick, unavailable, hit by a bus? Others need the ability to
>> >>pickup and run with it. The control over the domain (including
>> ability to renew registration, alter nameservers) needs to be with more
>> than >>one person. That's why I suggest using the same people who have
>> control over the software project at sf,github
>The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
>SSL is probably a good idea, and it's probably also a good idea to
> separate bitcoin.org from Github. I don't know that I trust Github. I'm
> sure that you can >find a sponsor for a dedicated server. Let us know if
> DNS changes to bitcoin.org are required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/d012ed80/attachment.html>

2023-06-07 17:03:36 CEST

- reply

📅 Original date posted:2013-06-20
📝 Original message:> BIP 32 already specifies how to use the first three tree levels: M/i/j/k,
> i~wallet, j~Internal/External, k~address. The first level is actually
> type-1 derived, and thus we cannot create an arbitrary number of them
> without pre-computing them from the offline wallet. So it's not "free" to
> create new wallets unless we redefine how the levels work.
Initially I was thinking that you would share the public key and chain code
from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a unique
value of 'i' for each receive chain.
For the case of generating new receive chains from a *watch-only* wallet, as
you say, the options are to either keep a cache of PubKey/ChainCode for
unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] -- the
concept of 'internal/'external' and change addresses at Depth=2 don't make
sense for handing out receive chains to lots of people anyway, and certainly
BIP32 doesn't *require* 0 <= j <= 1. So I think incrementing 'j' is the way
to go here...
The "default" layout of BIP32 does NOT mean that implementations should not
check for transactions with j > 1. That would be a useless constraint and
obviously self-limiting. It might be helpful to add to the 'Compatibility'
section some minimum expectations about how a wallet should be 'probed' when
imported. If you don't feel completely free to monotonically increment 'j'
to your hearts content to achieve major usability benefits, then I say BIP32
could use some clarifying.
BTW - the spec calls for addition not multiplication now, so we should call
it the 'Addend' not the 'Multiplier' :-)
> Do these extra wallet chains behave as different wallets, or sub-wallets?
They could, but they certainly don't need to! A single-wallet
implementation treats this merely as an address-generation algorithm, and
does not expose any hierarchy to the user interface. The user just
“magically” gets the ability to send multiple payments to their contacts
without immediately sacrificing their privacy
(http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything
goes into the same ledger, balance, coin pool, etc. Most of the code base is
unaware BIP32 is even in use.
While it is *possible* to support separate ledgers, balances, etc. it is
certainly not required, and you get all the benefits either way.
I think, since your proposal generates and receives payments into
BIP32-style addresses, we both need similar underlying wallet code. The only
difference is that you are passing the Kpar for [m/i'/0/k] and the *result*
of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar, and
leaving 'k' out of it, letting the receive choose 'k'.
> For instance, maybe there's a benefit to using the same parent pubkey
> across multiple services, as a form of identity. If I don't want that, I
> use your method. If I do want that, I use my method.
I think it's a interesting idea using static public keys as a means for
persistent identity and hence security from MitM. If you want a shared
public key across multiple services we could just combine both ideas and get
all the benefits, by making the data structure { ParentPubKey, Addend,
ChainCode }:
ParentPubKey: Public key of m/i' -- 33 bytes
Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
All that remains secret is the ChainCode from [m/i'] -- and of course the
private keys. The ParentPubKey is a common value across multiple services,
corresponding to user's identity rooted in [m/i']. Each service gets their
own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j]. With the
ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
increasing 'k'. Again, from the user perspective all transactions under
[m/i'] can be presented in a single ledger, or not.
Anyway, fundamentally my feedback is if you are designing for persistent
long-term relationships, you could build in a mechanism for generating
address chains so you don't need any further communication after the initial
exchange, and it need not complicate the wallet.
Thanks,
--Jeremy

2023-06-07 17:03:35 CEST

- reply

📅 Original date posted:2013-06-19
📝 Original message:Hi Alan,
> “BIP 32 does not prescribe a way to use multiple chains like you described
> with the convenient type-2 derivation (though we could create a variant
> that does)”
What do you think is missing from BIP32 for this? A wallet creates a
child-node using the public / type-2 CDF, hands out the PubKey/ChainCode,
and then generally expects transactions to come in starting at /0 and
incrementing monotonically.
Also, I'm not sure I follow your point about the 128kB hardware wallet --
it's a signing device, so assuming it's even validating output amounts, at
worst it cares about the number of inputs to the outputs being spent, but in
many cases you're just handing it a sighash and the BIP32 "path"
(/1/54/27/0) to generate the right private key for signing. The hardware
wallet is not actually listening on the P2P network and detecting payments,
so it's unaffected by dedicating child-nodes to each contact.
Consider the benefits of gaining critical mass of support for a technique
which [I think] can be used in all cases, and increases security and privacy
for everyone. I think there are huge benefits to leaving the age of 'single
address generation' behind us...
Thanks,
--Jeremy

2023-06-07 17:03:33 CEST

- reply

📅 Original date posted:2013-06-20
📝 Original message:> which could involve proving something to a third party that has not seen
> the communication between payer and payee.
OK - I think I follow now. So a third-party who does not see any of the
communication between the payer and payee only knows the HASH160. Let's say
the payee denies receipt of the funds....
It's easy to prove what public key it was sent to (it's the preimage), but
you can't prove the parent of that public key. You can provide any number of
ParentPubKey * Multiplier that could have been used, so the 3rd party is
unconvinced by a "matching" ParentPubKey * Multiplier.
However, if you calculated the destination using: PubKeyParent *
HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a
PubKeyParent and Multiplier (or Addend) that produces the destination
address, you've proven the payment is in fact spendable by PubKeyParent, and
they can't deny receipt. Very cool.
Sorry for "echoing" this back, it took me a little while to work it out, so
I thought I'd write it down. Hope I got it right...
If you give {PubKey, ChainCode} you do get this feature. If you give
{ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to
having plausible deniability.
If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you
could give HMAC(cpar, i) instead of Addend, and then you would get this
feature; a way to 'skip down' a level in the wallet hierarchy, keep the
'chain of custody' so to speak back to the ParentPubKey intact, without
having to disclose the ChainCode. Meh...
Thanks,
--Jeremy

2023-06-07 13:49:03 CEST

- reply

📅 Original date posted:2013-04-24
📝 Original message:Payment Protocol uses x509 certs to sign a Payment Request. This
allows wallets to display meta-data from the cert to the payer instead
of the address, which should make it easier to verify where money is
being sent, and make it harder for an attacker to change the address
displayed to a user so that coins are not sent to the wrong place.
The difficulty is that Payment Requests must be generated live, and
therefore the key used to sign those requests must also be live,
exposing the key to theft similar to a hot wallet. Steal the key,
forge payment requests, and the payer sees a 'green box' but the coins
go to the attacker. The question... is there a way to sign something
once, with a key kept offline, which verifies the address in the
Payment Request belongs to the payee?
1) Given a 'parent' cert which is kept offline, and a child
certificate of 'parent' which is kept hot on the payment server.
2) Given a public key and chain code { pubKey, code } under BIP32 we
generate child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.
3) If we sign Kpar with the parent cert's key offline, we can sign the
remaining less critical data (address, I[0:32], amount, description,
etc.) with the child cert's key.
4) The payer verifies Kpar, and verifies the address by calculating
Hash160(Kpar * I[0:32])
In fact, there's no requirement to use BIP32 to calculate I[0:32], it
could also just be randomly generated.
Any I[0:32] included in the Payment Request, even if it is tampered
with, will correspond to an address for which the payee can calculate
the corresponding private key.
So the idea is your 'most trusted' cert would be used offline only to
sign a Kpar once, and a 'less trusted' cert would be used to sign the
other stuff, like 'amount', 'description', 'merchant-data', and the
'I[0:32]' as well.
I'm not an expert on x509, but I imagine the trouble is, how does the
payer know which cert is which? I was originally thinking the parent
cert would be an intermediate CA cert used to sign the child cert, but
I guess good look getting one of those, even with a name constraint,
from a Root CA. I'm not sure if you can do better than just a
'convention' such as one is an EV cert and one is not. Perhaps the
less trusted cert is actually self-signed using the EV cert, but that
requires special validation, since its no longer a standard
certificate chain. I would love to hear a better idea.
Any comments if this is something worth pursuing? I think there are
definitely benefits if merchants can keep the key signing the address
offline.
Thanks,--Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130424/9156de8b/attachment.html>