Jeremy Spilman [ARCHIVE]

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

Public Key

npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727

Profile Code

nprofile1qqs8u4mxdnlhephegyxn84xnfme72yznjkeuwjh5wf2pm0htwslemccprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqn39aj3

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727

Show more details

Last Notes

2023-06-07 15:32:04

- reply

📅 Original date posted:2015-03-27
📝 Original message:> On Mar 27, 2015, at 8:16 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
>
> Isn't the goal of this exercise to ensure more full nodes on the network?
Basically we're talking about a form of Sybil defense and better quantifying true blockchain resiliency by proof of storage.
In this case the goal is to see if we can prove the number of distinct digital copies of the blockchain. This is actually a tricky problem because it will (always?) devolve to inferences from response timing, and we are running over a heterogenous network with heterogeneous machines.
It would be extremely impressive to achieve a reliable mechanism for discerning a local copy exists under these constraints, particularly without false positives and false negatives, and without imposing very substantial one-time encoding costs, e.g. on par with doubling the verification cost.
I think while its a difficult cost-benefit analysis, even code complexity aside, it's interesting to discuss all the same!
Simply having many unique IP addresses possibly accessing the same unique copy provides a different (if any) benefit. E.g. Tor uses IPs as a cost factor, but (until recently?) didn't even factor in things like them all being the same Class C.

2023-06-07 15:32:01

- 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:28:10

- reply

📅 Original date posted:2014-12-20
📝 Original message:On Sat, Dec 20, 2014 at 08:57:53AM +0000, Matt Corallo wrote:
>> There was recently some discussion around dnsseeds. Currently some
>> dnsseeds are getting blocked by ISPs because the hosts they pick up
>> (which run bitcoin core nodes) often run rather web servers alongside
>> which serve malware or whatever else and thus end up on IP-based malware
>> blacklists.
On Sat, 20 Dec 2014 02:08:17 -0800, Roy Badami <roy at gnomon.org.uk> wrote:
> Why would we want to have anything to do with people who are hosting
> malware? Or do I misunderstand?
It sounds like Matt is saying the nodes the dnsseed is pointing to as
valid full nodes, that those IPs are hosting the malware. Since the
dnsseed picks up any stable nodes it can find without auditing, it's
perhaps not surprising some servers in the world are running a full node
and a malware server together.
I guess what confused me about this though, how are ISPs reading the
dnsseed's node list, scanning *those* IPs for malware, and then ending up
blocking the dnsseed? Seems like a pretty winding path to end up blocking
a DNS server?
Since when do ISPs null-route a DNS server for happening to resolve some
domains to IPs which happen to also be hosting some malware? Null-route
those endpoint IPs sure, but the DNS server too? I guess there was that
incident of Microsoft taking over No-IP.com -- are dnsseeds being blocked
ostensibly because they are acting as dyanamic DNS infrastructure for
malware sites?

2023-06-07 15:23:45

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

- reply

📅 Original date posted:2014-03-02
📝 Original message:On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn <mike at plan99.net> wrote:
> 3) Whilst these payment processors currently verify merchants so the
> security risk is low, in future a lighter-weight model or competing
> sites that >allow open signups would give a weak security situation: a
> hacker who compromised your computer could sign up for some popular
> payment >processor under a false identity (or no identity), and wait
> until you use your hacked computer to make a payment to someone else
> using the same >payment processor. They could then do an identity swap
> of the real payment request for one of their own, and your Trezor would
> still look the same. >Avoiding this is a major motivation for the entire
> system!
Let me restate that, it's a huge problem...
Alice's system is compromised,
Mallory intercepts a payment request being sent to Alice from payment
processor X on behaf of merchant X.
Mallory regenerates a spoof payment request which pays to M, from the same
payment processor
Alice can't tell Mallory's spoofed PR apart from Merchant X's and thinks
she's paying Merchant X
It might be a bit challenging for M to generate the new PR on-the-fly
without being noticed, but that's not a security guarantee.
Perhaps the UI just isn't expressive enough currently to expose this
situation in any way, let alone reliably alert the user to the issue,
because there's no way for the payment processor to get authenticated
fields other than memo into the UI.
Today the only solution is for the payment processor to strictly control
the 'memo' field so Mallory wouldn't be able to make his own PR that
looked exactly like merchant Y's. But maybe it's too subtle to make
payment processors embed that kind of information.
So is the main goal is to provide a structured way to embed this
information in the PR and expect that user interfaces will display them to
end users? If that's the case, I don't think we need an entirely secondary
certificate, or cross signing from a secondary ECDSA key.
A poor solution: If the UI included some sort of certificate viewer, even
just tied to the OS certificate viewer, and made the cert available for
inspection, at least the merchant would have a chance to put some fields
in there which a very advanced user might actually find. But this was
discussed a while ago and I think the primary problem is the difficulty in
getting a CA to let you embed any additional fields in your certificate in
the first place, plus you don't want to generate a new cert for each
merchant.
A somewhat better option: Some additional fields defined in an extension
which are reliably shown in the UI. We could try to define specific
fields, like 'DelegateCN' which would possibly override the primary CN...
As an aside, I think you can never allow actually overriding the CN
displayed in the UI directly, the most you can do is add another field in
the UI to show this string. First I need to know it's from Payment
Processor X, and then maybe we can let the payment processor make some
additional claim, like yes you are paying irs.gov. You can't give the
impression that Payment Processor X is not actually man-in-the-middle.
Maybe the simplest would be a single field expected to contain a delimited
key/value string (of course JSON) which could be shown as additional lines
of labeled text in the UI. I don't want to give the "merchant" too much
dynamic control over what the user's screen will display, but making it
somewhat dynamic might add some future proofing.
I think any additional extension fields should be hashed using the hash
function specified in pki_type and signed by X509Certificates.certifcate
private key. No extended_certs required -- I'm thinking something like;
message PaymentRequest {
// new field
optional bytes extended_properties = 6;
optional bytes extended_properties_sig = 7;
}
Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140302/1195f53c/attachment.html>

2023-06-07 15:14:07

- reply

📅 Original date posted:2014-03-02
📝 Original message:From BIP70:
If pki_type is "x509+sha256", then the Payment message is hashed using
the
SHA256 algorithm to produce the message digest that is signed. If
pki_type
is "x509+sha1", then the SHA1 algorithm is used.
A couple minor comments;
- I think it meant to say the field to be hashed is 'PaymentRequest' not
'Payment' message -- probably got renamed at some point and this is an old
reference calling it by its original name.
- Could be a bit more explicit about the hashing, e.g. 'copy the
PaymentRequest, set the signature field to the empty string, serialize to
a byte[] and hash.
- SHA1 is retiring, any particular reason to even have it in there at all?
- Should there any way for the end-user to see details like the pki_type
and the certificate chain, like browser do?
Thanks,
Jeremy

2023-06-07 15:14:06

- reply

📅 Original date posted:2014-03-01
📝 Original message:We currently have subtle positive feedback of a signed payment request in
the form of the green background. Unsigned requests simply show up without
the green background, as well as requests which provide a certificate but
have a missing or invalid signature.
There's a open bug (#3628) and pull request (#3684) to provide negative
feedback (yellow background) for a missing or invalid signature, but it
seems like there's some debate on whether bitcoind should do that...
If an attacker can avoid the negative feedback by just stripping the
signature and setting pki_type to none, then arguably there's no security
benefit by singling out badly signed payment requests from unsigned
payment requests.
So perhaps the root problem is that the positive feedback (green
background) is not strong enough to make its absence highly conspicuous to
the end user.
As an aside, how could we go about implementing the equivalent of HTTP
Strict Transport Security for payment protocol to prevent this trivial
signature stripping attack? Is this a possible extension field merchants
are interested in?

2023-06-07 15:14:06

- reply

📅 Original date posted:2014-03-01
📝 Original message:On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir <laanwj at gmail.com> wrote:
> Such a thing would be interesting for a future BIP standard. I see one
> problem here: for an unsigned payment request there isn't really an
> "origin". >Browser URI handlers don't send the referrer either.
Yeah, good point. If you have a cert, we have the CN from the cert, which
becomes the string displayed as 'Pay To' and alternatively 'Merchant'.
But if there's no cert then all you have is memo.
So the best way to differentiate signed requests is by prominently
displaying that Merchant string. Really the green part should just be the
'Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that
would make the lack of certificate highly apparent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140228/4ceb93c0/attachment.html>

2023-06-07 15:14:03

- reply

📅 Original date posted:2014-02-25
📝 Original message:If I understand correctly, the risk here is this would open a historically
large discrepancy between MIN_RELAY and the expected minimum fee to
actually obtain block inclusion. I don't know if that's true, but I think
that's what Peter is saying makes it different this time.
The relay network does anti-spam with MIN_RELAY and MIN_DUST, but of
course only transactions which hit the blockchain actually PAY the fee, so
this allows lower-cost spam in the true dollar sense.
I guess it comes down to how 'sharp' the edge is between staying above
MIN_RELAY and staying OUT of the blockchain. In the worst case, there's a
completely deterministic boundary, so an attacker can generate an infinite
number of transactions which are guaranteed never to see the inside of a
block, and so therefore completely free for the attacker, and all of which
the network will relay (by default).
On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn <mike at plan99.net> wrote:
> Nodes that are encountering memory pressure can increase their min relay
> fee locally until their usage fits inside their resources. It's annoying
> to do this >by hand but by no means infeasible.
Perhaps this is just another way to think of the floating fee problem.
What does MIN_RELAY need to be so that my local resources stay within some
reasonable limit (and 'reasonable' means different things to different
nodes).
We have an input gate on transactions entering mempool, we persist
mempool, and I don't know the specifics but, I assume there's some
expiration policy other than block inclusion to clear out a Tx from
mempool. But are transactions prioritized in any way after they make it
into mempool today?
How closely should mempool selection align with the expected block
inclusion? I think if they align perfectly in theory that means optimal
mempool resource allocation. For example, a miner would push out cheaper
transactions which they were previously hashing against to make room for
higher fee transactions (bsaed on max block size or orphan rate
projections), but do we do the same for mempool? E.g.
- After hitting X number of transactions, the fee has to be larger than
a transaction in mempool in order to get in,
- That in turn that ejects a random transaction which paid less fees
than the incoming Tx from mempool
- We would have to consider how ejection would work with chains of
unconfirmed transactions (cumulative average fee/kb?) but again in this
case, you would want to 'do what miners would do' if you could
Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140225/2bd6429a/attachment.html>

2023-06-07 15:14:00

- reply

📅 Original date posted:2014-02-24
📝 Original message:On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik <jgarzik at bitpay.com> wrote:
> This PR reduces the size to 40 bytes:
> https://github.com/bitcoin/bitcoin/pull/3737
Just quickly GLANCED at it, but if I understand correctly how the template
matching code works, that will change max size of the <data> to 40 bytes
but does not do anything to enforce most-efficient encoding.
else if (opcode2 == OP_SMALLDATA)
{
// small pushdata, <= MAX_OP_RETURN_RELAY bytes
if (vch1.size() > MAX_OP_RETURN_RELAY)
break;
}
This code was a bit hard for me to parse since it's not actually requiring
any data, just disallowing more than a certain number of bytes of data. So
a bare OP_RETURN would be allowed as well, for whatever good that will do.
If you want to strictly require no PUSHDATA, perhaps you could do:
else if (opcode2 == OP_SMALLDATA)
{
// small pushdata, <= MAX_OP_RETURN_RELAY bytes
if (opcode1 >= OP_PUSHDATA1 || vch1.size() > MAX_OP_RETURN_RELAY)
break;
}
Thanks,
Jeremy

2023-06-07 15:13:30

- 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:13:11

- reply

📅 Original date posted:2014-02-25
📝 Original message:>
> So in summary the spec needs daily as an option, and to specify the
> recurring cycle as every n*period >(one of daily, weekly, monthly,
> yearly): and you can drop quarterly since it's just expressed as per
> >3*monthly.
If you're going to go the direction of a {unitType, unitsPerInterval}
tuple, then I think the only two units you could ever want are minutes and
months. All other standard units of time can be expressed in terms of
those two, right?
Also consider changing "optional uint64 ends = 4;" to be a interval count
instead of a UTC timestamp, to avoid any ambiguity over how the 'while'
loop should be implemented.

2023-06-07 15:13:01

- reply

📅 Original date posted:2014-02-05
📝 Original message:Well the point of the Merkle tree is that if I all you have is the top,
and all I give you is a leaf node and the siblings of all parents of that
leaf, then by simply hashing you can check if the node was actually
present in the tree.
The only reason this works is because it's hard for an attacker to come up
with the list of values which would ultimately hash together to produce
the expected top value. But if the hash function is actually just XOR, it
becomes completely trivial for me to claim any value I want was in the
tree.
1) Pick the fake value you want to claim was in the tree (leaf node)
2) Choose some random values to fake the depth in the tree
3) Calculate the last value as 'Prev (x) Top'
4) When your victim goes to verify set membership, they will get the top
value they expected
On Tue, 04 Feb 2014 08:04:14 -0800, Peter Todd <pete at petertodd.org> wrote:
> On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote:
>> Because it's trivial to create collisions! You can choose exactly what
>> output you want. That's why XOR is a very bad digest scheme.
>
> You're close, but not quite.
>
> So, imagine you have a merkle tree, and you're trying to timestamp some
> data at the bottom of the tree. Now you can successfully timestamp the
> top digest in the Bitcoin blockchain right, and be sure that digest
> existed before some time. But what about the digests at the bottom of
> the tree? What can an attacker do exactly to make a fake timestamp if
> the tree is using XOR rather than a proper hash function?

2023-06-07 15:12:53

- reply

📅 Original date posted:2014-02-02
📝 Original message:>
> Consequently you can now securely and very network/space efficiently
> securely delegate searching a block by computing the private key for the
> IBE pub key that any sender would use for that block, and sending it as
> a query to a random (or node-capture defended random selected node).
> The node can decrypt the encrypted bloom baits with it, but remains
> powerless to correlate with bloom baits to other payments received by
> the same user in bother blocks.
>
I'm not sure I've fully wrapped my head around it.
d/Q - Identity key
E - Generate an epoch-pubkey: E = Q * H1(epoch)
r/P - Ephemeral privkey/pubkey, or discoverable from inputs
S = r * K - Shared secret (ECDE)
Payer derives an encryption key H(S), and encrypts M, which is a 1 byte
bloom bait.
For each epoch, payee generates e = d * H1(epoch) and provides the key to
a full node for monitoring. So you are providing a per-block or per-epoch
private key, along with the block ID or epoch ID that the key corresponds
to.
The full node then uses this privkey to decrypt the same byte in all the
transactions in that epoch/block which match the expected layout/template,
e.g. given a certain length OP_RETURN, pull the specific byte and decrypt.
This decrypted byte is then in turn used as bloom bait which may or may
not cause the transaction to be sent back to the SPV client.
Am I right in saying the full node has no idea if decryption is
'succeeding' it just feeds the resultant bait into the bloom filter and
the transaction may match or not? So we do get some level of repudiation
by the SPV client -- the server doesn't know exactly which transactions
belong to the SPV client.
The bloom bait specified in the reusable address is still making the
bandwidth/privacy trade-off, it just doesn't become public information,
because it's protected by another factor?
What encryption scheme is being used here?
-=-=-=-==
Another approach (inspired by IBE) which narrows the discoverability of
transactions to the nodes that your SPV client is actually communicating
with, for the specific blocks/epochs that you specify, would be to use
PEKS.
PEKS(Q, W) for a public key Q and a keyword W produces a searchable
encryption of the word W.
The payee holding 'd' (privkey for Q) can create a trapdoor which allows a
server to search for transactions with W, where the searching party only
knows if a match is found or not.
Payer:
d/Q - Longstanding / identity privkey/pubkey
r/P - Ephemeral privkey/pubkey, or discoverable from inputs
W - Searchable Keyword
H1 - Hash function, {0, 1} ∗ → G1
H2 - Hash function, G2 → {0, 1}p
Secret, as usual per ECDH:
S = r * Q
For payer to create the searchable encryption of W for Q, called 'Sw':
Sw = H2(e(H1(W), S))
OP_RETURN P, Sw
For payee to search for a given 'W', payee calculates a trapdoor 'Tw':
Tw = d * H1(W)
For a searcher, given a Trapdoor (Tw), check each Transaction (P, Sw):
H2(e(Tw, P)) ==? Sw
If the values match, the keyword matches
Without getting into the concepts of e(g,g) and binomial pairing, I think
of it this way:
Sw = H2(r * Q * H1(W)), but recall: rQ == dP, so...
= H2(d * P * H1(W)), which can be written
= H2(d * H1(W) * P)
Severs finds all transactions with 'P' on relevant parts of the
blockchain, multiplies by the provided trapdoor 'Tw', applies 'H2', and
checks for a matching 'Sw' in the transaction;
Tw = d * H1(W)
Sw = H2(Tw * P)
H2(d * H1(W) * P)
PEKS is vulnerable to an offline keyword guessing attack, where you can
discover the value of the keyword being searched, if the keyword is low
entropy. The server/attacker can figure out the value of W, but they can't
generate their own trapdoors to search for other keywords.
But in this case, the 'keyword' can simply be the block ID / epoch ID
itself, not a secret value at all. In other words, the server can only
search for your transactions within the blocks/epochs that you specify.
Using blockID/epochID as W, this would allow a server to find all
transactions belonging to the payer for that blockID / epochID. The SPV
client would simply provide the trapdoor for each block/epoch to be
searched.
There are extensions to PEKS which provide for 'fuzzy' matching but they
are 'fuzzy' within the scope of Q, not across different Q, so that doesn't
help provide any repudiation. So I see this as only slightly improving
Peter's original proposal of providing 'Q' to the searcher, but if you
want repudiation, not as good as Adam's solution.
Perfunctory disclaimer... Hopefully this is close to correct, but please
don't anyone actually try to implement this!
Thanks,
Jeremy

2023-06-07 15:12:42

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

- reply

📅 Original date posted:2014-01-24
📝 Original message:>
>
>
> I think we need to provide users with better options than that.
>
Perfect privacy without extraordinary computational overhead today means downloading everything. But we could provide better tools to *shift* bandwidth requirements rather than try to reduce them.
I've been thinking about a setup where user runs a UTXO only, and maybe even outbound-connect only (like bitcoinj), full node at home. Then using Tor, mostly for tunneling, they host a hidden service they can connect back to from their smartphone to see balances, manage receive addresses, send funds, etc.
The smartphone is not doing SPV, it's like a web client for the wallet running at home. The initial connection between the smartphone and home wallet has the phone learn two codes, one is the hidden service name, another is an access token which is revocable. You may require further authentication from that point.
With fast bootstrapping / checkpointing of the UTXO I think usability could be as good as SPV, and you would get push-notification of relevant transactions with zero privacy trade-off.
I wonder if people would want to run such an app, if they would run it on their desktop, a dedicated machine, or an old smartphone or other cheap ARM device.

2023-06-07 15:12:03

- reply

📅 Original date posted:2014-01-13
📝 Original message:* Transaction *
I spent 1BTC on TestNet to a stealth address...
TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
http://blockexplorer.com/testnet/tx/df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c#i8166574
* Code *
Code which generated this transaction is here:
https://gist.github.com/jspilman/8396495
Note, one minor change from the protocol we discussed is I'm just using
the 32-byte x coordinate for the shared secret, not the compressed pubKey
(so, throwing away the first byte) before hashing with SHA256.
* How it Looks *
After importing the privkey for the TxIn to that transaction
(importprivkey "cNL8XqRtqwC1YEc9kKspbX2aukWnXfgHQSvjsPYbuPif5Q3DJkEs"
rescan) you will see two rows in the Transaction List of Bitcoin-QT...
Both rows simply say 'Sent to' with a blank address. One has 1BTC amount
which is the 2-of-2 stealth multisig, the other has 0BTC amount, and it's
the OP_RETURN.
I wonder if the 0BTC OP_RETURN transactions should be hidden from the
Transaction List? 'Transaction Details' truncates the <data> after
OP_RETURN anyway, so it's not even particularly useful for seeing what
data you embedded.
* Next Steps *
I'm not quite sure. If we're going to try to deploy this, I think we need
to fully understand what users who are making these payments should see in
their wallet software while making a payment, and after a payment has been
made.
Right now I'm thinking...
1) Define the PaymentRequest extension
2) Update Gavin's PHP to generate PaymentRequests for stealth payments
3) Get Bitcoin-QT loading the PaymentRequest and generating transactions
from those PaymentRequests
4) Write an agent to detect incoming stealth payments
But we would still be showing meaningless rows in the payer's Transaction
List without some additional work.
If there is a place to add TxOut meta-data with the pubkeys used to
generate it... well, there must be since the 'Merchant' field is attached
somehow. So we could probably use the same method to keep the pubKeys
around.
Maybe the simple way to punt on this is to just show 'Merchant' in the
address column if it is available and an address is not. We could skip
saving the pubKeys for now, so there would be no way to send follow on
stealth payments, but at least the Transaction List would make sense
instead of looking like two empty transactions.
* Other Open Questions *
I think the biggest is if/how to receive P2P stealth payments in
Bitcoin-QT as an end-user not a merchant.
I can probably make the necessary changes to IsMine, but I don't know
where we should keep 'd2'/'Q2' unencrypted so it's available for doing the
necessary tests, but has no chance of ever be used as a stand-alone
private key?
And then there's still the question of: when 'd1'/Q1 is available
decrypted, we must fully verify the transaction, and how to indicate if
that has or has not been done yet.
It really seems crippled to me without fully integrated support for
receiving P2P stealth payments in Bitcoin-QT. It doesn't seem like that
much code, just some details to work out first.

2023-06-07 15:11:59

- reply

📅 Original date posted:2014-01-21
📝 Original message:On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
> I'd point out that regardless of how long the desired prefix is, the
> encoded prefix should probably always be constant length in all
> reusable addresses.
I might be misunderstanding, but I think prefix length must be specified
in the reusable address, however I agree the prefix actually published to
the blockchain should be constant length.
> If you don't want a particular prefix then the
> sender should just pick random data for the rest of the space. There
> is no need to publish any additional distinguishing data in the form
> of how long the prefix is.
Let's say the payee's reusable address is '<version> <prefix> <Q1> <Q2>
...', where <prefix> is 2 bytes. Without any length indicator. What's the
payer going to put on the blockchain? How would they know what the 'rest
of the space' is? They would have to put the whole <prefix> verbatim into
the OP_RETURN without knowing how many bits of <prefix> the payee actually
wants to see there.
If instead, the address is '<version> <prefix> <prefixLen> <Q1> <Q2> ...'
where <prefix> is 2 bytes, and <prefixLen> is 1 byte, representing number
of bits of prefix that should be fixed.
Then payer will know how much of <prefix> from the address should be taken
verbatim, and the rest of the two bytes would be replaced with random
data, and exactly two bytes would be put in the OP_RETURN.
If <prefixLen> was zero, the 2 byte prefix in the reusable address must be
ignored, and an entirely random 2 byte prefix would be put into the
OP_RETURN.
I'm a bit worried about broken implementations copying the <prefix> from
the reusable address into OP_RETURN when <prefixLen> is 0, and ending up
basically identifying the payee. That's the only reason I can think of to
make '<prefix> <prefixLen>' optional in the reusable address, to prevent
the opportunity to screw it up. You would *still* put a 2-byte random
prefix in the OP_RETURN, even if the fields weren't in the address at all.
It's just a minor concern though.

2023-06-07 15:11:58

- reply

📅 Original date posted:2014-01-15
📝 Original message:On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back <adam at cypherspace.org> wrote:
> I was meaning to comment on the SPV privacy properties.
>
> For full-node use these unlinkable static addresses have quite nice
> properties. It also nicely solves the problem of having to educate users
> and wallet authors to not reuse addresses. But for SPV nodes they have
> no direct-way to find the payments. So then in Peter Todd's variant
> (maybe it was suggested by Greg Maxwell?) there is a second address so
> that the SPV
> client can delegate detection to a full node without giving it the
> private key allowing it to spend! (This is something analogous to bloom
> filtering).
The second pubKey is useful for delegating scanning, or even just being
able to scan for transactions yourself without keeping bitcoin-encumbered
private keys decrypted in memory. So even while running your own full node
there are good reasons to use a second pubKey to derive the shared secret.
> But I think its moderately expensive for the full node because it has to
> do a DH calculation per transaction and its not precomputable so there
> is IO
> per query. (In the P version in fact only payments which are thereby
> reconizable as unlinkable static need to be processed).
And of course, if you have multiple reuseable addresses, then you're doing
this calculation separately to check each one.
So the load on a popular centralized service would be quite high, which
you may consider a feature.
>
> Then an artificial prefix is proposed to constrain the query to a subset,
> however that leaks to everyone so in some ways its a worse privacy leak
> than bloom filtering. It can be used to rule out recipients and could be
> quite a powerful extra lever for statistical analysis.
Choosing how many bits to put in the prefix may be difficult, particularly
if transaction load changes dramatically over time. 0 or 1 bits may be
just fine for a single user running their own node, whereas a central
service might want 4 or 5 bits to keep their computation costs scalable.
But I think it's great people can choose how to trade privacy for
computation/bandwidth however they want, and services can compete to offer
monitoring for 0+ bit prefixes.
> (And also there is proposed a version of the prefix computed via
> brute-force to make it somewhat stealthy still).
I think in this case the hash grinding of the prefix would only being used
if thats how transactions are being indexed. I don't think it adds any
privacy, it's just added work we're forced to do in order for the prefix
to work as designed. Peter, please correct me if I'm wrong.
>
> Maybe in the payment address case the service should choose the
> derivation factor and communicate it and the client with the static
> address, as suggested by Alan Reiner because then it can also serve
> the function of allowing the service to tie the payment to the users
> account.
I think any change which requires more than a single published public
message (e.g. a posting in a forum, or in a README.me in Github) should be
seen as solving an entirely different problem.
If you have directed communication from payee->payer, I think there's
simply no reason to do it this way. (By "this way" I mean ECDH with
OP_RETURN P).
We could try to define a different reusable address type, for when you can
make a single directed message from payer->payee, and in that case there's
probably no need for ECDH or the prefix, like Alan's proposal.
But once you admit having that directed communication, then you are
swimming very close to the payment protocol.

2023-06-07 15:11:53

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

- 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

- 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

- 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

- 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

- 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

- 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

- 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:11:19

- reply

📅 Original date posted:2014-01-01
📝 Original message:So I looked into gitian, the first thing I noticed was the hashes that
people were signing, for example:
https://github.com/bitcoin/gitian.sigs/blob/master/0.8.6-win32/gavinandresen/bitcoin-build.assert
don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually
hosted by sourceforce. That was a bit alarming at first, but I talked to
BlueMatt and maaku on IRC and the difference is due to Gavin Authenticode
signing the executable for windows.
BlueMatt asked if someone could implement in gitian-downloader a way to
strip off the signature so that we could get back to the raw binary with a
hash that matches what everyone is producing from gitian. I found:
http://blog.didierstevens.com/programs/disitool/
which is a Python script which can strip the signature nicely, but the
hashes still don't match.
I couldn't find a gitian build of 0.8.6 so I built my own, and after
verifying the hash for v0.8.6 was '49547ff9...' as expected I looked at
the hex diff between that and the sig-stripped .exe from sourceforge, and
the only two differences are:
- At offset D8 the stripped file has '5D E2 B2' versus 'F9 F4 00' in the
gitian build
- The sig-stripped file has an extra byte '00' at the end
I started to look at the file spec for windows PE files and quickly
thought better of it. Maybe someone better informed can chime in on what
those three bytes at offset D8 specify.
I'm not sure if we want to patch the signature onto the gitian build, or
strip the signature off of the Gavin-signed build, but something of the
sort is necessary if you want get gitian-downloader to match the official
distro (for Windows at least).
In any case, I think wallet users want to know when an upgrade is
available, and ability to click an 'update' button get a binary they can
trust. It's not a problem unique to bitcoind, deterministic builds are
awesome, but I don't think fully solve it.
Thanks,
Jeremy
On Tue, 31 Dec 2013 13:33:54 -0800, Matt Corallo
<bitcoin-list at bluematt.me> wrote:
> We already have a wonderful system for secure updating -
> gitian-downloader. We just neither use it >not bother making actual
> gitian releases so anyone can use it to verify signatures of downloads.

2023-06-07 15:11:12

- reply

📅 Original date posted:2013-12-31
📝 Original message:Merge mining lets Bitcoin miners support or attack an alt-coin without any
additional cost for their proof-of-work.
Since bitcoin miners have to install software to build and claim blocks in
the alt-coin, the percentage of bitcoin hashing power reflected toward the
alt-coin will follow some adoption curve based on convincing bitcoin
miners to opt-in.
Depending on where you are on that adoption curve or 'participation rate',
you need [a lot] less than 51% of of total Bitcoin hashing power in order
to 51% attack the alt-coin.
But there's so much 'dry powder' out there (GPUs), I wonder if *not*
supporting merge-mining is any better? At least the attacker has to do
some unique PoW, so you hope it's costing them something. Relatively large
amounts of hashing can definitely be deployed on target with zero startup
cost, and perhaps very little runtime cost (botnets).
I think the absolute cost of the PoW is very likely *not* the determining
factor in preventing a 51% attack on all but one or two blockchains
currently in existence.
Do I understand correctly, the question here is mostly a matter a game
theory?
On Mon, 30 Dec 2013 17:14:05 -0800, Luke-Jr <luke at dashjr.org> wrote:
> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
>> that you are using merge-mining is a red-flag because without majority,
>> or
>> at least near-majority, hashing power an attacker can 51% attack your
>> altcoin at negligible cost by re-using existing hashing power.
>
> I strongly disagree on this isolated point. Using the same logic,
> Bitcoin is
> vulnerable to an attacker at negligible cost by re-using existing hashing
> power from mining Namecoin. Any non-scam altcoin is pretty safe using
> merged
> mining, since any would-be attacker is going to have it in their
> interests to
> invest in the altcoin instead of attacking it. It's only the scam ones
> that want to pump & dump with no improvements, that are really at risk
> here.
>
> The rational decision for a non-scam altcoin, is to take advantage of
> merged mining to get as much security as possible. There are also some
> possible
> tricks to get the full security of the bitcoin miners even when not all
> participate in your altcoin (but this area probably needs some studying
> to get right).
>
> Luke
>

2023-06-07 15:11:09

- reply

📅 Original date posted:2013-12-28
📝 Original message:I was reading there are some commands to access a peer's mempool state.
The purpose being to allow miners to recover faster after a reboot, I
think?
Reading peer mempool definitely allows recovering faster after a reboot.
So does persisting mempool in a database locally. But what can you learn
about a node from its mempool? Basically, are there distinguishing
features in the mempool, or could there be?
Are there transactions you can receive which go into your own mempool but
which you don't forward? How about 'nLockTime' transactions?
Is this new feature off by default? Which clients support it?
By the way, are there recommended places to go to compare features
implemented by different wallet software?
Sorry, so many questions...

2023-06-07 15:10:27

- 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:08:54

- reply

📅 Original date posted:2013-11-05
📝 Original message:Great paper Ittay, thanks for all your work on this.
> Today the threshold is 0% with good connectivity.
Fig. 2 captures this well, the threshold is only zero if 'y' is 1. In
Section 6 and 6.1 you argue y -> 1 but the sybil attack you describe,
isn't that more like how *all* sophisticated miners would want to ensure
their blocks are widely propagated? I think you can't assume only the
selfish miner is doing it.
Based on the current 'first seen' algorithm, as you say, competing
longest chains happen about every 60 blocks. The rest of the time, a
single block propagates through the vast majority of the network
'uncontested'. If there are multiple valid longest blocks being
simultaneously propagated, then propagation pattern of the competing
blocks will determine hash rate on each.
Selfish mining requires exploiting the race condition between learning
about a competing block, and publishing your own. Usually we talk about
minimizing publishing latency so that your block ends up uncontested 59/60
times, and in the 1/60 times, even then your block has the best chance of
winning.
Selfish mining forgoes the 59/60 chance of your block being uncontested,
and instead chooses to 'race the network' every time. You start 'one step
behind' the competing block (since of course you only learn about it after
it starts propagating), so you must rely on being able to outrace
propagation of the competing block through a private low-latency
side-network which can inject your block at multiple points throughout the
bitcoin p2p network to outrace the competitor.
I think it's a stretch to say 'y' is 0 with good connectivity. Even the
best connected mining pools today are concerned with this 'y' factor.
Here's a probably very dumb idea... to throw out one possible "solution"...
You want a way to fake-out the 'selfish miner' into disclosing their
blocks -- how can your force their hand to prevent them from accumulating
longer private chains?
What if you propagate (and relay) an encrypted block header which honest
miners will timestamp when they receive it, then 10 seconds later
propagate the decryption key to unblind it. But here's the catch - maybe
the decryption results in junk, maybe it results a new longer block. If
it's a real block then it gets priority based on when the ciphertext was
received instead of when the decryption key was received. Now 'selfish
miner' can't race the network anymore, because they are always in state 0'
and can't tell if they are up against a ghost, or a real competing block.
If they wait for the decryption key to check, it's too late, and they are
guaranteed to lose unless they can out-race the network, e.g. back at
t=50%. Of course there would need to be some way to anti-DDoS this which
allows for some amount of these fake-outs without letting them get out of
hand.
Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131105/15da1196/attachment.html>

2023-06-07 15:08:19

- reply

📅 Original date posted:2013-10-28
📝 Original message:Just an aside...
The 1BTC bountry John references below is a 1BTC P2SH output, where the
redeemScript he provided does hash to the expected value, and is itself a
2-of-3 multisig, with the following pubkeys, expressed as addresses:
1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
By comparison, the signatories for the 4BTC bountry are:
1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe
1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
On the one hand, the vanity address makes it easy to guess who one of the
signatories is, on the other hand, is it bad form to reuse keys for
signing?
John, you mentioned wanting to disambiguate bounties, perhaps through a
bounty-specific pubkey. I'm not sure I follow, how is that better than
just referencing the address of the output, or the TxID, in a 'Table of
Bounties'? Or you want to embed a hash of your signed message announcing
the bounty?
Out of curiosity, I suppose right now you just keep pubkeys for the
signatories you want to appoint and reuse the same pubkey to create these
multi-sigs, or you have to ask for a new one each time?
From the signatories perspective, I imagine we're a long way off from a
wallet receiving or importing the p2sh, tracking that these outputs as
"yours", and even more, which contract/bounty they correspond to, and
finally a usable way to accumulate signatures and ultimately spend the
output to the bounty winner.
And of course, thanks for posting the bounties!
On Sun, 27 Oct 2013 22:58:13 -0700, John Dillon
<john.dillon892 at googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>> One limitation of the payment protocol as speced is that there is no
>> way for a hidden service site to make use of its full authentication
>> capability because they are unable to get SSL certificates issued to
>> them.
>>
>> Thoughts?
>
> I think this is a great idea and wish to see it done. Here is 1BTC for
> you,
> redeemable when you finish this task. I trust either Jeff Garzik or
> Peter Todd
> to evaluate your finished product, or possibly someone elses:
>
> 37NDa6iFLEozbvw8vj38ri5D6SLw5xQujS
>
> 22e067d3317e6300a9edda84fd0e24d8bfb86cf91540c3fe7acff45e4dc64dd3:0
>
> redeemScript :
> "5241045f4bba15dbfe94a45f362aa13bbaef8bbf21ff84fec1be5b27fa628f4b3acca1a2e5711503c8b8fe2e228229b8b8814f9e33e0f7a314a089d7140269ffd51fe44104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae"
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBCAAGBQJSbfy2AAoJEEWCsU4mNhiPrMMH/jd+AgVYUKd1vmP1BfaZum1s
> X186JulwF659YHOx94dLs+NOjvjMfY6cPbHm+B0j20CnhWrZrXzcXvwTHnzOSuoc
> 1AAXg0KDbvyo+7PvTrsGQfHhT1FZSRzIUToofVmFlvEIO6/LiYMAYWCgIiX9nPvv
> RlvdtavTST+cY19yZamo5X0XU5cgI2tbtVWKEHJQ2VcglCgwFg5K0kZ0O1NMKbcZ
> KBagY3PVTiHnYP+LwSTW6EU9DNq0eLYG39mz4N6CqGkXZjGgh2YXZ6Sl2qRuO/5e
> Rd9HcJXKqPKqMuRpQ2PA5U3U6QSyrUz7/fmi5dsOxnR6pdR53kjUVSvbOqBFHXw=
> =I1/R
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:07:56

- reply

📅 Original date posted:2013-10-25
📝 Original message:Gavin, can you confirm the best place to read up on the discuss fee
estimation changes for v0.9?
I think fee estimation at its core is about providing a data point, or
even call it an API, which can be used however you see fit.
What parameters do I want to see in a 'fee estimation' API?
- 30 minutes vs 24 hours processing time
- Confidence Levels (50%/90%)
What properties does the result have?
- Is it globally consistent?
Talking about fees.. I read this:
https://gist.github.com/gavinandresen/2961409 and there is so much there I
really liked.
Any pointers for reading more about the leading theories on transaction
fees? For example, how well do they correlate with network security? Are
we getting what we are paying for? :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131025/91e5d419/attachment.html>

2023-06-07 15:07:23

- reply

📅 Original date posted:2013-10-10
📝 Original message:Can this be combined with the ideas on deterministic signing to show
matching signatures with OpenSSL's implementation?
Not sure if that's worth much, since we would just be testing needles in a
very large haystack, but better than nothing?
On Wed, 09 Oct 2013 20:50:30 -0700, Warren Togami Jr. <wtogami at gmail.com>
wrote:
> https://github.com/sipa/secp256k1
> sipa's secp256k1, optimized ecdsa, significantly faster than openssl
>
> Today someone in #bitcoin-dev asked for Bitcoin 0.8.5 with sipa's
> secp256k1. Litecoin has been shipping test builds with secp256k1 for
> several months >now so it was a simple matter to throw together a branch
> of Bitcoin 0.8.5 with secp256k1.
>
> https://github.com/wtogami/bitcoin/commits/btc-0.8.5-secp256k1
> This branch should theoretically work for Linux, win32 gitian and mac
> builds. These commits are rather ugly because it was thrown together
> just to make >it build with the old 0.8 makefiles without intent for
> production code merge. cfields is working on autotoolizing it as one of
> the prerequisites prior to >inclusion into bitcoin master where it will
> be an option disabled by default.
>
> http://193.28.235.60/~warren/bitcoin-0.8.5-secp256k1/
> Untested win32 gitian build. Build your own Linux or Mac builds if you
> want to test it. Not recommended for production wallet or mining uses.
>
> Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131009/42b7fbc0/attachment.html>

2023-06-07 15:03:36

- 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

- 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

- 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

- 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

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

2023-06-07 11:47:54

- reply

📅 Original date posted:2013-04-20
📝 Original message:I was discussing this with petertodd a couple days ago and we were thinking
the sequence I sent yesterday was usable today. I tried getting it to work
on test-net but the final transaction closing the channel was not being
accepted into the mempool beacause "ERROR: CTxMemPool::accept() : inputs
already spent"
But I was talking with sipa and gmaxwell on IRC about it, and sipa reminded
me; Test-Net implements IsStandard() to allow the non-final "refund" TX
into the mempool, but then doesn't allow it to be replaced, Main-Net
implements IsStandard() to *reject* non-final transactions in the first
place.
Therefore, this actually will work on Main-Net today, since the refund TX
won't even be allowed into the mempool until it's final, the AP is free to
sign and broadcast its final TX without any replacement. Of course, if the
AP waits too long, the user can get their Refund into the mempool and the
AP's [higher seq] version will be locked out.
This may be a case where Test-Net is in a "bad" state, by allowing
non-final TXs into the pool, but not allowing replacement, you get an
intermediate state which neither matches Main-Net behavior, nor implements
behavior which would ever be deployed to Main-Net as-is.
The current Main-Net behavior is actually very well suited for this
application. Any application that can be reduced to two instances of a Tx,
namely one non-final, and one final which is updated internally between the
parties, works very well under the current Main-Net rules.
If you set the nLockTime of the refund to be several days after the
scheduled closing time of the channel, it would be quite challenging to get
the Refund TX into the blockchain *despite* a final broadcast TX from the
AP. Since the vast majority of Main-Net won't even accept it, the attacker
would have to distribute the TX to any miner who could include the AP's
transaction in a block between now and when the refund becomes final, and
convince them all to not include the perfectly valid, fees paid, final,
nSeq=MAX, nLockTime=0 transaction from the AP. Demonstrating that level of
coordination would act substantially against the best interests of the
miners, to say the least.
This proposal still suffers from any malleability weakness, where the
user's refund could be invalidated by a miner changing the TxID of TX1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130420/28205bfd/attachment.html>

2023-06-07 11:47:50

- reply

📅 Original date posted:2013-04-19
📝 Original message:I’m not sure I followed John’s proposal fully, why would a user sign TX1
committing funds to the MULTISIG they may never get back? I also don’t see
the problem with getting a signed TX2 back from the AP before releasing
TX1... see the sequence below. But more importantly, we only need exactly
one replacement, so for starters we could anti-DoS by allowing only
nSequence of 0 or MAX.
If this was enabled on test-net, I would be including a link to
transactions that implement the following proposal. At the moment, the best
I can do is unit test and generate the rawtransaction output at each step –
you can find source code and test output here:
https://gist.github.com/jspilman/5424310
The initial funding transaction and time-locked refund is pretty annoying
to setup, if you want to support the general case of coins from arbitrarily
sized inputs. You will have:
- 1 or more inputs from the user, 0 or 1 change outputs
- 0 or more inputs from the AP, 0 or 1 change outputs
- 1 output to ‘2 PK1 PK2 2 CHECKMULTISIG’
This precludes using SIGHASH_SINGLE except for the special cases where
inputs are perfectly sized (i.e. they are created in a prior step).
0. User and AP negotiate how much to escrow, who pays the fees, and how
far in the future nLockTime will be set (how long user’s funds will be tied
if AP doesn’t close the channel)
1. User creates an unsigned TX1 with 1 or more inputs from user’s
‘listunspent’, change going back to user (if any), and a single output of
‘FundAmount’ with scriptPubKey of ‘2 PK1 OP_0 CHECKMULTISIG’, and sends to
the AP
2. AP adds to TX1; their inputs (if any), their change (if any), replaces
OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and
returns TX1 to User.
3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps it
to himself. User, having completed TX1, knows its TxID and can now create
TX2-Locked spending TX1 back to themselves. User sets nLockTime to the
agreed point, signs SIGHASH_ALL, and sends TX2-Locked to AP.
4. AP verifies TX2-Locked and adds their signature, and returns TX2-Locked
to User. User can now broadcast TX1 and TX2-Locked.
5. At each payment milestone, user creates TX2-Final; TX1 as input, final
nSequence, no lock time, with a single output going back to to the user,
and an amount equal to the remaining balance of the channel. User signs
with SIGHASH_SINGLE and sends to the AP.
6. AP can add an output to TX2-Final sending their portion of the coins
where ever they want, sign it SIGHASH_ALL, and broadcast it at any point,
closing the channel. AP must broadcast TX2-Final before nLockTime, but has
no guarantee the user hasn’t offered a bribe for miners by spending
TX2-Locked with a large fee, e.g. a pissed off user spends TX2-Locked
entirely to fees just to see if they can convince miners to wait for it.
The alternative to the TX2-Locked is a 3rd party in the MULTISIG who is
trusted to close the channel at the request of either party, based on the
latest TX2-Final which was sent by the user. In this case there is no
TX2-Locked, only a single boardcast version of TX2-Final, and you do not
need transaction replacement at all.
Thanks,
--Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130419/858beba2/attachment.html>