<unnamed>

Public Key

npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727

Profile Code

nprofile1qqs8u4mxdnlhephegyxn84xnfme72yznjkeuwjh5wf2pm0htwslemccpzpmhxue69uhkummnw3ezuamfdejsntvvpp

Publishing to

nostr.wine

Last Notes

2023-06-07 15:32:01 UTC

- 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 15:23:45 UTC

- reply

📅 Original date posted:2014-07-15
📝 Original message:Payment Protocol would probably be the communication format for any new
meta-data.
What's the likelihood of something like this every making it on the
blockchain?

2023-06-07 15:13:30 UTC

- 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 15:12:42 UTC

- 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 15:12:42 UTC

- 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 15:11:54 UTC

- 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 15:11:53 UTC

- 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 15:11:52 UTC

- 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 15:11:50 UTC

- 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 15:11:45 UTC

- 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 15:11:43 UTC

- 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 15:11:37 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> > 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.
On Sun, 12 Jan 2014 10:26:18 -0800, Mike Hearn <mike at plan99.net> wrote:
> Why? Showing an address is meaningless, especially if the user didn't
> type it in or see
> it somewhere else. It's just an opaque random number, all putting it in
> the UI can do is
> make it look scarier :)
>
> Part of the point of the payment protocol is it lets merchants provide
> human readable text
> for transactions instead of addresses.
Of course you're right, moving away from addresses is definitely part of
the point of PP.
On Sun, 12 Jan 2014 13:18:33 -0800, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or
> we'll spend the next
> two years writing code that tries to ignore linebreaks and spaces and
> changing <input> in HTML
> forms to <textarea>...
Agreed, it's long enough to be even more problematic than usual. If the
general consensus is that there should not even be a standardized address
form, then I can skip that entirely, and go straight to trying to extend
PP.
It's a given this will be implemented for Payment Protocol. The question
is whether it's also usable outside of PP.
I was kind of imagining that we could encourage people to replace all
their static address text that live on Github pages, and README.me, and
forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention
could be to require only transporting xSTL addresses within a URI, even
going so far as to not support them copy/pasted. 101 characters is not
much longer (and sometimes shorter) than PaymentRequest URIs end up being.
I think there are ways to make stealth addresses easy enough to use that
people actually prefer using them for P2P payments which do not involve a
full-stack merchant. In that case, if it was a PaymentRequest it would
almost certainly not be signed, and would be more easily shared over email
or SMS as a URI than as a file attachment or, even worse, putting the
unsigned PR file up on a third-party server which probably won't do a good
job securing it.
* PP Implementation Overview *
The basic PaymentRequest>PaymentDetails is expecting 'output' containing
one or more TxOuts with script and amount. I believe the general approach
is to put a fallback address into 'output' for backward compatibility, and
put Q and Q2 into an extension field.
So we add a new optional field to PaymentDetails which contains the one or
two PubKeys. Not sure if we want different protobuf tags, or if the
difference in length of the value makes it obvious enough which approach
is being used;
optional bytes stealthOnePubKey = 1000
optional bytes stealthTwoPubKey = 1001
or just
optional bytes stealth = 1000
* User Interaction / Flow *
Lets follow this through from the user perspective, starting with what it
looks like today. I'm having a hard time finding screenshots of what PP
looks like in BitcoinQT, so I built from HEAD and using Gavin's
Handy-Dandy PaymentRequest Generator
(https://bitcoincore.org/~gavin/createpaymentrequest.php):
Screenshots: http://imgur.com/a/k6j9D
Image 1 - 'Send' screen after clicking a PR URI with a small transaction
and auto-calculated fee
Image 2 - System Tray notification after clicking 'Send'
Image 3 - Transaction List showing partially confirmed transaction
Image 4 - Transactions details popup
We see 'Pay To' (Common Name from the cert) and 'Memo' on the Send screen.
The System Tray notification popup and Transaction List shows just the
address string. The 'Transaction details' window shows 'Merchant' which I
think is the same as 'Pay To'. You also have 'Copy address' option in the
right-click menu.
Memo seems not to be saved, or at least not visible in the UI after
sending a payment.
* Transaction Display *
The address string is fairly pervasive, which is why I was originally
thinking it would make sense to implement all the address handling first,
so all those screens would continue to work as specified, without trying
to hack something different in those fields.
Without digging too far into the code, it looks like "address" displayed
is derived from the TxOut -- e.g. script.cpp:ExtractDestination. This
could be a bit problematic depending on what we really want to show to the
user -- the stealth multisig, or the pubkeys?
Part of the point of stealth addresses is actually making them reusable.
So if you're the originator of the payment, you might want the wallet to
tag that transaction somehow with the pubkeys used to generate it.
Also, ideally I think I would want multiple different stealth payments
within a single wallet to the same merchant / pubkeys to be identifiable
as such.
* Sample Code *
Will follow in another email, to be sent shortly!

2023-06-07 15:11:36 UTC

- 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 15:11:35 UTC

- reply

📅 Original date posted:2014-01-12
📝 Original message:> Oh, sorry, I forgot to mention it in my first write-up but you can
> easily make stealth addresses include a second pubkey for the purpose of
> the communication that either isn't used in the scriptPubKey at all, or
> is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> can give a third-party that key and out-source the effort of scanning
> the blockchain for you.
Great point. Even if it's not a 3rd party, I think it's really important
to be able to scan for transactions with a key which can't actually spend
the funds.
The first approach is just one-pass ECDH. I think you're saying the second
approach is two rounds of ECDH but re-using the same e/P (usually referred
to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key
for signing operations.
Payee: Publish Q, Q2 [d, d2 are privkeys, Q, Q2 are
pubkeys]
Payer: 1) Generate ephemeral key: e / P [e is privkey, P is pubkey]
2) S = e * Q [first shared secret]
3) S2 = e * Q2 [second shared secret, reusing
'e']
4) Q' = Q + H(S) [pay-to stealth address]
5) Q2' = Q2 + H(S2) [stealth 'marker']
Watch: 1) Look for TxOut with OP_RETURN <P>
2) Q2' = Q2 + H(d2 * P)
3) Check for Q2' elsewhere in the Tx
S/MIME for example, allows reuse of the ephemeral keypair. When reusing an
ephemeral keypair where A reuses (x, X) to encrypt different messages to
more than one user, A should verify the static public keys to prevent
small-subgroup attacks.[1][2]
Let's say you pay-to Q' and then Q2' value has to be somewhere else in the
transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN
<P> <Q2'> would be 66 bytes.
But then Mallory could generate transactions with the right Q2' but with
his own pubkey in Step 2 instead of Q. So your scanner would detect a
payment, but you wouldn't be able to spend it, and Mallory could.
That's a good argument for putting Q2' in a 2-of-2 multisig so that
pulling this trick would at least make the transaction unspendable for
both parties, which may be good enough deterrent, but you're still going
to want to check it against your 'd' before fulfilling a large order. Your
online watch process could queue the matching transactions, which you
could move to your offline machine, decrypt your key, and verify the
transactions are spendable.
Now, you would need to get two pubkeys to the payer, throw in a prefix to
help standardize it, and end up with addresses that could look like (for
example):
xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba
Those addresses are 74 bytes:
<Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>
xSTL Prefix = 0xC0CB9270
tSTL Prefix = 0xB2E27D50
NOTE: I do NOT have the corresponding privkeys for these four pubkeys!
Those just happened to be the first matching prefixes I found for 74 byte
addresses. I could try to find ones which start with a specific byte if
that's somehow better, like 0x04 to match BIP32.
Unfortunately, I don't think you can just derive a second public key from
the first to keep the address shorter, and still keep the first private
key secure, even if the second private key is stolen. You only get
equivalent security as BIP32 public derivation, where you can't lose a
child private key.
Do we also want xSTL (or whatever user friendly string) prefixes for
single pubkey (41 byte) stealth addresses?
I'll wait a couple days for feedback, then I'll try to implement the
following prototypes:
1) Pay to STL addresses
2) Watcher process to detect and queue STL payments for a given d2/Q2
3) Offline verifier to take output from Watcher and verify spendable given
encrypted d/d2
Obviously extending QT directly for #1 would be ideal, I may even be able
to do that since supporting a new address type should be fairly contained.
But if not I'll punt to writing a node.js or python script which connects
to bitcoind via RPC.
Thanks,
Jeremy
[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf
[2] - Validation of Elliptic Curve Public Keys
http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf

2023-06-07 15:11:34 UTC

- reply

📅 Original date posted:2014-01-08
📝 Original message:Thanks Peter for the paper!
I'm just going to restate your 'simple explanation' to make sure I got
it...
The payee publishes a public key of theirs, which will be a long-standing
identifier, public key = 'Q', corresponding private key = 'd'.
To pay them, payee generate a keypair, private key = 'e' public key of
'P'. Publish 'P' in the transaction.
The payer can calculate S = eQ, where S is a shared secret between
payer/payee. The payee calculates the same S as S = dP. So the payee sees
'P' in a transaction, and multiplies by their private key, to get S.
Now that we have the shared secret, either side can calculate an offset to
Q which becomes the pay-to-address. When you say BIP32-style derivation,
Q' = H(S) + Q, does this mean Q + SHA256(33-byte S)?
A payee has to check each transaction (or every transaction of a fixed
prefix) with 'P', calculate Q' = Q + H(dP) and see if that transaction
pays to Q'. If the address matches, then the payee can spend it with
private key of d + H(dP).
One downside is that you have to hold your private key in memory
unencrypted in order to identify new payments coming in. So
stealth-addresses may not be suitable for receiving eCommerce payments,
since you can't implement a corresponding watch-only wallet, e.g. there's
no way to "direct-deposit into cold storage."
Hope I got that right...
On Mon, 06 Jan 2014 04:03:38 -0800, Peter Todd <pete at petertodd.org> wrote:
> Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
> secret that the payee can use to recover their funds. Let the payee have
> keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to
> arrive at shared secret c=H(eQ)=H(dP). This secret could be used to
> derive a ECC secret key, and from that a scriptPubKey, however that
> would allow both payor and payee the ability to spend the funds. So
> instead we use BIP32-style derivation to create Q'=(Q+c)G and associated
> scriptPubKey.
>
> As for the nonce keypair, that is included in the transaction in an
> additional zero-valued output:
> RETURN <P>

2023-06-07 15:10:56 UTC

- 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 15:10:27 UTC

- 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 15:03:36 UTC

- 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 15:03:35 UTC

- 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 15:03:34 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:If you have two parties who want to form a persistent relationship, by exchanging and verifying public keys beforehand, then I think the canonical way to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.
I don’t understand the use case for handing out individual multipliers, if what you desire is a persistent relationship. If each party dedicates a child-wallet for receiving coins, and saves a PubKey/ChainCode for sending coins, the two parties can transaction securely forever without ever exchanging any more information, and without any address reuse.
I think ideally, the default behavior is that wallets always dedicate a new child node {PubKey, ChainCode} to each party they transact with. At the presentation layer, you have a “contact” and each contact has a transaction history. You can send coins to a contact at any time, and internally the wallet picks the next address in their sequence. Any funds received on pubkeys from contact’s sequence are attributed to that contact. The wallet can organize the contacts, and roll-up the transaction history into ‘ledgers’ and ‘balances’ however they want – it could be based on the underlying BIP32 hierarchy or perhaps not. The cost of watching large a number of pubkeys, even if you ‘look ahead’ 100 pubkeys for each contact, is relatively small versus the benefits.
What might be nice is a ‘Contact Request’ protocol, basically the same as a PaymentRequest but no actual payments are sent, just child wallets created:
message Contact {
optional uint32 contact_version = 1 [default = 1];
optional string pki_type = 2 [default = "none"];
optional bytes pki_data = 3;
required bytes serialized_contact_details = 4;
optional bytes signature = 5;
}
message ContactDetails {
optional string network = 1 [default = "main"];
required bytes pubkey = 2;
required bytes chaincode = 3;
optional string memo = 4;
optional string response_url = 5;
}
Alice sends a Contact+ContactDetails to Bob. If Bob accepts, he sends his own Contact+ContactDetails (without a response_url) back to Alice. Basically just like adding a contact to your IM contacts.
Alice could send a Contact+ContactDetails to Bob without a response_url, in which case after accepting the contact, Bob could send funds to Alice, but not receive funds.
You could probably pack the whole message inside a bitcoin:// URI if you wanted to.
Thanks,
--Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/81654330/attachment.html>

2023-06-07 15:03:33 UTC

- 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 11:49:03 UTC

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