Thomas Voegtlin [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-10-25 to 2021-02-19
💬 Posted a total of 79 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47

Profile Code

nprofile1qqs85jayqpcw2sqjyy5xwxpvv6lw7kfxq0l8cu5ykuhl4t7wnk3qcpg0qeqku

Author Public Key

npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47

Show more details

Last Notes

2023-09-07 11:17:26

- reply

📅 Original date posted:2023-08-30
🗒️ Summary of this message: Proposal for symmetric peer backups in resumable channels. Issue: if Alice loses state, Bob may disconnect. Solution: Alice writes Bob's state commitment on-chain to prevent forgetting.
📝 Original message:
Regarding your proposal to make peer backups symmetric, with a first
message that commits to the current state, and then a second message
that reveals the state: I think it could work, but I see the following
issue:
If Alice reveals that she has lost her state, Bob might be tempted to
disconnect, because he expects that Alice will forget his already sent
state commitment. For example this would happen if the user is frustrated
and uninstalls/re-installs the app, or if she decides to try from another
device because the first device "failed" to restore her wallet). Thus,
Bob could try to send a different commitment the next time.
A possible way to prevent that: Alice could, if Bob does not reveal his
state, write Bob's state commitment on-chain, in an OP_RETURN. That way,
Bob cannot expect her to have forgotten his state commitment.
Thomas
On 17.08.23 20:43, SomberNight wrote:
>
> Symmetric resumable channels
> ----------------------------
>
> Alice and Bob could have a channel where they both provide state backups
> to each other. Regarding who goes first in channel_reestablish, we need
> an extra preliminary round where both Alice and Bob commit to what they
> will send in channel_reestablish:
>
> Round 1:
> 1. Alice sends hashA = hash(bobs_backup, nonceA)
> 2. Bob sends hashB = hash(alices_backup, nonceB)
>
> Alice persists hashB to disk upon receiving it, and enforces that even
> if there is a disconnection, Bob cannot arbitrarily send a different
> commitment next time. (if the channel gets reestablished fully and
> Alice sends a new backup to Bob, the stored hashB can be cleared)
>
> Round 2:
> 3. Alice sends channel_reestablish containing bobs_backup, and nonceA
> 4. Bob sends channel_reestablish containing alices_backup, and nonceB
>
> Alice checks that the commitment received from Bob in round1 matches
> what was received in round2.
>
> Regarding the opening post OP_CHECKSIGFROMSTACK on-chain enforcement,
> that can be made symmetric as well! The channel funding output script
> needs one taproot branch each for both Alice and Bob lying. The protocol
> needs to be tweaked a bit so as to allow a party to legitimately admit
> having lost state and commit to the hash of that in round1, and then
> reveal they lost state in round2 (e.g. send null data). In which case
> the other party would not be able to use the fraud proof taproot branch.
>
> Though note that user-error and manual copying/restoring of DBs could
> lead to catastrophic failure with the on-chain enforcement:
> if you restore an old db and launch your client, the client won't know
> it is running an old state and happily participate in the two round
> dance, giving a fraud proof to the counterparty in the process.
>
> Regards,
> ghost43

2023-08-21 09:48:48

- reply

📅 Original date posted:2023-08-17
🗒️ Summary of this message: Bastien is not interested in fraud proofs, but Thomas argues they are not dangerous and suggests using existing messages for backup data.
📝 Original message:
Hello Bastien
> I don't think those fraud proofs are necessary at all.
That's a pity. I would have expected you to be interested, given that
Phoenix could benefit from that feature.
Anyway, since my proposal requires new opcodes, I think of it more as
a theoretical discussion, rather than a concrete proposal.
> They're also
> dangerous, because they impose a hard penalty on LSPs for something
> that should be best effort (and could get desynchronized by connection
> issues, especially with flaky mobile connections).
>
How are the fraud proofs I described more dangerous than revoked states?
There is no "toxic data" in here.
The server must not sign (ctn1, t1), (ctn2, t2) with ctn1>ctn2 and t1<t2.
That is the only constraint, and it does not depend on flaky connections.
All the server needs to do is remember the value of the highest timestamp
signed so far. And, if they need to subtract leap seconds to their clock,
wait a little bit before resuming the channel. That does not sound too hard...
> I'm surprised that you don't mention the BOLT PR we created for those
> backups in [1], I believe that is sufficient. It should probably be
> moved to a blip instead of a BOLT once we've implemented this version
> (the approach we use in Phoenix currently is slightly different), but
> apart from that it contains all the mechanisms necessary to achieve
> this today.
>
Sorry, I had seen that PR a few years ago, but in the meantime I had
forgotten about it. I just had a new look at it now.
Perhaps that PR could benefit from my idea of sending backup data as new
fields of existing messages? I see that update_channel_backup needs to be
sent *before* the corresponding change of state. I think using the existing
messages would be more elegant, because it makes things atomic.
Note that in practice, the client would only need to send his signature
of the backup, and not the backup itself, which should be reconstructed
by the server on each new state (see section 'saving bandwidth').
cheers
Thomas

2023-08-16 00:49:04

- reply

📅 Original date posted:2023-08-14
🗒️ Summary of this message: Proposal for resumable Lightning channels using OP_CHECKSIGFROMSTACK. Allows for backup of channel state and fraud proof. Suited for private channels with Lightning service providers.
📝 Original message:
Hello list,
Here is an idea to make lightning channels resumable from wallet seed.
I have not implemented it yet, and there might be issues I am not
seeing. Thus, I would be grateful for feedback.
Thanks to SomberNight and Peter Todd for reviewing earlier versions of
this proposal.
Thomas
-----------------------------------------------
Resumable channels using OP_CHECKSIGFROMSTACK
=============================================
In order to resume the activity of a Lightning channel, one needs a
backup that contains all the information about the current channel
state. The need to perform channel backups has plagued user
experience, with many implementations reverting to static backups,
which can be used to recover funds, but not to resume channel
operations.
Asking your channel counterparty to store your channel state has the
advantage to make backup operations atomic. However, there is no
guarantee that this is safe. Indeed, if the other party suspects that
you have lost your state (for example, because you have been offline
for a long time, or if they can see that you requested blockchain
information following a certain pattern), they can try to send you a
revoked state, and there is no way to punish them for doing that.
Here is a proposal for a new type of channel funding transaction,
where the redeem script has an additional spending path, that accepts
a fraud proof: a proof that the channel counterparty has lied about
the current state. This proposal requires two opcodes that are
currently not available in Bitcoin: OP_CAT and OP_CHECKSIGFROMSTACK.
Roles are asymmetric in this channel: Alice is a client, and Bob is a
server, who stores Alice's state. Thus, this proposal is mostly suited
for private channels with Lightning service providers. During channel
reestablishment, Bob will send her latest state to Alice, using an
extra field in the channel_reestablish message. Since Alice cannot
punish Bob if she has lost her state, she must not let Bob learn
whether she still has her state. Thus, Alice will never send
channel_reestablish first.
This proposal assumes that Alice and Bob each have a clock, and that
these clocks do not drift too much relative to each other. The channel
may become unusable if clocks differ too much, as discussed below.
Simplified description
----------------------
The *state* of the channel refers to everything Alice needs in order
to resume channel operations. With every new commitment, Alice sends
her current state, with her signature of that state:
- if Alice sends commitment_signed, the state and signature are
included in that message.
- if Alice receives commitment_signed, the state and signature will
be included in the next revoke_and_ack sent by Alice.
With every new commitment, Bob sends a signed tuple (ctn, timestamp),
where ctn is the current commitment number (for the moment, forget
about the distinction between local and remote ctns), and timestamp is
the current time for Bob.
- if Bob sends commitment_signed, the signed tuple is included in
that message.
- if Bob receives commitment_signed, the signed tuple will be
included in the next revoke_and_ack sent by Bob.
The private key used by Bob to sign the tuples is constant over the
lifetime of the channel, and it must not be reused in other
channels. The corresponding public key will be used in the fraud proof
spending path of the redeem script.
Alice verifies Bob's signature. She also checks that the received
timestamps are reasonable (see below) and strictly monotonic.
With every channel_reestablish message, Bob will send two extra fields:
- (ctn, timestamp, bob_signature)
- (alice_state, alice_signature).
Alice verifies that the state she received was signed by her, and that
the (ctn, timestamp) tuple was signed by Bob. She also checks that the
timestamp is reasonable.
Fraud Proofs
------------
Let us assume that Bob tries to send a revoked state to Alice in
channel_reestablish. The channel_reestablish received by Alice
contains a signed tuple (ctn1, t1), with t1 current timestamp.
However, another signed tuple (ctn2, t2) has been received in the
past, with ctn1 < ctn2 and t1 > t2.
If Alice has not lost her state, she will now hold two signed tuples
(ctn1, t1) and (ctn2, t2), that satisfy ctn1 < ctn2 and t1 > t2.
This constitutes a fraud proof. With OP_CAT and OP_CHECKSIGFROMSTACK,
we can build a script that verifies the fraud proof, and allows Alice
to unilaterally spend the channel funding output.
Here is an example of such a script:
witness:
[
alice_signature(transaction)
bob_signature((ctn1,timestamp1))
ctn1
timestamp1
bob_signature((ctn2,timestamp2))
ctn2
timestamp2
]
witness_script:
OP_PICK 1
OP_PICK 4
OP_LESSTHAN # verify ctn1 < ctn2
OP_VERIFY
OP_PICK 0
OP_PICK 3
OP_GREATERTHANOREQUAL # verify timestamp1 >= timestamp2
OP_VERIFY
# check signatures
OP_CAT
OP_PUSHDATA bob_pubkey # we may use Bob's funding_pubkey
OP_CHECKSIGFROMSTACK
OP_VERIFY
OP_CAT
OP_PUSHDATA bob_pubkey
OP_CHECKSIGFROMSTACK
OP_VERIFY
OP_PUSHDATA alice_pubkey # we may use Alice's funding_pubkey
OP_CHECKSIGVERIFY
In order to keep things simple, a few details have been omitted in the
description:
- Bob actually needs to send both the local and the remote ctns in
his signed tuples. A pair of tuples is a fraud proof if the order
is violated for either local or remote ctns. Thus, the actual
script will be more complex than what has been drafted above.
- Integers pushed on the Bitcoin stack are maximum 4 bytes (31 bits +
1 bit for the sign). Since commitment numbers are 48 bits long,
they will need to be split into two integers. Timestamps might
require a similar decomposition. This adds further complexity to
the redeem script.
- Note that Bob must strictly increase his timestamp on each
ctn. This puts a lower bound on the precision used for timestamps.
Reasonable Timestamps
---------------------
Since Alice and Bob do not have the same clock, Bob may legitimately
send a timestamp that is in Alice's past or future. Every time Alice
receives a timestamp from Bob, she compares it to her current time.
- If Alice receives a timestamp that is in her future, instead of
closing the channel, she may wait it out before she accepts to
resume operations.
- If Alice receives a timestamp that is too far in her past, she
should disconnect. Indeed, Bob may be sending an old state and
replaying old timestamps, which is not punishable. In that case,
Alice should not automatically force close the channel, because she
can only do that if she has not lost her state; if force-closing
was automatic, not force-closing would reveal to Bob that she
has lost her state.
A delay needs to be tolerated by Alice, because Bob does not have the
same clock; that delay should be chosen so that it is always smaller
than the interval between two sessions.
Saving Bandwidth
----------------
Alice's channel state does not need to be sent with every commitment,
if it is made of information that is known by both parties. In that
case, it is sufficient for Alice to send her signature of the current
state. Both Alice and Bob must be able to serialize the state, so that
Alice can verify her own signature against a serialization of the
state created by Bob. The state only needs to be sent by Bob once, in
channel_reestablish.
For this to work, the channel state cannot include information that is
private to Alice. If the private keys used by Alice in the channel are
derived deterministically from her wallet seed, they do not need to be
part of the state. Alternatively, private keys may be included in an
encrypted blob that is included in the state. Since that encrypted
blob is constant, it only needs to be sent once by Alice, during the
channel opening negotiation. Bob will save it and add it to the state
sent in channel_reestablish.
In addition, the state must not include any payment_hash preimage
known by Alice; thus, Alice will have to fail incoming payments for
those preimages, if she has lost her state.
The channel state should include the compact storage of per-commitment
secrets sent by Bob.
Concluding remarks
------------------
- Obviously, this proposal assumes that Alice remembers with whom she
has an open channel.
- Alice may restore her wallet from seed on a new device, while the
initial wallet is still active. In that case, Alice must stop using
the channels on her old device. Thus, Alice should disconnect if
she has not lost her state and receives a state with a ctn that is
in her future. This ensures that only one device uses the channels.
- Without waiting for OP_CHECKSIGFROMSTACK to be available in
Bitcoin, it would be possible for Bob to lockup funds on another
blockchain such as Liquid. It is also possible to create fraud
proofs that are not used in a redeem script, but that are tied to
Bob's public identity and reputation. In that case, Bob should sign
with his node pubkey, and fraud proofs will need to include a short
channel id.

2023-06-20 23:25:28

- reply

📅 Original date posted:2023-06-20
🗒️ Summary of this message: Thomas proposes leveling the competition between Lightning service providers by allowing reverse submarine swap payments from any wallet. He suggests pre-payment of mining fees can be combined with 0-conf. Updating Bolt 12 makes more sense than updating Bolt 11.
📝 Original message:
Hello Bastien,
Thank you for the clarification; indeed I might not have been clear
about the fact that senders need to understand the new fields.
What you are suggesting (solution 2, blacklisting non-cooperative
clients and playing with the mempool) is prone to griefing attacks and
it requires manpower and infrastructure not necessarily affordable by
small companies. I would also be surprised if that is the approach
used by ACINQ.
I believe pre-payment of the mining fee can be combined with 0-conf;
I am not sure why you picture them as opposed? Even with BOLT-12, I
don't see 0-conf going away.
We have not implemented BOLT-12 yet in Electrum. Would you care to
describe whether bundled payments already would work with the current
specification, or whether they would require changes to BOLT-12? We
are going to implement BOLT-12 support in Electrum in the coming
months, and I would be happy to help here.
I believe that it will take years *after it is merged*, until BOLT-12
actually becomes the dominant payment method on Lightning. OTOH, if
this feature was adopted in BOLT-11, I think it could be deployed much
faster.
The goal of my proposal is to level the field of competition between
Lightning service providers, by allowing reverse submarine swap
payments to come from any wallet (of course, a dedicated client will
still be needed to verify the redeem script and the invoice, and to
sweep the funds, as discussed above), and by allowing JIT channels to
be provided by companies who do not distribute a dedicated wallet that
trusts them.
In this context, making this proposal happen earlier rather than later
could have a significant impact on the shape of the ecosystem. It
remains to be seen how this is understood by everybody.
cheers,
Thomas
On 15.06.23 11:01, Bastien TEINTURIER wrote:
> Hi Thomas,
>
> First of all, I'd like to highlight something that may not be obvious
> from your email, and is actually pretty important: your proposal
> requires *senders* to be aware that the payment will lead to a channel
> creation (or a splice) on the *receiver* end. In particular, it requires
> all existing software used by senders to be updated. For this reason, I
> think extending Bolt 12 (which requires new sender code anyway) makes
> more sense than updating Bolt 11.
>
> I see only three strategies to provide JIT liquidity (by opening a new
> channel or making a splice, I'll only use the open channel case below
> for simplicity):
>
> 1. Ask receiver for the preimage and a fee, then open a channel and
> push the HTLC amount minus the fee
> 2. Open a channel, then forward the HTLC amount minus a fee
> 3. Pre-pay fee, then open a channel and forward the whole HTLC amount
> on that channel
>
> What is currently deployed on the network is 1) and 2), while you're
> proposing 3). Both 1) and 2) have the advantages that the sender doesn't
> need to be aware that JIT liquidity is happening, and doesn't need to do
> anything special for that payment, which is the main reason those
> strategies were chosen.
>
> If all you're concerned about is trust and regulation, solution 2) works
> fine as long as the mempool isn't empty: if the user doesn't release the
> preimage after you've opened the channel, you should just blacklist that
> channel, reject payments made to it, and double-spend it whenever you
> have another on-chain transaction to make (and use 1 sat/byte for JIT
> liquidity transactions). Even if the mempool is empty, if your LSP has
> transactions to make at every block, it's likely that it will succeed
> at double-spending the faulty channel, and thus won't lose anything.
>
> But I agree that this only works when coupled with 0-conf. If we're not
> using 0-conf anymore, pre-paying fees would make more sense. But we will
> likely keep on using 0-conf at least until Bolt 12 is deployed, so it
> seems more reasonable to include this new feature in Bolt 12 rather than
> Bolt 11, since all implementations are actively working on this?
>
> Cheers,
> Bastien
>
> Le jeu. 15 juin 2023 à 10:52, Thomas Voegtlin <thomasv at electrum.org> a
> écrit :
>
>> Hello Matt,
>>
>> I think it is not too late to add a new feature to BOLT-11. In any
>> case, the belief that BOLT-11 is ossified should not be a reason to
>> make interactive something that fundamentally does not require more
>> interactivity than what BOLT-11 already offers. Technical decisions
>> should be dictated by technical needs, and I am a minimalist when it
>> comes to adding new messages to protocols.
>>
>> I believe that two major implementations have an incentive to support
>> this proposal (although I cannot speak for them):
>> - Lightning Labs could potentially offer their Loop service to
>> non-LND users.
>> - ACINQ would be able to open channels to Phoenix users without
>> requesting the preimage first. This would put them on the safe side
>> of the upcoming MICA regulation; I cannot emphasize enough how
>> important that is.
>>
>> In addition, you could certainly decide to support that feature in
>> LDK, and I can speak for Electrum :-)
>>
>> It is the first time I suggest a change to the Lightning protocol, and
>> what I am proposing is really a tiny change. All we need is a new
>> invoice feature, that describes the prepayment of a fee using a
>> different preimage. This feature does not need to be set on all
>> invoices, and it could be made optional during a transition period.
>>
>> Here is how that feature could possibly made optional:
>> - a new feature bit is defined, BUNDLE_PREPAYMENT
>> - two extra fields are defined: prepayment_amount, prepayment_hash
>> - if the sender does not support BUNDLE_PREPAYMENT and the feature is
>> optional, it ignores the new fields
>> - if the sender support BUNDLE_PREPAYMENT:
>> - sender sends (amount - prepayment_amount) with payment_hash
>> - sender sends prepayment_amount with prepayment_hash
>>
>> The decision to make this feature required or optional remains with
>> the service provider. I can see how submarine swap providers who are
>> already exposed to the mining fee griefing attack could decide to make
>> it optional for a transition period.
>>
>> cheers,
>> Thomas
>>
>>
>> Regarding your question (a) about the distinction between splice-out
>> and submarine swaps: Submarine swaps make it possible to add receiving
>> capacity to a channel.
>>
>>
>>
>>
>> On 14.06.23 19:28, Matt Corallo wrote:
>>> I think the ship has probably sailed on getting any kind of new
>> interoperable change in to BOLT-11.
>>>
>>> We already can't get amount-less BOLT-11 invoices broadly supported,
>> rolling out yet another new incompatible version of BOLT-11 and expecting
>> the entire ecosystem to support it doesn't seem all that likely.
>>>
>>> If we're working towards specifying some "standard" way of doing swaps,
>> (a) I'd be curious to understand why the need isn't obviated by splice-out,
>> and (b) why it shouldn't be built on OMs so you can do it more privately.
>>>
>>> Matt
>>>
>>> On 6/13/23 1:10 AM, Thomas Voegtlin wrote:
>>>> Good morning list,
>>>>
>>>> I would like to propose an extension to BOLT-11, where an invoice can
>> contain two bundled payments, with distinct preimages and amounts.
>>>>
>>>> The use case is for services that require the prepayment of a mining
>> fee in order for a non-custodian exchange to take place:
>>>> - Submarine swaps
>>>> - JIT channels
>>>>
>>>> In both cases, the service provider receives a HTLC for which they do
>> not have the preimage, have to send funds on-chain (to the channel or
>> submarine swap funding address), and wait for the client to reveal the
>> preimage when they claim the payment. Because there is no guarantee that
>> the client will actually claim the payment, the service providers need to
>> ask prepayment of mining fees.
>>>>
>>>> In the case of submarine swaps, services that use dedicated client
>> software, such as Loop by Lightning Labs, can ask for a prepayment, because
>> their software can handle it (this is called "no show penalty" on the Loop
>> website). However, competitors who do require a dedicated wallet, not such
>> as the Boltz exchange, cannot do that. Their website shows an invoice to
>> the user, whose wallet that is agnostic about the swap, and it would be
>> unpractical for them to show two invoices to be paid simultaneously. This
>> creates a situation where Boltz is vulnerable to DoS attacks, where the
>> attacker forces them to pay on-chain fees.
>>>>
>>>> In the case of JIT channels, providers who want to protect themselves
>> against this mining fee attack need to ask the preimage of the main payment
>> before they open the channel. I believe this is what Phoenix does (although
>> their pay-to-open service is not open-source, so I cannot really check).
>> The issue is that a service that asks for the preimage first becomes
>> custodian. From a legal perspective, it does not matter whether they open
>> the channel immediately after receiving the preimage, the ordering of
>> events makes their service custodian. In Europe, such a service will fall
>> within the European MICA regulation. Competitors who refuse to offer
>> custodian services, such as Electrum, are excluded from that game.
>>>>
>>>> In order to solve that, it would be beneficial to bundle the prepayment
>> and the main payment in the same BOLT-11 invoice.
>>>>
>>>> The semantics of bundled payments is as follows:
>>>> - 1. the BOLT-11 invoice contains two preimages and two amounts:
>> prepayment and main payment.
>>>> - 2. the receiver should wait until all the HTLCs of both payments
>> have arrived, before they fulfill the HTLCs of the pre-payment. If the main
>> payment does not arrive, they should fail the pre-payment with a MPP
>> timeout.
>>>> - 3. once the HTLCs of both payments have arrived, the receiver
>> fulfills the HTLCs of the prepayment, and they broadcast their on-chain
>> transaction. Note that the main payment can still fail if the sender never
>> reveal the preimage of the main payment.
>>>>
>>>> Of course, nothing in my proposal prevents the service provider from
>> stealing the pre-payment, but that is already the case today.
>>>>
>>>> I believe this proposal would level the field in terms of competition
>> between lightning service providers. Currently, you need to use a dedicated
>> client in order to use Loop, and competitors who do not have an established
>> user base running a dedicated client are exposed to the mining fee attack.
>> I also believe that ACINQ would benefit from this, because it would make it
>> possible for them to make their pay-to-open service fully non-custodian. My
>> understanding is that in its current form, the 'pay-to-open' service used
>> by Phoenix will fall into the scope of the European MICA regulation, which
>> they should consider as a serious issue.
>>>>
>>>> Finally, I believe that such a change should be implemented in BOLT-11,
>> and not using BOLT-12 or onion messages. Indeed, my proposal does not
>> require the exchange of new messages. Some of the initial feedback I
>> received was that this is a use case for BOLT-12 or OM, but I think that
>> this is making things unnecessarily complicated. We should not add new
>> messages when things can be done in a non-interactive way.
>>>>
>>>> Cheers,
>>>> ThomasV
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>> --
>> Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
>> Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
>> Geschäftsführer: Thomas Voegtlin
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
--
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-20 11:15:34

- reply

📅 Original date posted:2023-06-20
🗒️ Summary of this message: Thomas suggests adding a feature bit to the invoice to make prepayment optional or required, and subtracting the prepayment amount from the main payment amount.
📝 Original message:
Hello Dave,
That is an interesting idea; it would indeed save space for the prepayment hash.
I think the invoice would still need a feature bit, so that the receiver can
decide to make prepayment optional or required.
Note that for the feature to be optional, we need to subtract the prepayment
amount from the main payment amount. Thus, in your example, Alice would expect
to receive either:
(1 BTC, invoice payment_hash)
or:
(1 BTC - minus 10k sats, invoice payment_hash) + (10k sats, prepayment_hash via keysend)
cheers
Thomas
On 19.06.23 22:29, David A. Harding wrote:
> On 2023-06-12 22:10, Thomas Voegtlin wrote:
>> The semantics of bundled payments is as follows:
>> - 1. the BOLT-11 invoice contains two preimages and two amounts:
>> prepayment and main payment.
>> - 2. the receiver should wait until all the HTLCs of both payments
>> have arrived, before they fulfill the HTLCs of the pre-payment. If the
>> main payment does not arrive, they should fail the pre-payment with a
>> MPP timeout.
>> - 3. once the HTLCs of both payments have arrived, the receiver
>> fulfills the HTLCs of the prepayment, and they broadcast their
>> on-chain transaction. Note that the main payment can still fail if the
>> sender never reveal the preimage of the main payment.
>
> Hi Thomas,
>
> Do you actually require a BOLT11 invoice to contain a payment hash for
> the prepayment, or would it be acceptable for the prepayment to use a
> keysend payment with the onion message payload for the receiver
> indicating what payment hash to associate with the prepayment (e.g.,
> Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of
> 10k sats, so the 10k sats is sent via keysend with metadata indicating
> the receiver shouldn't claim it until they receive the 1 BTC HTLC to
> 0123...cdef).
>
> If so, I think then you'd only need BOLT11 invoices to be extended with
> an extra_fee_via_keysend field. That would be significantly smaller and
> it also allows encoding the extra_fee_via_keysend field in an existing
> BOLT11 field like (d) description or the relatively new (m) metadata
> field, which may allow immediate implementation until an updated version
> of BOLT11 (or an alternative using offers) becomes widely deployed.
>
> Thanks,
>
> -Dave
--
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-19 17:42:39

- reply

📅 Original date posted:2023-06-15
🗒️ Summary of this message: Thomas Voegtlin proposes a new feature for BOLT-11 to allow for prepayment of fees using a different preimage, which could benefit Lightning Labs and ACINQ. The feature would be optional and could be made available during a transition period. Matt Corallo questions the feasibility of adding a new feature to BOLT-11 and suggests exploring splice-out and building on OMs for more privacy.
📝 Original message:
Hello Matt,
I think it is not too late to add a new feature to BOLT-11. In any
case, the belief that BOLT-11 is ossified should not be a reason to
make interactive something that fundamentally does not require more
interactivity than what BOLT-11 already offers. Technical decisions
should be dictated by technical needs, and I am a minimalist when it
comes to adding new messages to protocols.
I believe that two major implementations have an incentive to support
this proposal (although I cannot speak for them):
- Lightning Labs could potentially offer their Loop service to
non-LND users.
- ACINQ would be able to open channels to Phoenix users without
requesting the preimage first. This would put them on the safe side
of the upcoming MICA regulation; I cannot emphasize enough how
important that is.
In addition, you could certainly decide to support that feature in
LDK, and I can speak for Electrum :-)
It is the first time I suggest a change to the Lightning protocol, and
what I am proposing is really a tiny change. All we need is a new
invoice feature, that describes the prepayment of a fee using a
different preimage. This feature does not need to be set on all
invoices, and it could be made optional during a transition period.
Here is how that feature could possibly made optional:
- a new feature bit is defined, BUNDLE_PREPAYMENT
- two extra fields are defined: prepayment_amount, prepayment_hash
- if the sender does not support BUNDLE_PREPAYMENT and the feature is
optional, it ignores the new fields
- if the sender support BUNDLE_PREPAYMENT:
- sender sends (amount - prepayment_amount) with payment_hash
- sender sends prepayment_amount with prepayment_hash
The decision to make this feature required or optional remains with
the service provider. I can see how submarine swap providers who are
already exposed to the mining fee griefing attack could decide to make
it optional for a transition period.
cheers,
Thomas
Regarding your question (a) about the distinction between splice-out
and submarine swaps: Submarine swaps make it possible to add receiving
capacity to a channel.
On 14.06.23 19:28, Matt Corallo wrote:
> I think the ship has probably sailed on getting any kind of new interoperable change in to BOLT-11.
>
> We already can't get amount-less BOLT-11 invoices broadly supported, rolling out yet another new incompatible version of BOLT-11 and expecting the entire ecosystem to support it doesn't seem all that likely.
>
> If we're working towards specifying some "standard" way of doing swaps, (a) I'd be curious to understand why the need isn't obviated by splice-out, and (b) why it shouldn't be built on OMs so you can do it more privately.
>
> Matt
>
> On 6/13/23 1:10 AM, Thomas Voegtlin wrote:
>> Good morning list,
>>
>> I would like to propose an extension to BOLT-11, where an invoice can contain two bundled payments, with distinct preimages and amounts.
>>
>> The use case is for services that require the prepayment of a mining fee in order for a non-custodian exchange to take place:
>>   - Submarine swaps
>>   - JIT channels
>>
>> In both cases, the service provider receives a HTLC for which they do not have the preimage, have to send funds on-chain (to the channel or submarine swap funding address), and wait for the client to reveal the preimage when they claim the payment. Because there is no guarantee that the client will actually claim the payment, the service providers need to ask prepayment of mining fees.
>>
>> In the case of submarine swaps, services that use dedicated client software, such as Loop by Lightning Labs, can ask for a prepayment, because their software can handle it (this is called "no show penalty" on the Loop website). However, competitors who do require a dedicated wallet, not such as the Boltz exchange, cannot do that. Their website shows an invoice to the user, whose wallet that is agnostic about the swap, and it would be unpractical for them to show two invoices to be paid simultaneously. This creates a situation where Boltz is vulnerable to DoS attacks, where the attacker forces them to pay on-chain fees.
>>
>> In the case of JIT channels, providers who want to protect themselves against this mining fee attack need to ask the preimage of the main payment before they open the channel. I believe this is what Phoenix does (although their pay-to-open service is not open-source, so I cannot really check). The issue is that a service that asks for the preimage first becomes custodian. From a legal perspective, it does not matter whether they open the channel immediately after receiving the preimage, the ordering of events makes their service custodian. In Europe, such a service will fall within the European MICA regulation. Competitors who refuse to offer custodian services, such as Electrum, are excluded from that game.
>>
>> In order to solve that, it would be beneficial to bundle the prepayment and the main payment in the same BOLT-11 invoice.
>>
>> The semantics of bundled payments is as follows:
>>   - 1. the BOLT-11 invoice contains two preimages and two amounts: prepayment and main payment.
>>   - 2. the receiver should wait until all the HTLCs of both payments have arrived, before they fulfill the HTLCs of the pre-payment. If the main payment does not arrive, they should fail the pre-payment with a MPP timeout.
>>   - 3. once the HTLCs of both payments have arrived, the receiver fulfills the HTLCs of the prepayment, and they broadcast their on-chain transaction. Note that the main payment can still fail if the sender never reveal the preimage of the main payment.
>>
>> Of course, nothing in my proposal prevents the service provider from stealing the pre-payment, but that is already the case today.
>>
>> I believe this proposal would level the field in terms of competition between lightning service providers. Currently, you need to use a dedicated client in order to use Loop, and competitors who do not have an established user base running a dedicated client are exposed to the mining fee attack. I also believe that ACINQ would benefit from this, because it would make it possible for them to make their pay-to-open service fully non-custodian. My understanding is that in its current form, the 'pay-to-open' service used by Phoenix will fall into the scope of the European MICA regulation, which they should consider as a serious issue.
>>
>> Finally, I believe that such a change should be implemented in BOLT-11, and not using BOLT-12 or onion messages. Indeed, my proposal does not require the exchange of new messages. Some of the initial feedback I received was that this is a use case for BOLT-12 or OM, but I think that this is making things unnecessarily complicated. We should not add new messages when things can be done in a non-interactive way.
>>
>> Cheers,
>> ThomasV
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-14 14:16:41

- reply

📅 Original date posted:2023-06-13
🗒️ Summary of this message: Proposal to extend BOLT-11 to include two bundled payments with distinct preimages and amounts to address prepayment of mining fees for non-custodian exchanges.
📝 Original message:
Good morning list,
I would like to propose an extension to BOLT-11, where an invoice can contain two bundled payments, with distinct preimages and amounts.
The use case is for services that require the prepayment of a mining fee in order for a non-custodian exchange to take place:
- Submarine swaps
- JIT channels
In both cases, the service provider receives a HTLC for which they do not have the preimage, have to send funds on-chain (to the channel or submarine swap funding address), and wait for the client to reveal the preimage when they claim the payment. Because there is no guarantee that the client will actually claim the payment, the service providers need to ask prepayment of mining fees.
In the case of submarine swaps, services that use dedicated client software, such as Loop by Lightning Labs, can ask for a prepayment, because their software can handle it (this is called "no show penalty" on the Loop website). However, competitors who do require a dedicated wallet, not such as the Boltz exchange, cannot do that. Their website shows an invoice to the user, whose wallet that is agnostic about the swap, and it would be unpractical for them to show two invoices to be paid simultaneously. This creates a situation where Boltz is vulnerable to DoS attacks, where the attacker forces them to pay on-chain fees.
In the case of JIT channels, providers who want to protect themselves against this mining fee attack need to ask the preimage of the main payment before they open the channel. I believe this is what Phoenix does (although their pay-to-open service is not open-source, so I cannot really check). The issue is that a service that asks for the preimage first becomes custodian. From a legal perspective, it does not matter whether they open the channel immediately after receiving the preimage, the ordering of events makes their service custodian. In Europe, such a service will fall within the European MICA regulation. Competitors who refuse to offer custodian services, such as Electrum, are excluded from that game.
In order to solve that, it would be beneficial to bundle the prepayment and the main payment in the same BOLT-11 invoice.
The semantics of bundled payments is as follows:
- 1. the BOLT-11 invoice contains two preimages and two amounts: prepayment and main payment.
- 2. the receiver should wait until all the HTLCs of both payments have arrived, before they fulfill the HTLCs of the pre-payment. If the main payment does not arrive, they should fail the pre-payment with a MPP timeout.
- 3. once the HTLCs of both payments have arrived, the receiver fulfills the HTLCs of the prepayment, and they broadcast their on-chain transaction. Note that the main payment can still fail if the sender never reveal the preimage of the main payment.
Of course, nothing in my proposal prevents the service provider from stealing the pre-payment, but that is already the case today.
I believe this proposal would level the field in terms of competition between lightning service providers. Currently, you need to use a dedicated client in order to use Loop, and competitors who do not have an established user base running a dedicated client are exposed to the mining fee attack. I also believe that ACINQ would benefit from this, because it would make it possible for them to make their pay-to-open service fully non-custodian. My understanding is that in its current form, the 'pay-to-open' service used by Phoenix will fall into the scope of the European MICA regulation, which they should consider as a serious issue.
Finally, I believe that such a change should be implemented in BOLT-11, and not using BOLT-12 or onion messages. Indeed, my proposal does not require the exchange of new messages. Some of the initial feedback I received was that this is a use case for BOLT-12 or OM, but I think that this is making things unnecessarily complicated. We should not add new messages when things can be done in a non-interactive way.
Cheers,
ThomasV

2023-06-14 14:16:41

- reply

📅 Original date posted:2023-06-14
🗒️ Summary of this message: A submarine swap client can be distributed separately from the user's lightning wallet, enabling competition and increasing potential user base. However, dedicated logic is required for full verification and trust minimization. An extension to BOLT-11 is proposed for invoices with two bundled payments.
📝 Original message:
Of course, a submarine swap client needs to do the proper checks and sweep
the funds. In the case of Boltz, their website serves javascript that does
that, and they are also distributing a Progressive Web App [1]. I have no
idea whether their app is doing all this correctly, my point is rather that
it is possible to distribute a submarine swap client that is separate from
the lightning wallet of the user, and they are doing just that.
This separation between wallet and submarine swap providers is what would
enable competition. Lightning Loop could benefit from that, by distributing
an app that does not require a local LND instance. This would vastly increase
your potential user base. The only ingredient that is missing is the bundling
of fee prepayment and main payment in the same invoice.
Note that there is an ongoing standardization effort for LSP protocols [2]. My
understanding is that Boltz is currently working to add submarine swaps to it.
cheers,
Thomas
[1] https://twitter.com/Boltzhq/status/1668590610998079488
[2] https://github.com/synonymdev/lsp-spec/tree/main
On 14.06.23 04:56, Olaoluwa Osuntokun wrote:
>> Their website shows an invoice to the user, whose wallet that is agnostic
>> about the swap, and it would be unpractical for them to show two invoices
>> to be paid simultaneously
>
> In order to be properly non-custodial, a submarine swap client needs to be
> able to unilaterally sweep or timeout an on chain HTLC and also validate all
> the swap parameters.
>
> Assuming I understand this web based flow correctly, it still requires
> "dedicated logic" on the client side to sweep (reveal the preimage) or
> timeout the on chain HTLC. If one wishes to avoid the awareness of the
> subswap itself, then a user would need to manually go to the website in
> order to obtain a signed sweep transaction (for a Loop Out like sub-swap, so
> off-chain to on-chain). However, that would still require the wallet to
> sign
> the HTLC sweep path, once again requiring dedicated logic. A website could
> have an option to give a user a signed sweep or refund transaction, but that
> can't be created until user goes on chain as something like no_input doesn't
> exist today on mainnet. Even then, a website can let the user act first,
> then just never give them the necessary signed transaction.
>
> In other words: one always requires dedicated logic in order to fully verify
> the swap parameters and also perform an on-chain sweep/timeout, which is a
> requirement for a trust minified swap. A user can trust the service to just
> send to the given address or pay an invoice for them, but that's not a trust
> minimized swap.
>
> -- Laolu
>
> On Tue, Jun 13, 2023 at 6:52 AM Thomas Voegtlin <thomasv at electrum.org>
> wrote:
>
>> Good morning list,
>>
>> I would like to propose an extension to BOLT-11, where an invoice can
>> contain two bundled payments, with distinct preimages and amounts.
>>
>> The use case is for services that require the prepayment of a mining fee
>> in order for a non-custodian exchange to take place:
>> - Submarine swaps
>> - JIT channels
>>
>> In both cases, the service provider receives a HTLC for which they do not
>> have the preimage, have to send funds on-chain (to the channel or submarine
>> swap funding address), and wait for the client to reveal the preimage when
>> they claim the payment. Because there is no guarantee that the client will
>> actually claim the payment, the service providers need to ask prepayment of
>> mining fees.
>>
>> In the case of submarine swaps, services that use dedicated client
>> software, such as Loop by Lightning Labs, can ask for a prepayment, because
>> their software can handle it (this is called "no show penalty" on the Loop
>> website). However, competitors who do require a dedicated wallet, not such
>> as the Boltz exchange, cannot do that. Their website shows an invoice to
>> the user, whose wallet that is agnostic about the swap, and it would be
>> unpractical for them to show two invoices to be paid simultaneously. This
>> creates a situation where Boltz is vulnerable to DoS attacks, where the
>> attacker forces them to pay on-chain fees.
>>
>> In the case of JIT channels, providers who want to protect themselves
>> against this mining fee attack need to ask the preimage of the main payment
>> before they open the channel. I believe this is what Phoenix does (although
>> their pay-to-open service is not open-source, so I cannot really check).
>> The issue is that a service that asks for the preimage first becomes
>> custodian. From a legal perspective, it does not matter whether they open
>> the channel immediately after receiving the preimage, the ordering of
>> events makes their service custodian. In Europe, such a service will fall
>> within the European MICA regulation. Competitors who refuse to offer
>> custodian services, such as Electrum, are excluded from that game.
>>
>> In order to solve that, it would be beneficial to bundle the prepayment
>> and the main payment in the same BOLT-11 invoice.
>>
>> The semantics of bundled payments is as follows:
>> - 1. the BOLT-11 invoice contains two preimages and two amounts:
>> prepayment and main payment.
>> - 2. the receiver should wait until all the HTLCs of both payments have
>> arrived, before they fulfill the HTLCs of the pre-payment. If the main
>> payment does not arrive, they should fail the pre-payment with a MPP
>> timeout.
>> - 3. once the HTLCs of both payments have arrived, the receiver fulfills
>> the HTLCs of the prepayment, and they broadcast their on-chain transaction.
>> Note that the main payment can still fail if the sender never reveal the
>> preimage of the main payment.
>>
>> Of course, nothing in my proposal prevents the service provider from
>> stealing the pre-payment, but that is already the case today.
>>
>> I believe this proposal would level the field in terms of competition
>> between lightning service providers. Currently, you need to use a dedicated
>> client in order to use Loop, and competitors who do not have an established
>> user base running a dedicated client are exposed to the mining fee attack.
>> I also believe that ACINQ would benefit from this, because it would make it
>> possible for them to make their pay-to-open service fully non-custodian. My
>> understanding is that in its current form, the 'pay-to-open' service used
>> by Phoenix will fall into the scope of the European MICA regulation, which
>> they should consider as a serious issue.
>>
>> Finally, I believe that such a change should be implemented in BOLT-11,
>> and not using BOLT-12 or onion messages. Indeed, my proposal does not
>> require the exchange of new messages. Some of the initial feedback I
>> received was that this is a use case for BOLT-12 or OM, but I think that
>> this is making things unnecessarily complicated. We should not add new
>> messages when things can be done in a non-interactive way.
>>
>> Cheers,
>> ThomasV
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
--
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-07 18:29:05

- reply

📅 Original date posted:2021-02-19
📝 Original message:I never liked BIP70. It was too complex, had too many features, and when
people discuss it, they do not even agree on what the main feature was.
Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
that payment requests were signed. I am making this post to discuss this.
When I send bitcoins to an exchange, I would like to receive a signed
request. I want to have a proof that the exchange asked me to send coins
to that address, in case it has been hijacked by some intern working
there. If that feature was implemented by an exchange, it would guide my
decision to use that exchange over its competitors.
I do not think that a single exchange ever implemented that, but I guess
this is because BIP70 is a terrible standard. LN payment requests are
signed, do not require SSL, do not require interactivity, and therefore
exchanges use them. Can't we achieve the same for on-chain payments? Is
anyone working on that?
I would be more than happy to remove BIP70 support from Electrum, if
there was another standard for signed requests.
Thomas
--
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-07 18:24:53

- reply

📅 Original date posted:2020-05-23
📝 Original message:Hello list,
I have been trying to CPFP a transaction using OP_RETURN, because the
remaining output value would have been lower than the dust threshold.
The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
single p2wsh input.
The result is a 60 bytes transaction (without witness), that gets
rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
is equal to 82 bytes.
Why is that value so high? Would it make sense to lower it to 60?
Thomas

2023-06-07 18:09:41

- reply

📅 Original date posted:2018-01-10
📝 Original message:A vulnerability has been found in Electrum, and patched in version
3.0.5. Please update your software if you are running an earlier version.
The following is a copy of the summary and guidelines we posted on our
website: https://github.com/spesmilo/electrum-docs/blob/master/cve.rst
A CVE number for the issue has been requested 2 days ago, and has not
been attributed yet.
JSONRPC vulnerability in Electrum 2.6 to 3.0.4
==============================================
On January 6th, a vulnerability was disclosed in the Electrum wallet
software, that allows malicious websites to execute wallet commands
through JSONRPC executed in a web browser. The bug affects versions
2.6 to 3.0.4 of Electrum, on all platforms. It also affects clones of
Electrum such as Electron Cash.
Can funds be stolen?
--------------------
Wallets that are not password protected are at risk of theft, if they
are opened with a version of Electrum older than 3.0.5 while a web
browser is active.
In addition, the vulnerability allows an attacker to modify user
settings, the list of contacts in a wallet, and the "payto" and
"amount" fields of the user interface while Electrum is running.
Although there is no known occurrence of Bitcoin theft occurring
because of this vulnerability, the risk increases substantially now
that the vulnerability has been made public.
Can wallet data be leaked?
--------------------------
Yes, an attacker can obtain private data, such as: Bitcoin addresses,
transaction labels, address labels, wallet contacts and master public
keys.
Can a password-protected wallet be bruteforced?
-----------------------------------------------
Not realistically. The vulnerability does not allow an attacker to
access encrypted seed or private keys, which would be needed in order
to perform an efficient brute force attack. Without the encrypted
seed, an attacker must try passwords using the JSONRPC interface,
while the user is visiting a malicious page. This is several orders of
magnitude slower than an attack with the encrypted seed, and
restricted in time. Even a weak password will protect against that.
What should users do?
---------------------
All users should upgrade their Electrum software, and stop using old
versions.
Users who did not protect their wallet with a password should create a
new wallet, and move their funds to that wallet. Even if it never
received any funds, a wallet without password should not be used
anymore, because its seed might have been compromised.
In addition, users should review their settings, and delete all
contacts from their contacts list, because the Bitcoin addresses of
their contacts might have been modified.
How to upgrade Electrum
-----------------------
Stop running any version of Electrum older than 3.0.5, and install
Electrum the most recent version. On desktop, make sure you download
Electrum from https://electrum.org and no other website. On Android,
the most recent version is available in Google Play.
If Electrum 3.0.5 (or any later version) cannot be installed or does
not work on your computer, stop using Electrum on that computer, and
access your funds from a device that can run Electrum 3.0.5. If you
really need to use an older version of Electrum, for example in order
to access wallet seed, make sure that your computer is offline, and
that no web browser is running on the computer at the same time.
Should all users move their funds to a new address?
---------------------------------------------------
We do not recommend moving funds from password protected wallets. For
wallets that were not password protected, moving funds is an extreme
precaution, that might not be necessary; indeed, if a wallet was
compromised, it is very likely that the attacker would have stolen the
funds immediately.
When was the issue reported and fixed?
--------------------------------------
The absence of password protection in the JSONRPC interface was
reported on November 25th, 2017 by user jsmad:
https://github.com/spesmilo/electrum/issues/3374
jsmad's report was about the Electrum daemon, a piece of software that
runs on web servers and is used by merchants in order to receive
Bitcoin payments. In that context, connections to the daemon from the
outside world must be explicitly authorized, by setting 'rpchost' and
'rpcport' in the Electrum configuration.
On January 6th, 2018, Tavis Ormandy demonstrated that the JSONRPC
interface could be exploited against the Electrum GUI, and that the
attack could be carried out by a web browser running locally, visiting
a webpage with specially crafted JavaScript.
We released a new version (3.0.4) in the hours following Tavis' post,
with a patch written by mithrandi (Debian packager), that addressed
the attack demonstrated by Tavis. In addition, the Github issue
remained open, because mithrandi's patch was not adding password
protection to the JSONRPC interface.
Shortly after the 3.0.4 release we started to work on adding proper
password protection to the JSONRPC interface of the daemon, and that
part was ready on Sunday, January 7th. We also learned on Sunday
afternoon that the first patch was not effective against another,
similar attack, using POST. This is why we did not delay the 3.0.5
release, which includes password protection, and completely disables
JSONRPC in the GUI.
--
Electrum Technologies GmbH / Waldemarstr 37a / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-07 18:07:30

- reply

📅 Original date posted:2017-11-02
📝 Original message:Electrum 3.0 was tagged and released yesterday night.
Release notes:
# Release 3.0 - Uncanny Valley (November 1st, 2017)
* The project was migrated to Python3 and Qt5. Python2 is no longer
supported. If you cloned the source repository, you will need to
run "python3 setup.py install" in order to install the new
dependencies.
* Segwit support:
- Native segwit scripts are supported using a new type of
seed. The version number for segwit seeds is 0x100. The install
wizard will not create segwit seeds by default; users must
opt-in with the segwit option.
- Native segwit scripts are represented using bech32 addresses,
following BIP173. Please note that BIP173 is still in draft
status, and that other wallets/websites may not support
it. Thus, you should keep a non-segwit wallet in order to be
able to receive bitcoins during the transition period. If BIP173
ends up being rejected or substantially modified, your wallet
may have to be restored from seed. This will not affect funds
sent to bech32 addresses, and it will not affect the capacity of
Electrum to spend these funds.
- Segwit scripts embedded in p2sh are supported with hardware
wallets or bip39 seeds. To create a segwit-in-p2sh wallet,
trezor/ledger users will need to enter a BIP49 derivation path.
- The BIP32 master keys of segwit wallets are serialized using new
version numbers. The new version numbers encode the script type,
and they result in the following prefixes:
* xpub/xprv : p2pkh or p2sh
* ypub/yprv : p2wpkh-in-p2sh
* Ypub/Yprv : p2wsh-in-p2sh
* zpub/zprv : p2wpkh
* Zpub/Zprv : p2wsh
These values are identical for mainnet and testnet; tpub/tprv
prefixes are no longer used in testnet wallets.
- The Wallet Import Format (WIF) is similarly extended for segwit
scripts. After a base58-encoded key is decoded to binary, its
first byte encodes the script type:
* 128 + 0: p2pkh
* 128 + 1: p2wpkh
* 128 + 2: p2wpkh-in-p2sh
* 128 + 5: p2sh
* 128 + 6: p2wsh
* 128 + 7: p2wsh-in-p2sh
The distinction between p2sh and p2pkh in private key means that
it is not possible to import a p2sh private key and associate it
to a p2pkh address.
* A new version of the Electrum protocol is required by the client
(version 1.1). Servers using older versions of the protocol will
not be displayed in the GUI.
* By default, transactions are time-locked to the height of the
current block. Other values of locktime may be passed using the
command line.
--
Electrum Technologies GmbH / Waldemarstr 37a / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-07 18:06:06

- reply

📅 Original date posted:2017-09-17
📝 Original message:On 17.09.2017 04:29, Pieter Wuille wrote:
>
> This has been a low-priority thing for me, though, and the computation work
> to find a good checksum is significant.
>
Thanks for the info. I guess this means that a bech32 format for private
keys is not going to happen soon. Even if such a format was available,
the issue would remain for segwit-in-p2sh addresses, which use base58.
The ambiguity of the WIF format is currently holding me from releasing a
segwit-capable version of Electrum. I believe it is not acceptable to
use the current WIF format with segwit scripts; that would just create
technological debt, forcing wallets to try all possible scripts. There
is a good reason why WIF adds a 0x01 byte for compressed pubkeys; it
makes it unambiguous.
I see only two options:
1. Disable private keys export in Electrum Segwit wallets, until a
common WIF extension has been agreed on.
2. Define my own WIF extension for Electrum, and go ahead with it.
Defining my own format does make sense for the xpub/xprv format, because
Electrum users need to share master public keys across Electrum wallets.
It makes much less sense for WIF, though, because WIF is mostly used to
import/sweep keys from other wallets.
I would love to know what other wallet developers are going to do,
especially Core. Are you going to export private keys used in segwit
scripts in the current WIF format?

2023-06-07 18:06:05

- reply

📅 Original date posted:2017-09-15
📝 Original message:The Wallet Import Format (WIF) currently appends a 0x01 byte after the
raw private key, when that key needs to be used in conjunction with a
compressed public key. This allows wallets to associate a single Bitcoin
address to a WIF key.
It would be useful to extend the semantics of that byte, to signal for
segwit scripts, because these scripts result in different addresses.
That way, a WIF private key can still be associated to a single Bitcoin
address.
What WIF currently does is:
Nothing -> uncompressed pubkey
0x01 -> compressed pubkeys, non-segwit (can be used in P2PKH or P2SH)
We could extend it as follows:
0x02 -> segwit script embedded in P2SH (P2WPKH or P2WSH)
0x03 -> native segwit script (P2WKH or P2WSH)
Note 1: This is similar to my {x,y,z}{pub,prv} proposal for bip32
extended keys. (see other thread)
Note 2: It is probably not useful to use distinct bytes for P2WKH and
P2WSH, because the P2SH script is not known anyway. We did not do it for
non-segwit addresses, I guess we should keep it the way it is.
Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.
Note 4: my proposal will not result in a user visible change at the
beginning of the string, like we have for compressed/uncompressed. This
could be improved.

2023-06-07 18:05:46

- reply

📅 Original date posted:2017-09-12
📝 Original message:On 09.09.2017 16:08, shiva sitamraju via bitcoin-dev wrote:
> Hi,
>
> I understand the motivation of adding the birthdate field. However, not
> very comfortable with having this in the public key serialization. There
> are privacy implication of both the birthday field and having the complete
> derivation path, which takes space.
> > I am fine with Thomas proposal of {x,y,z}. Having additional version byte
> field looks modular but since since we already have the big enough version
> field in bip32, better to use that instead of adding more bytes.
>
> Thomas, can you please explain why we require different version for P2WPKH
> or P2WSH versus (P2WPKH or P2WSH) nested in P2SH. It looked to me that they
> would have the same output bitcoin address and under same account.
no, native scripts do not have the same address. see bip173
>
> On Fri, Sep 8, 2017 at 2:09 AM, <
> bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev at lists.linuxfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> or, via email, send a message with subject or body 'help' to
>> bitcoin-dev-request at lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-owner at lists.linuxfoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Proposal: Extended serialization format for BIP-32
>> wallets (Andreas Schildbach)
>> 2. Re: Proposal: Extended serialization format for BIP-32
>> wallets (Pavol Rusnak)
>> 3. Re: Fast Merkle Trees (Mark Friedenbach)
>> 4. Re: Proposal: Extended serialization format for BIP-32
>> wallets (Thomas Voegtlin)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 7 Sep 2017 21:35:49 +0200
>> From: Andreas Schildbach <andreas at schildbach.de>
>> To: bitcoin-dev at lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
>> BIP-32 wallets
>> Message-ID: <oos72e$rjp$1 at blaine.gmane.org>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:
>>> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>>>> A solution is still needed to wallets who do not wish to use BIP43
>>>
>>> What if we added another byte field OutputType for wallets that do not
>>> follow BIP43?
>>>
>>> 0x00 - P2PKH output type
>>> 0x01 - P2WPKH-in-P2SH output type
>>> 0x02 - native Segwit output type
>>>
>>> Would that work for you?
>>
>> I think that would work.
>>
>>> The question is whether this field should be present only if depth==0x00
>>> or at all times. What is your suggestion, Thomas?
>>
>> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
>> we need this field. I think it should always be present if a chain is
>> limited to a certain script type.
>>
>> There is however the case where even on one chain, script types are
>> mixed. In this case the field should be omitted and the wallet needs to
>> scan for all (known) types. Afaik Bitcoin Core is taking this path.
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 7 Sep 2017 22:00:05 +0200
>> From: Pavol Rusnak <stick at satoshilabs.com>
>> To: Andreas Schildbach <andreas at schildbach.de>, Bitcoin Protocol
>> Discussion <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
>> BIP-32 wallets
>> Message-ID: <40ed03a1-915c-33b0-c4ac-e898c8c733ba at satoshilabs.com>
>> Content-Type: text/plain; charset=windows-1252
>>
>> On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
>>> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
>>> we need this field.
>>
>> But the depth of exported public key will be null. It does not make
>> sense to export xpub for m or m/0' for your particular case.
>>
>>> I think it should always be present if a chain is
>>> limited to a certain script type.
>>
>> I am fine with having the path there all the time.
>>
>>> There is however the case where even on one chain, script types are
>>> mixed. In this case the field should be omitted and the wallet needs to
>>> scan for all (known) types. Afaik Bitcoin Core is taking this path.
>>
>> Is that really the case? Why come up with a hierarchy and then don't use
>> it?
>>
>> --
>> Best Regards / S pozdravom,
>>
>> Pavol "stick" Rusnak
>> CTO, SatoshiLabs
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 7 Sep 2017 13:04:30 -0700
>> From: Mark Friedenbach <mark at friedenbach.org>
>> To: Russell O'Connor <roconnor at blockstream.io>
>> Cc: Bitcoin Protocol Discussion
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Fast Merkle Trees
>> Message-ID: <40D6F502-3380-4B64-BCD9-80D361EED35C at friedenbach.org>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> TL;DR I'll be updating the fast Merkle-tree spec to use a different
>> IV, using (for infrastructure compatability reasons) the scheme
>> provided by Peter Todd.
>>
>> This is a specific instance of a general problem where you cannot
>> trust scripts given to you by another party. Notice that we run into
>> the same sort of problem when doing key aggregation, in which you must
>> require the other party to prove knowledge of the discrete log before
>> using their public key, or else key cancellation can occur.
>>
>> With script it is a little bit more complicated as you might want
>> zero-knowledge proofs of hash pre-images for HTLCs as well as proofs
>> of DL knowledge (signatures), but the basic idea is the same. Multi-
>> party wallet level protocols for jointly constructing scriptPubKeys
>> should require a 'delinearization' step that proves knowledge of
>> information necessary to complete each part of the script, as part of
>> proving the safety of a construct.
>>
>> I think my hangup before in understanding the attack you describe was
>> in actualizing it into a practical attack that actually escalates the
>> attacker's capabilities. If the attacker can get you to agree to a
>> MAST policy that is nothing more than a CHECKSIG over a key they
>> presumably control, then they don't need to do any complicated
>> grinding. The attacker in that scenario would just actually specify a
>> key they control and take the funds that way.
>>
>> Where this presumably leads to an actual exploit is when you specify a
>> script that a curious counter-party actually takes the time to
>> investigate and believes to be secure. For example, a script that
>> requires a signature or pre-image revelation from that counter-party.
>> That would require grinding not a few bytes, but at minimum 20-33
>> bytes for either a HASH160 image or the counter-party's key.
>>
>> If I understand the revised attack description correctly, then there
>> is a small window in which the attacker can create a script less than
>> 55 bytes in length, where nearly all of the first 32 bytes are
>> selected by the attacker, yet nevertheless the script seems safe to
>> the counter-party. The smallest such script I was able to construct
>> was the following:
>>
>> <fake-pubkey> CHECKSIGVERIFY HASH160 <preimage> EQUAL
>>
>> This is 56 bytes and requires only 7 bits of grinding in the fake
>> pubkey. But 56 bytes is too large. Switching to secp256k1 serialized
>> 32-byte pubkeys (in a script version upgrade, for example) would
>> reduce this to the necessary 55 bytes with 0 bits of grinding. A
>> smaller variant is possible:
>>
>> DUP HASH160 <fake-pubkey-hash> EQUALVERIFY CHECKSIGVERIFY HASH160
>> <preimage> EQUAL
>>
>> This is 46 bytes, but requires grinding 96 bits, which is a bit less
>> plausible.
>>
>> Belts and suspenders are not so terrible together, however, and I
>> think there is enough of a justification here to look into modifying
>> the scheme to use a different IV for hash tree updates. This would
>> prevent even the above implausible attacks.
>>
>>
>>> On Sep 7, 2017, at 11:55 AM, Russell O'Connor <roconnor at blockstream.io>
>> wrote:
>>>
>>>
>>>
>>> On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach <mark at friedenbach.org
>> <mailto:mark at friedenbach.org>> wrote:
>>> I've been puzzling over your email since receiving it. I'm not sure it
>>> is possible to perform the attack you describe with the tree structure
>>> specified in the BIP. If I may rephrase your attack, I believe you are
>>> seeking a solution to the following:
>>>
>>> Want: An innocuous script and a malign script for which
>>>
>>> double-SHA256(innocuous)
>>>
>>> is equal to either
>>>
>>> fast-SHA256(double-SHA256(malign) || r) or
>>> fast-SHA256(r || double-SHA256(malign))
>>>
>>> or fast-SHA256(fast-SHA256(double-SHA256(malign) || r1) || r0)
>>> or fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) || r0)
>>> or ...
>>>
>>> where r is a freely chosen 32-byte nonce. This would allow the
>>> attacker to reveal the innocuous script before funds are sent to the
>>> MAST, then use the malign script to spend.
>>>
>>> Because of the double-SHA256 construction I do not see how this can be
>>> accomplished without a full break of SHA256.
>>>
>>> The particular scenario I'm imagining is a collision between
>>>
>>> double-SHA256(innocuous)
>>>
>>> and
>>>
>>> fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) ||
>> r1) || r0).
>>>
>>> where innocuous is a Bitcoin Script that is between 32 and 55 bytes long.
>>>
>>> Observe that when data is less than 55 bytes then double-SHA256(data) =
>> fast-SHA256(fast-SHA256(padding-SHA256(data)) || 0x8000...100) (which is
>> really the crux of the matter).
>>>
>>> Therefore, to get our collision it suffices to find a collision between
>>>
>>> padding-SHA256(innocuous)
>>>
>>> and
>>>
>>> fast-SHA256(double-SHA256(malign) || r2) || r1
>>>
>>> r1 can freely be set to the second half of padding-SHA256(innocuous), so
>> it suffices to find a collision between
>>>
>>> fast-SHA256(double-SHA256(malign) || r2)
>>>
>>> and the first half of padding-SHA256(innocuous) which is equal to the
>> first 32 bytes of innocuous.
>>>
>>> Imagine the first opcode of innocuous is the push of a value that the
>> attacker claims to be his 33-byte public key.
>>> So long as the attacker doesn't need to prove that they know the
>> discrete log of this pubkey, they can grind r2 until the result of
>> fast-SHA256(double-SHA256(malign) || r2) contains the correct first
>> couple of bytes for the script header and the opcode for a 33-byte push. I
>> believe that is only about 3 or 4 bytes of they need to grind out.
>>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
>> attachments/20170907/63af0292/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 7 Sep 2017 22:39:17 +0200
>> From: Thomas Voegtlin <thomasv at electrum.org>
>> To: "bitcoin-dev at lists.linuxfoundation.org"
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
>> BIP-32 wallets
>> Message-ID: <9e74dc17-105c-b43c-7780-4fa690043fe2 at electrum.org>
>> Content-Type: text/plain; charset=windows-1252
>>
>>
>>
>> On 07.09.2017 18:23, Pavol Rusnak wrote:
>>> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>>>> A solution is still needed to wallets who do not wish to use BIP43
>>>
>>> What if we added another byte field OutputType for wallets that do not
>>> follow BIP43?
>>>
>>> 0x00 - P2PKH output type
>>> 0x01 - P2WPKH-in-P2SH output type
>>> 0x02 - native Segwit output type
>>>
>>> Would that work for you?
>>>
>>> The question is whether this field should be present only if depth==0x00
>>> or at all times. What is your suggestion, Thomas?
>>>
>>
>>
>> well, in my initial proposal, I wrote that this value should be user
>> visible. That is why I used version bytes. If you create an extra byte
>> field, and then use base58 or bech32 encoding, the value will not be
>> user visible anymore.
>>
>> The initial implementation of segwit xpub/xprv in Electrum used a flag
>> that was not user visible (I added 1 to the bip32 version bytes, which
>> leaves the xpub/xprv prefix unchanged). I have experimented with that
>> invisible flag for more than 6 months now, and I am now convinced that
>> it is better to make that flag user visible.
>>
>> The reason is that when users create wallets with multisig scripts, they
>> need to combine several master public keys. However, these master public
>> keys should all be of the same type: it would not make sense to create a
>> 2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By
>> imposing that all master keys are of the same type, we ensure that all
>> cosigners agree on the script type that will be used to derive addresses.
>>
>> In other words, if users are exposed to master keys and need to
>> manipulate them, it is better to let them see what they are doing.
>>
>> OTOH if you do not plan to expose your users to these keys, you probably
>> do not need a serialization format.
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> End of bitcoin-dev Digest, Vol 28, Issue 17
>> *******************************************
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Electrum Technologies GmbH / Waldemarstr 37a / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin

2023-06-07 18:05:32

- reply

📅 Original date posted:2017-09-07
📝 Original message:On 07.09.2017 18:23, Pavol Rusnak wrote:
> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>> A solution is still needed to wallets who do not wish to use BIP43
>
> What if we added another byte field OutputType for wallets that do not
> follow BIP43?
>
> 0x00 - P2PKH output type
> 0x01 - P2WPKH-in-P2SH output type
> 0x02 - native Segwit output type
>
> Would that work for you?
>
> The question is whether this field should be present only if depth==0x00
> or at all times. What is your suggestion, Thomas?
>
well, in my initial proposal, I wrote that this value should be user
visible. That is why I used version bytes. If you create an extra byte
field, and then use base58 or bech32 encoding, the value will not be
user visible anymore.
The initial implementation of segwit xpub/xprv in Electrum used a flag
that was not user visible (I added 1 to the bip32 version bytes, which
leaves the xpub/xprv prefix unchanged). I have experimented with that
invisible flag for more than 6 months now, and I am now convinced that
it is better to make that flag user visible.
The reason is that when users create wallets with multisig scripts, they
need to combine several master public keys. However, these master public
keys should all be of the same type: it would not make sense to create a
2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By
imposing that all master keys are of the same type, we ensure that all
cosigners agree on the script type that will be used to derive addresses.
In other words, if users are exposed to master keys and need to
manipulate them, it is better to let them see what they are doing.
OTOH if you do not plan to expose your users to these keys, you probably
do not need a serialization format.

2023-06-07 18:05:31

- reply

📅 Original date posted:2017-09-07
📝 Original message:On 07.09.2017 00:29, Pavol Rusnak via bitcoin-dev wrote:
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
>
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
>
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
>
> Feel free to comment.
>
Your proposal forces wallets to use the derivation path in order to
determine the type of output script. it will work only in the context of
BIP43.
Therefore, it should not be proposed as a BIP32 improvement, but as a
improvement of BIP43.
A solution is still needed to wallets who do not wish to use BIP43

2023-06-07 18:05:23

- reply

📅 Original date posted:2017-09-06
📝 Original message:On 05.09.2017 21:00, Kabuto Samourai wrote:
>
> The Electrum approach is nice but may not go far enough, as xpub and zpub
> both list "P2PKH or P2SH." Why not expand the number of version prefixes to
> eliminate the ambiguity?
>
I agree that this would make sense if we had done it from the start.
However, fixing that now might be difficult.
My "xyz" proposal extends the current format in a way that is very easy
to deploy, because existing software will require minimal changes.
However, if we eliminate the p2sh ambiguity now, wallets will need to
add extra safeguards, in order to prevent scenarios that are currently
allowed, and they will need to handle legacy xpub/xprv differently than
ypub and zpub. This would take much more time to deploy.
In addition, consensus might be more difficult to reach on that; I guess
not all developers will not agree that removing that ambiguity is
useful. Since there is an infinity of possible P2SH scripts, it will
never be possible to remove ambiguity from a master key associated to a
P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
strong.

2023-06-07 18:05:22

- reply

📅 Original date posted:2017-09-05
📝 Original message:On 05.09.2017 19:03, Luke Dashjr wrote:
> It seems desirable to use the same seed for all different script formats...
That does not seem desirable to everybody.
If you want to guarantee that users will be able to recover all their
funds from their mnemonic seed (and that is what they expect), then
wallets must implement all script formats, even the ones that are
deprecated. In addition, the list of script formats that must be
supported is not defined in advance, but it keeps growing. This makes
wallet implementation increasingly difficult. In the long run, seed
portability is guaranteed to fail in such a system.
> As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> really doesn't make sense to differentiate segwit specifically.
That's not a reason. The fact that xpub/xprv can be used for both P2PKH
and P2SH has already resulted in users receiving coins on addresses they
do not control.

2023-06-07 18:05:21

- reply

📅 Original date posted:2017-09-05
📝 Original message:BIP32 extended public/private keys have version bytes that result in the
user visible xpub/xprv prefix. The BIP's recommendation is to use
different version bytes for other networks (such as tpub/tprv for testnet)
I would like to use additional version bytes to indicate the type of
output script used with the public keys.
I believe the change should be user visible, because users are exposed
to master public keys. I propose the following prefixes:
========== =========== ===================================
Version Prefix Description
========== =========== ===================================
0x0488ade4 xprv P2PKH or P2SH
0x0488b21e xpub P2PKH or P2SH
0x049d7878 yprv (P2WPKH or P2WSH) nested in P2SH
0x049d7cb2 ypub (P2WPKH or P2WSH) nested in P2SH
0x04b2430c zprv P2WPKH or P2WSH
0x04b24746 zpub P2WPKH or P2WSH
========== =========== ===================================
(source: http://docs.electrum.org/en/latest/seedphrase.html)
I have heard the argument that xpub/xprv serialization is a format for
keys, and that it should not be used to encode how these keys are used.
However, the very existence of version bytes, and the fact that they are
used to signal whether keys will be used on testnet or mainnet goes
against that argument.
If we do not signal the script type in the version bytes, I believe
wallet developers are going to use dirtier tricks, such as the bip32
child number field in combination with bip43/bip44/bip49.
Thomas

2023-06-07 18:05:16

- reply

📅 Original date posted:2017-09-05
📝 Original message:On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:
> Hi,
>
> Thanks Thomas. The procedure described in
> http://docs.electrum.org/en/latest/seedphrase.html is really what I was
> looking for ! I really don't see any point of following BIP49, If possible
> it would be great if you can propose an alternative to BIP49 that follows
> similar structure to what is used in electrum.
>
> I have proposed following changes to BIP32 serialization format
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format
> to differentiate segwit xpub/xprv. Below the list of new version bytes,
> resulting base58 prefix and network type:
>
> 0x042393df , sxpr , segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb , segwit testnet public key
> 0x042224cc , stpr , segwit testnet private key
>
I have proposed a similar idea, with letters z,y,z combined with pub/prv
(see the electrum documentation page)
The point is that we need 3 types of keys, not 2, because there are two
types of segwit output scripts: native and nested in p2sh.
We could use t,u,v for testnet.

2023-06-07 18:05:15

- reply

📅 Original date posted:2017-09-03
📝 Original message:On 30.08.2017 09:24, shiva sitamraju via bitcoin-dev wrote:
>
> 2. Segwit wallet seed words have a different format which is incompatible
> with previous wallet seed words. This encodes the information that this
> wallet is segwit in the seed words itself. We need to define a structure
> for this
>
That is what Electrum does.
See http://docs.electrum.org/en/latest/seedphrase.html

2023-06-07 18:05:10

- reply

📅 Original date posted:2017-08-30
📝 Original message:On 29.08.2017 12:19, Simone Bronzini via bitcoin-dev wrote:
> 2. SegWit addresses:
> since mixing SegWit and non-SegWit addresses on the same BIP44 structure
> could lead to UTXOs not being completely recognised by old wallets,
> BIP49 was proposed to separate the key space.
This will lead to old UTXOs not being recognized by NEW wallets, because
at some point new wallets will not care about implementing old standards.
The only way to address this is to get out of bip39 and bip43, and to
include a version number in the mnemonic seed.

2023-06-07 18:00:02

- reply

📅 Original date posted:2017-04-13
📝 Original message:I think it is better not to use the coinbase, because it might collide
with other proposals, and because coinbase is not part of the block header.
I agree that a small set of standard threshold may be sufficient; a one
percent resolution is probably not needed. If we use 4 bits we can
encode 15 different thresholds + zero (meaning no support). For example
we can have all thresholds between 25% and 95% separated by 5%.
Using 4 bits per soft-fork proposal leaves enough room to fit 7
simultaneous proposals in version bits. That should be plenty.
>
> I still like the coinbase idea though - more than using up the BIP9 versionbits range for verbose signaling.
>
> BIP9 (and other proposals which use those 29 versionbits) currently assume that the participants on the network will coordinate in some form or other, to agree on what the bits mean (in terms of change deployments).
>
> It would be very easy to also agree on a set of "standard" threshold levels and map those onto e.g. 1 byte.
>
> Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are standardized deployment schedules that people find useful.
> So a BIP9 conformant schedule could be A = 95% / 2016 window,
> while B = 75%/2016, etc.
>
> This would be quite a compact yet still readable signaling. The space of values is large enough that I doubt we'd see much contention.
>
> Regards
> Sancho
>

2023-06-07 18:00:01

- reply

📅 Original date posted:2017-04-13
📝 Original message:Hi Sancho,
I saw your proposal. However, my point is that the threshold should be
part of the signaling, and not fixed in the soft-fork proposal.
I agree that coinbase space might be a limitation.
To avoid this, I realize that the threshold could be encoded in the
version bits. We have 32 version bits, and the top 3 bits must be set to
001 in BIP9. In order to extend BIP9 in a backward compatible way, we
could set these 3 top bits to 010, and use the 29 remaining bits for
soft fork signaling.
If we use 7 bits per soft-fork proposal, we have enough space to encode
four simultaneous soft-fork proposals, and sub-percent granularity for
the threshold (2^7=128).
Le 13/04/2017 à 16:17, Sancho Panza a écrit :
> Thomas,
>
> I wonder if you've seen my proposal on how to make BIP9 more configurable:
> https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki
>
> This could be extended with a coinbase signaling feature as you suggest.
> This could include parameter information for forks which a miner is signaling, for coordination.
>
> Currently I've not included something like this, but it might make a nice addition.
> One problem is the limited space in coinbase for embedding data on the large number of possible independent deployments.
>
> Regards,
> Sancho
>

2023-06-07 18:00:00

- reply

📅 Original date posted:2017-04-13
📝 Original message:Disclaimer: I am fully supportive of Segregated Witness and its
activation by users through BIP148. However, I also believe that a
soft fork would be less risky if it was initially activated by miners,
before the date set in BIP148. This proposal is not intended to
replace UASF, but to mitigate the risks.
The following idea might already have been proposed and discussed
elsewhere. If that is the case, I am sorry for the noise.
Background
==========
BIP9 requires 95% of miner hashrate support in order to activate a
soft-fork. So far, the lack of miner consensus about Segwit has been
frustrating both users and developers. This had led some users to
propose a soft fork activation regardless of the expressed level of
miner support (UASF, BIP148).
There are many risks associated with UASF. If the fork is activated
with less than 50% of the hashing power, the blockchain will have two
competing branches. In addition, if the hashrate on the forking branch
is very low, that branch will be exposed to attacks, where non-empty
blocks are systematically orphaned by adverse miners. This threat may
be a strong deterrent for miners willing to support the fork.
The main argument in favor of UASF is that users, not miners, give its
value to Bitcoin. Therefore, users and markets should have the power
to decide which branch of the fork has the most value, and
profit-driven miners should follow. If the soft-forking branch is
valued more than the non-forking branch, it will end up attracting a
majority of the hashing power, and the non-forking branch will
eventually be orphaned.
Feedback through markets, however, will only work if the forking
branch can effectively be used. If the forking branch is rendered
unusable by adverse miners, there is little chance the new coins will
ever reach markets. To make things worse, profit-driven miners might
adopt a passive attitude and decide to mine on the forking branch only
once a proper price has been set by markets, or only once they see
that it has enough hashing power to be usable. Thus, the lack of
hashrate information prior to the soft fork increases the risk.
On the other hand, if a soft fork was initiated with more than 33% of
the hashing power, then it would probably be viable, because the
remaining two thirds of the hashing power cannot successfully be
allocated to mine blocks on the non-forking branch and to orphan
blocks on the forking branch. Therefore, users will be able to move
coins on the forking branch, and markets will be able to set a price
on these coins, thus creating the feedback needed by profit-driven
miners.
Today about 30% of the hashing power are signaling their intention to
activate Segwit using BIP9. This hashrate is very close to the 33%
threshold, and it would probably be enough to initiate a viable soft
fork; indeed we can expect additional hashing power to be gained from
miners mining on both branches of the fork.
However, nothing suggests that a soft fork triggered with 30% of the
hashrate would be followed by the miners who are currently signaling
Segwit using BIP9. BIP9 signaling means that these miners are willing
to soft fork if support reaches 95%; it does not say anything about
their intentions if support is as low as 30%. In other words, BIP9
signaling does allow miners to properly signal their intentions.
BIP9 signaling
==============
The activation threshold is part of the semantics of BIP9. Miners who
use BIP9 do not only signal their support for a soft fork; they also
signal to other miners that they will activate the soft fork if and
only if support reaches 95%.
Some of these miners might actually be willing to activate a soft fork
with a lower support, even at the cost of creating two chains. Other
miners might not be supportive of that idea, because they consider
that the danger of their blocks being orphaned is too high.
The problem is that this information, at which level of support miners
are willing to initiate a soft fork, is not available. Thus, miners
who are willing to initiate a soft fork at a lower hashrate cannot
coordinate their action.
Proposal: Soft Fork Threshold Signaling
=======================================
Miners signal the threshold at which they are willing to activate a
soft fork. The value of the threshold is published in the coinbase
transaction of the block, with the corresponding version bit.
Miners activate a soft fork if their threshold has been reached over
the last retargeting period. For example, if 504 of 2016 blocks signal
a soft fork with a threshold equal or lower to 25%, then the soft fork
is activated by these miners.
If no activation threshold is reached, the current BIP9 signaling rate
indicator is replaced by a distribution of signaling rates per
threshold. The public availability of threshold information allows
miners to adjust their own threshold, and to optimize their chances of
activating the soft fork.
UASF
====
Even if the soft fork is not activated by miners, this proposal will
reduce the risks associated to a user activated soft fork (UASF). The
public availability of hashrate threshold information prior to the
soft fork will help miners decide whether they should join the fork
right after it has been activated, before price information is
available.
Vulnerabilities
===============
This proposal has similar vulnerabilities as BIP9: it is susceptible
to fake signaling by miners, and to miners withholding hashing power
before the fork.

2023-06-07 17:53:04

- reply

📅 Original date posted:2016-08-25
📝 Original message:Le 25/08/2016 à 09:39, Jonas Schnelli via bitcoin-dev a écrit :
> (I think this case if not completely unrealistic):
>
> What would happen, if a user gave out 21 addresses, then address0 had
> receive funds in +180 days after generation where address21 had receive
> funds immediately (all other addresses never received a tx).
>
> In a scan, address0 would be detected at <address-birthday>+180 days
> which would trigger the resize+20 of the address-lookup-window, but, we
> would require to go back 180day in order to detect received transaction
> of address21 (new lookup-window) in that case.
>
> Or do I misunderstand something?
>
>
That case is not unrealistic; a merchant might generate addresses that
are beyond their gap limit, and orders get filled at a later date.
In that case you will not get the same result when restoring your wallet
in a block-scanning wallet and in Electrum.
The lack of consideration for these cases is another issue with BIP44.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/5fed1fda/attachment-0001.sig>

2023-06-07 17:53:02

- reply

📅 Original date posted:2016-08-24
📝 Original message:Le 23/08/2016 à 22:12, Luke Dashjr via bitcoin-dev a écrit :
> BIP 39: Mnemonic code for generating deterministic keys
> - Used by many wallets and hundreds of thousands of users.
>
> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
> - Appears to be implemented by multiple wallets.
>
I personally believe that BIP39/BIP44 is a bad design. There is limited
support for these BIPs in Electrum, in order to provide compatibility
with hardware wallets. However, I do not plan to use BIP39/BIP44 for
default Electrum wallets, for the following reasons.
(Note that it does not make sense to consider BIP39 and BIP44
independently. Any wallet that decides to implement one without the
other would be considered as broken.)
Here is why I rejected this design:
1 - BIP44 uses multiple accounts. This means that in order to be
compatible with the standard, a wallet *must* implement multiple
accounts. A wallet that decides to keep things simple and use only one
account, will not allow users to recover all their funds when they
restore from a BIP39 seed, and will be considered as broken.
2 - An appealing feature of deterministic wallets is that you can use
the same instance of your wallet on different devices. Two instances of
your wallet can automatically synchronize their Bitcoin addresses, and
display the same balance. The problem is that hardened derivations break
this property. Indeed, with hardened derivations, software wallets need
to ask the user's password in order to derive new accounts. Therefore,
in order to implement automated detection of newly created accounts, a
BIP44-compatible software wallets would need to ask the user's password
whenever a new account is detected. This means that the wallet would ask
the password without the user initiating any action. This seems to be an
avenue for malware.
Of course, hardware wallets do not have that issue, because they can
derive new accounts without requesting a password from the user. BIP44
is a standard that has been designed for hardware wallets, but that
makes things really difficult for software wallets.
3 - Unneeded complexity. From an end user perspective, the multiple
accounts in BIP44 achieve the same result as using different derivation
passphrases with the same BIP39 seed phrase. The only real difference is
that BIP44 accounts can be enumerated deterministically, while
passphrases in general cannot. However, this property is of limited
interest, because automatic synchronization of multiple accounts cannot
be guaranteed for bip44 software wallets, as explained in 2.
4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed
phrase' in order to derive the BIP32 seed. This hash-based derivation
was added on my suggestion, in order to make the BIP independent from
the particular wordlist used to generate the seed phrases. However,
BIP39 also requires the implementation of a checksum, in order to verify
that a seed phrase is valid. Suprisingly, the specification of the
checksum involves wordlist indices. This means the checksum (and thus
the BIP) requires a fixed wordlist. This defeats the purpose of using a
hash for the derivation of the seed.
The authors of the BIP should either have used hash functions for both
the seed AND the checksum (that is what Electrum does), or for none of
them (in that case case, you can have a bidirectional function between
seed phrases and entropy, which is nice if you want to perform Shamir
secret sharing of seed phrases, at the expenses of a fixed wordlist). In
its current state, BIP39 takes the worst of both worlds.
5 - The fact that the wordlist must be part of BIP39, and cannot be
changed in the future, seems a terrible idea to me. I believe that a
specification should always try to be minimal. In that case, the
specification includes a 2000+ words dictionary, when it could have
avoided that.
Even if you decide that BIP39 is final, there will always be users
requiring the addition of wordlists for new languages. So, in practice,
this BIP will never be final.
6 - Finally, and most importantly, BIP39 seed phrases do not have a
version number. Without a version number, how are you going to derive
addresses from a BIP39 seed phrase, when wallets start to use to new
derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
that a BIP39 compatible wallet will have to check addresses from all the
derivation methods that ever existed in the past, in order to ensure
that all coins are correctly retrieved? Or will there be users that
cannot access their coins because their BIP39 seed phrase is too old for
newer software?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/926591b8/attachment.sig>

2023-06-07 17:51:27

- reply

📅 Original date posted:2016-06-22
📝 Original message:IMO the moderate success of BIP70 is caused by its complexity. Since the
amount of data in a BIP70 payment request does not fit in a bitcoin:
URI, an https server is required to serve the requests.
Only large merchants are able to maintain such an infrastructure; (even
Coinbase recently failed at it, they forgot to update their
certificate). For end users that is completely unpractical.
The main benefit of BIP70 is that the payment request is signed by the
requestor; this gives the sender a proof that they are sending to the
right person, and that the person actually requested the payment.
The same benefit can be achieved without the complexity of BIP70, by
extending the Bitcoin URI scheme. The requestor is authenticated using
DNSSEC, and the payment request is signed using an EC private key. A
domain name and an EC signature are short enough to fit in a Bitcoin URI
and to be shared by QR code or SMS text.
bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz
The URI scheme is extended with two fields:
name: DNS name containing a public key or bitcoin address
sig: signature
That extension is sufficient to provide authenticated requests, without
requiring a https server. The signed data can be serialized from the
URI, and DNSSEC verification succeeds without requesting extra data from
the requestor. The only assumption is that the verifier is able to make
DNS requests.
I am willing to write a BIP if other wallet developers are interested.
Le 20/06/2016 19:33, Erik Aronesty via bitcoin-dev a écrit :
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol. Not too late
> to support JSON messages as the standard going forward
>
> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification. alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas. personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)
>
> - missing an optional client supplied identification
>
> - lack of basic subscription support
>
> *Proposed for subscriptions:*
>
> - BIP0047 payment codes are recommended instead of wallet addresses when
> establishing subscriptions. Or, merchants can specify replacement
> addresses in ACK/NACK responses. UI confirms are *required *when there
> are no replacement addresses or payment codes used.
>
> - Wallets must confirm and store subscriptions, and are responsible for
> initiating them at the specified interval.
>
> - Intervals can *only *be from a preset list: weekly, biweekly, or 1,
> 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause
> suspension until the user re-verifies.
>
> - Wallets *may *optionally ask the user whether they want to be notified
> and confirm every interval - or not. Wallets that do not ask *must *notify
> before initiating each payment. Interval confirmations should begin at *least
> *1 day in advance of the next payment.
>
>
> *Proposed in general:*
> - JSON should be used instead of protocol buffers going forward. Easier to
> use, explain extend.
>
> - "Extendible" URI-like scheme to support multi-mode identity mechanisms on
> both payment and subscription requests. Support for keybase://, netki://
> and others as alternates to https://.
>
> - Support for client as well as merchant multi-mode verification
>
> - Ideally, the identity verification URI scheme is somewhat
> orthogonal/independent of the payment request itself
>
> Question:
>
> Should this be a new BIP? I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
>
> Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
> major protocols without any mention of payment URI's ... just a way of
> sending and receiving identity verified messages in general?
>
> I would be happy to implement plugins for identity protocols, if anyone
> thinks this is a good idea.
>
> Does anyone think https:// or keybase, or PGP or netki all by themselves,
> is enough - or is it always better to have an extensible protocol?
>
> - Erik Aronesty
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:50:43

- reply

📅 Original date posted:2016-05-15
📝 Original message:Le 14/05/2016 18:14, Jonas Schnelli via bitcoin-dev a écrit :
>
> AFAIK: Bip39 import (cross-wallet) is not supported by [...] Electrum [2] .
>
That is correct. There are several reasons why I decided not to use
BIP39 in Electrum. One of them was that BIP39 seed phrases do not
include a version number. A version number is needed in order to
maintain backward compatibility, everytime you change the address
derivation.
Electrum will allocate a new version number for seed phrases that should
be derived to segwit addresses.
I guess BIP39 designers will have to change the semantics of their
checksum bits, in order to encode a version number for segwit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160515/05a23ff8/attachment.sig>

2023-06-07 15:43:28

- reply

📅 Original date posted:2015-07-23
📝 Original message:There is some room for optimization in the Electrum server:
- the utxo database (patricia tree) should be made a binary tree.
- the server is written in python, which is slow.
I am not too worried about the short-term; a block takes on average 15s
to process on my server. For example, here are the last blocks in my log:
[23/07/2015-17:11:57] catch_up: block 366604 (0.145s 27.278s)
[23/07/2015-17:37:55] catch_up: block 366605 (0.126s 24.453s)
[23/07/2015-17:50:23] catch_up: block 366606 (0.133s 21.666s)
[23/07/2015-18:03:22] catch_up: block 366607 (0.110s 31.680s)
[23/07/2015-18:11:14] catch_up: block 366608 (0.093s 18.269s)
[23/07/2015-18:26:38] catch_up: block 366609 (0.115s 27.925s)
[23/07/2015-18:29:07] catch_up: block 366610 (0.062s 8.163s)
[23/07/2015-18:44:18] catch_up: block 366611 (0.118s 21.294s)
[23/07/2015-18:52:14] catch_up: block 366612 (0.075s 12.535s)
[23/07/2015-18:58:54] catch_up: block 366613 (0.100s 17.857s)
[23/07/2015-19:04:18] catch_up: block 366614 (0.061s 11.174s)
[23/07/2015-19:10:31] catch_up: block 366615 (0.064s 10.151s)
[23/07/2015-19:11:04] catch_up: block 366616 (0.035s 2.962s)
[23/07/2015-19:19:53] catch_up: block 366617 (0.081s 13.125s)
[23/07/2015-19:25:23] catch_up: block 366618 (0.037s 8.377s)
[23/07/2015-19:28:08] catch_up: block 366619 (0.044s 3.984s)
[23/07/2015-19:30:36] catch_up: block 366620 (0.051s 6.105s)
[23/07/2015-19:40:05] catch_up: block 366621 (0.058s 14.632s)
[23/07/2015-19:42:10] catch_up: block 366622 (0.040s 4.143s)
That server is a Hetzner EX40 box, rented for 50 eur/month. Of course if
you run the electrum server on a cheap VPS, performance might not be as
good.
Le 23/07/2015 17:56, Slurms MacKenzie via bitcoin-dev a écrit :
> Similar to the Bitcoin Node Speed Test, this is a quick quantitative look at how the Electrum server software handles under load. The Electrum wallet is extremely popular, and the distributed servers which power it are all hosted by volunteers without budget. The server requires a fully indexed Bitcoin Core daemon running, and produces sizable external index in order to allow SPV clients to quickly retrieve their history.
>
> 3.9G electrum/utxo
> 67M electrum/undo
> 19G electrum/hist
> 1.4G electrum/addr
> 24G electrum/
>
> Based on my own logs produced by the electrum-server console, it takes this server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes per megabyte of block to process into the index. This seems to hold true through the 10 or so blocks I have in my scroll buffer, the contents of blocks seem to be of approximately the same processing load. Continuing this trend with the current inter-block time of 9.8 minutes, an electrum-server instance running on modest-high end dedicated server is able to support up to 2.64 MB block sizes before permanently falling behind the chain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:42:43

- reply

📅 Original date posted:2015-07-22
📝 Original message:Hello,
Although Electrum clients connect to several servers in order to fetch
block headers, they typically request address balances and address
histories from a single server. This means that the chosen server knows
that a given set of addresses belong to the same wallet. That is true
even if Electrum is used over TOR.
There have been various proposals to improve on that, but none of them
really convinced me so far. One recurrent proposal has been to create
subsets of wallet addresses, and to send them to separate servers. In my
opinion, this does not really improve anonymity, because it requires
trusting more servers.
Here is an idea, inspired by TOR, on which I would like to have some
feedback: We create an anonymous routing layer between Electrum servers
and clients.
* Each server S publishes a RSA public key, KS
* Each client receives a list of available servers and their pubkeys
* For each wallet address, addr_i, a client chooses a server S_i, and a
RSA keypair (K_addr_i, k_addr_i)
* The client creates a list of encrypted requests. Each request contains
addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
* The client chooses a main server M, and sends the list of encrypted
requests to M
* M dispatches the client's requests to the corresponding servers S_i
(without the client's IP address.)
* Each server decrypts the requests it receives, performs the request,
and encrypts the result with K_addr_i
* M receives encrypted responses, and forwards them to the client.
* The client decrypts the encrypted response with k_addr_i
What do you think? What are the costs and benefits of such an approach?
(Note: this will not work if all servers, or a large fraction of them,
are controlled by the same entity that controls M)
Thomas

2023-06-07 15:42:38

- reply

📅 Original date posted:2015-07-21
📝 Original message:Le 20/07/2015 16:40, Mike Hearn a écrit :
>
> If we accept a single payment address i.e. no clever tricks around merge
> avoidance, such a QR code could look like this:
>
> bitcoin:1aBcD1234....?x=serialized_payment_request
>
> However this requires text mode and wastes bytes at the front for the URI
> type.
>
It is possible to be both backward-compatible and to avoid wasting space
in URIs, if we simply assume that the payment request is a single
standard output + amount (that scenario will probably cover 99% of the
cases, and the few other cases may not need QR codes). We generate a
serialized bip70 PR from the parameters found in the URI, sign that
string, and add the signature to the URI.
Example:
bitcoin:1H14AiSc4PqkK9VTmeutZU3edSy3HS5HL8?amount=1&message=here%20is%20a%20test&time=1437489571&exp=604800&name=ecdsa.net&sig=3Quot6m2RsR43NgV8VQQx3Ngf5u8wZY18mu523x3ViLrA3WLwSoQum2Znw3gRsTgfADpHuEiyyjnpxCLKWrkR4RQM
'time' is the timestamp of the request
'exp' is the duration of validity, 1 week here
(it saves a few bits to express it that way)
'name' is the domain name of the signer
'sig' is the signature
The QR code derived from that URI is perfectly scannable with a phone.

2023-06-07 15:42:14

- reply

📅 Original date posted:2015-07-31
📝 Original message:Le 27/07/2015 23:51, Justin Newton via bitcoin-dev a écrit :
> Thomas,
> I think this is interesting and has some good thoughts behind it. For
> clarity, are you recommending that the "_oa2" portion of the domain name be
> "hidden" as a way to make it easier to delegate just wallet names from a
> zone?
>
I don't think you can completely "hide" it, because you need to know
where the _oa2 is in the name, in order to perform requests. In my
proposal it was denoted by a @ character in the alias:
x at y.z -> x._oa2.y.w

2023-06-07 15:42:14

- reply

📅 Original date posted:2015-07-23
📝 Original message:Le 23/07/2015 11:48, Thomas Voegtlin via bitcoin-dev a écrit :
>
> One benefit of having an intermediate "_wallet" level is to allow zone
> delegation. Is that the reason for that choice?
>
Thinking about it, I think that it would be better to separate those two
operations: on one hand, the listing of TXT records under a name, and on
the other hand, the possibility to use Zone Delegation.
For example, let us use the "_oa2" name (Openalias version 2) when we
need to introduce an intermediate level, and "_oa2_keys" for key listing.
Here is an example:
_oa2_keys.sample 3600 IN TXT "btc ltc email fullname"
_btc.sample 3600 IN TXT "bitcoinaddress"
_ltc.sample 3600 IN TXT "litecoinaddress"
_btc.sample 3600 IN TXT "otherbitcoinaddress"
_email.sample 3600 IN TXT "john.smith at googlemail.com"
_fullname.sample 3600 IN TXT "John Smith"
Zone Delegation: Let us assume example.com wants to delegate all its
Bitcoin aliases to Netki. We introduce an intermediate level, with the
"_oa2" name. In the alias, this string is translated as "@"
john._oa2.example.com <-- will be looked up as john at example.com
_btc.john._oa2.example.com <-- bitcoin address of john at example.com

2023-06-07 15:42:13

- reply

📅 Original date posted:2015-07-23
📝 Original message:Le 17/07/2015 03:01, Justin Newton via bitcoin-dev a écrit :
>> 3> We use a 2 tier lookup format. [...]
>>
>> We do the same thing, except in a single call. [...]
>
> We looked at doing this in a single lookup as you did. With one or two
> currencies this can be potentially more efficient. As the number of
> supported currencies and addresses under a single name grows, however, this
> solution becomes potentially more problematic. [...]
Hi Justin,
Your lookup solution is indeed more efficient than OpenAlias, and more
robust to DoS. However, that is not because you use a two-tier lookup.
Indeed, instead of having the following records:
_wallet.sample = "btc ltc"
_btc._wallet.sample = "mybitcoinadress"
you could simply have:
_wallet.sample = "btc ltc"
_btc.sample = "mybitcoinaddress"
In practice, a wallet supporting only Bitcoin will skip the currencies
lookup in both cases, and go directly for the _btc record.
One benefit of having an intermediate "_wallet" level is to allow zone
delegation. Is that the reason for that choice?
Thomas

2023-06-07 15:42:10

- reply

📅 Original date posted:2015-07-20
📝 Original message:Le 19/07/2015 01:01, Justin Newton via bitcoin-dev a écrit :
>>
>> I would rather not make Namecoin part of the standard, because .bit
>> records cannot be verified easily by lightweight/spv wallets; they would
>> need a copy of the Namecoin blockchain for that.
>
> You are the second person to raise this. Clearly this is an item that
> requires some discussion before anything is decided for sure. We had
> gone this direction (and I assume Riccardo did as well) to provide a
> censor resistant option as well as one that would be low cost for
> individuals to be able register their own names. This also allows for
> lookups that never leave the local network. The trade off there for
> mobile wallets was one I feel we failed to properly consider.
>
I think our common goal should be to standardize DNS records holding
Bitcoin addresses, because they are going to be used by both Netki and
Electrum.
You and Ricardo may find it useful to have other types of lookups, such
as Namecoin, and that's fine with me, but I do not want that to slow
down or stall the current standardisation effort, because Namecoin
lookups are clearly not an option for lightweight wallets. That is what
I meant by 'not part of the standard'; let's work on what we have in
common :)

2023-06-07 15:42:09

- reply

📅 Original date posted:2015-07-18
📝 Original message:Le 14/07/2015 19:29, Justin Newton a écrit :
> Hi there. You are correct that we are a company providing a service,
> however, that service is also based on an open standard which we are
> proposing. I'll be honest that we haven't done the greatest job in
> promoting the standard so far. More coming soon on that front. Any
> of the Open Source Wallet Name resolvers that we have created do
> lookups against the standard record formats, and not directly against
> our servers in any way. Information on the record formats as well as
> links to the lookup API server and some early libraries can be found
> here: https://www.netki.com/#/developers and here:
> https://github.com/netkicorp
>
Sorry to answer late, and thanks for the clarification. After talking
with you, I believe that it will not be difficult to agree on a common
standard, that gives maximum freedom to everyone.
I also believe that it is in Netki's interest to convey the message that
they are actively promoting an open standard, and not pushing a private
solution. For this reason, and assuming that the future standard
satisfies you fully, will you mind if that standard carries a neutral
name (such as "OpenAlias v2", or "BIP xx"), instead of being named after
your company? I reckon that is purely a PR issue.
> To break it down briefly, we have an open lookup standard based on
> both the namecoin blockchain as well as traditional DNSSEC. (You can
> choose your own adventure of using namecoin based names or traditional
> ICANN names).
I would rather not make Namecoin part of the standard, because .bit
records cannot be verified easily by lightweight/spv wallets; they would
need a copy of the Namecoin blockchain for that.
> Differences:
>
> 1> We do not use DNSCrypt. I understand why you chose to, but we were
> concerned about broad interoperability and easy broad distribution of
> hosting, so decided not to use it. We have other ways of achieving
> privacy, using HD Wallets and Payment Requests.
>
As far as Electrum is concerned, I do not see DNSCrypt as something
usable in the short term. I do not think it should be mandated, because
there are other ways of achieving privacy, as you say.
> 2> We have the option of storing a URL rather than just a wallet
> address in the TXT record. This allows a second level lookup against
> the URL to get back a unique HD Wallet address or Payment Request each
> time, further protecting user privacy and security. Using Wallet
> Names with Payment Requests allows for the user experience of typing
> in an easy to remember name and getting back the "green lock" and who
> the validated recipient is. This also provides an auto audit of the
> end to end DNS SEC process, in the case the path were somehow
> compromised, the signature on the payment request can provide an
> additional check.
>
I see value in the ability to store differerent types of strings in TXT
records. In particular, I have the need to store an email address, and
more than one Bitcoin address or xpubkey per alias.
> 3> We use a 2 tier lookup format. The first lookup returns a list of
> currencies or payment types supported by the Wallet Name. The second
> lookup goes to a record specific to that currency type to get the
> address to go to. We believe this to be a more scalable solution in a
> world where someone can have both multiple digital currency types, but
> then also multiple types of colored coins, and wants a simple way to
> share a single name for all of those different addresses. This allows
> the wallet to do the work behind the scene of choosing the currency it
> wants to send, and automatically getting back the right address to
> send to, without the user having to do anything different.
>
This seems to be a major difference, and I believe it makes sense to do
it the way you describe. Does that solution fully replace the tags used
in OpenAlias, or does it make sense to combine these two systems?
> 4> We mandate DNSSEC while you make it optional. We did this because
> we believe giving the user the option of NOT using DNSSEC is like
> letting them order a car with no brakes. We weren't sure how we would
> explain to them why their money was gone when they really didn't
> understand the risks they were taking up front. We had a lot of
> discussion about it before coming to the decision we did, and I can
> see why you went the other way, although I do believe we made the
> right choice.
I agree on this; there is no point using OpenAlias without DNSSEC.
Wallets can use fallback servers if the default DNS does not have DNSSEC.
>
>
> Additionally, we just released another open source API server to help
> with the "other half" of the lookup problem. Its in its infancy, and
> we are certainly taking feedback on it at this time. It is called
> Addressimo <https://github.com/netkicorp/addressimo> and will serve
> unique HD Wallet addresses or Payment Requests for every lookup, thus
> allowing a user to have a private, secure way to share a Wallet Name
> that can be used to send them any digital currency.
>
> I'd love to talk here or offline about merging standards going
> forward. As an FYI, Verisign has also delivered a standard to the
> IETF using DNSSEC to pass payment information here:
> https://tools.ietf.org/html/draft-wiley-paymentassoc-00 We have
> started discussions with them about merging standards as well.
>
That is nice, but may be out of scope here. Isn't there a risk that
involving the IETF would make the process a lot slower? Of course it
would be great, but maybe we should try to reach consensus at our level
first (the bitcoin level), before trying to merge with them.
>
> They actually have a really nice way in their standard to encode email
> addresses that more or less ensures that there won't be name space
> collision in the case that there is already a record "joe.user.com"
> and you want to create one for "joe at user.com" that we are looking at
> adding to what we are doing in the next update to our record formats.
>
>
> In any case, I'd much rather we had one effort going forward than
> multiples, so let's talk!
>

2023-06-07 15:42:08

- reply

📅 Original date posted:2015-07-20
📝 Original message:Le 20/07/2015 16:42, Mike Hearn a écrit :
>>
>> In my previous post, I was suggesting to *not* include the proof in the
>> request, because the payer can download it independently. Only the final
>> signature is needed. What makes DNSSEC interesting is not the size of
>> the proof, but rather the fact that you can request it easily, and in a
>> canonical way.
>>
>
> Yes, but you still need the final signature. Is it possible to use an EC
> signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong
> about that, and all you need is 32 bytes, then my argument does not hold.
>
The final signature is a signature of the payment request, it is not
part of DNSSEC. So, yes, that signature can be EC.
The DNSSEC proof is used to verify that the public key, which is
recovered from the signature, corresponds to the alias.
The payment requests I am currently playing with have the following values:
pki_type = "dnssec+btc" (btc means that the signature is checked against
a Bitcoin address stored in DNS)
pki_data = the user's alias (DNS key)

2023-06-07 15:42:08

- reply

📅 Original date posted:2015-07-20
📝 Original message:Le 20/07/2015 17:14, Mike Hearn a écrit :
>
> By "alias" you mean domain name? I'm not sure what DNS key means in this
> context.
>
yes, sorry, I mean the domain name corresponding to the TXT record.
it's called 'alias' in the context of OpenAlias.
> I'm still not really convinced that a domain name under some new roots is
> an identity people will want to use, but yes, I guess your approach would
> work for those who do want it.
What do you mean by "under some new roots" ?
If I believe Netki, there is enough people who want to have a Bitcoin
address stored in DNS, for at least one company to thrive. :)
All I am proposing is a new usage for these already existing DNS
records; not only to receive BTC, but also to sign requests with them.
> It still may be worth exploring the compact cert+optimized BIP70 (no
> DNSSEC) in a qrcode if making a network that stores small bits of data
> really is beyond us :(
>
Heh, pastebin + base64 encoding the PR could work. However, it might
violate their ToS. More seriously, there might be some legal issues for
a company willing to provide that kind of service.
Re QR codes: 150 bytes, using base43 encoding, is not too bad.

2023-06-07 15:42:07

- reply

📅 Original date posted:2015-07-20
📝 Original message:hi Mike,
I hope you had a good trip!
> To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
>
> 1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
> won't fit nicely in a QR code, I think.
>
> 2. 1024 bit is the absolute minimum strength you can get away with,
> really. DNSSEC assumes frequent key rotations to try and help, which
> complicates things.
>
> So I'm not sure using DNSSEC fixes the usability problem we want to fix.
>
In my previous post, I was suggesting to *not* include the proof in the
request, because the payer can download it independently. Only the final
signature is needed. What makes DNSSEC interesting is not the size of
the proof, but rather the fact that you can request it easily, and in a
canonical way.
A typical lightweight payment request, serialized with EC signature and
without the proof, would be about 150 bytes long.
> I will do a separate reply to break out some thoughts on replacing QR codes.
>
> Would it be possible to create the same kind of "lightweight payment
>> requests" using SSL certificates? Probably, if the final signing key is
>> a EC key, and if the payment request does not include the whole chain of
>> certificates.
>
>
> Given that the pre-existing value of the PKI is much lower for individuals
> than for companies/websites, where they all have certs already, building a
> Bitcoin-specific or entirely new/independent PKI for people is not so
> unthinkable, I agree.
>
> In theory such a cert could be as minimal as:
>
> <ECC signature>thomasv at electrum.org
>
> so literally just a signature + a UTF-8 string, and that's it! You don't
> need anything more if you're willing to sacrifice extensibility,
> revocability, etc.
Again, we don't have to sacrifice revocability, if the proof is
downloaded separately.
>
> The pubkey of the CA would be obtained by running the pubkey recovery
> algorithm on the signature, and then checked against a table of trusted
> pubkeys.
>

2023-06-07 15:42:06

- reply

📅 Original date posted:2015-07-19
📝 Original message:Hi Mike,
The reason why I would like to extend BIP70 is because it is currently
not being used in transactions between end-users. BIP70 works very well
in B2C situations, where users buy products from a website. However,
end-users still share Bitcoin addresses.
Before BIP70 was written, I had proposed "Signed URIs", where the
signature is a public proof that a payee requested a payment. This is
one of the main benefits of BIP70, and I still want to bring it to
user-to-user transactions.
I believe one of the main barriers to BIP70 adoption is that bitcoin:
URIs have been extended in a way that requires the request to be hosted
on a webserver. You may complain about the lack of store-and-forward
network, despite the apparent simplicity of creating one such network.
However, that does not mean we should absolutely do things that way and
wait until such a network exists.
Bitcoin addresses do not require a webserver. If we want to build
something that competes with that, we should have at least that level of
convenience.
EC signatures are short, and they can be shared by copy-paste, or added
to a bitcoin: URI. This is a features of my "Signed URIs" proposal, that
was lost in BIP70. Indeed, signed URIs were self-contained. A serialized
payment request can also be made very short, if it is signed by a EC
key, and if it does not include the chain of certificates. Such a
"lightweight request" can be base58-encoded, and easily shared by
copy-paste, or passed in a bitcoin: URI.
Size is another reason why I proposed to use DNSSEC in BIP70 (the first
reason is that the subdomain is signed by the domain, not by an external
CA). Indeed, DNSSEC provides a canonical way to download the chain of
signatures needed to verify a record. Thus, the chain of signatures does
not need to be included in the payment request; it can be downloaded and
archived by the verifier.
Now, I understand that SSL vertificates have distinct advantages over
DNSSEC; for example, CA-signed SSL certificates have a legal value,
which is important for dispute resolution.
Would it be possible to create the same kind of "lightweight payment
requests" using SSL certificates? Probably, if the final signing key is
a EC key, and if the payment request does not include the whole chain of
certificates. (However, that would require an additional infrastructure
to publish the chain of certificates, and I do not think that x509
certification path are unique, which makes things more complicated, but
not impossible).
Sorry if I did not answer point-by-point to your post. I felt that I
failed to explain one of the reasons why I want to use DNSSEC in the
validation of payment requests.
Thomas
Le 14/07/2015 13:45, Mike Hearn a écrit :
> Hi Thomas,
>
> Re: NetKi, I think any proposal in this space has to be an open standard,
> almost by the definition of what it is. At any rate, it may be worth
> talking to them. They have signed up to implement their system at least.
>
> I did understand that your proposal does not rely on email - for instance a
> web forum could issue username at reddit.com type aliases, even if those are
> not also email accounts. I am just continuing the comparison against email
> address certs.
>
> It's also the case that a domain can use the DKIM setup without actually
> offering email accounts. They can just have a web form or API that triggers
> sending of the signed email (or simply, providing the signed headers
> themselves). Thus the same system can be used transparently by both email
> providers and other sites that don't give their users email addresses, but
> would still like to use the same system.
>
> Hardly anyone uses email certificates today, so I don't think it would
>> affect a lot of users.
>
>
> No, but obviously we'd like to change that! The holdup is not the
> certificate side of things, really, but rather the lack of a
> store-and-forward network for signed payment requests. I keep asking
> someone to build one but I fear the problem is almost too simple ......
> everyone who looks at this decides to solve 12 other problems
> simultaneously, it gets complicated, then they never launch :(
>
> Once there's a simple and robust way to get PaymentRequest's from one end
> user to another, even when that first user is offline, then getting an
> email cert issued is no big deal.
>
> That does not look so... not until (1) BIP70 wallets integrate with
>> https://crt.sh, (2) you convince that service to index email certs (3)
>> you convince all CAs to report all email certs they issue to crt.sh.
>>
>
> Any solution that separates identity providers from certificate issuers
> would have these requirements, though. And as many identity providers today
> do not wish to become CAs too, it seems fundamental.
>
> I don't think it's such a problem, mind you. The crt.sh website is actually
> a frontend to the CT protocol, which is a somewhat blockchain like audit
> log that's eventually intended to contain all issued certificates. Right
> now, of course, they focus on SSL certs because those are the most common
> and important. If other kinds of certs became more widely used, support in
> the infrastructure would follow.
>
>
>
> Don't get me wrong - I would like to see a way for a domain to delegate
> BIP70 signing power to a third party. For instance, this would mean payment
> processors like BitPay could sign on the behalf of the merchant, and the
> merchant identity would then show up in wallets. The "chain a cert off a
> domain cert" trick would be a good way to do that, though rather than
> hacking the X.509 stack to validate invalid stuff, at this point it may as
> well be a custom (better) cert format. There's little reason to use X.509
> beyond backwards compatibility.
>
> But the most popular identity providers today either don't care about
> Bitcoin at all, or worse, are developing competitors to it. So for real
> adoption to occur, we must have solutions that do not require identity
> provider cooperation. I realise this is a business reason rather than a
> technical reason, but it's a very strong one - so bootstrapping off
> existing infrastructure with a split CA/ID provider design still makes much
> more sense to me.
>

2023-06-07 15:42:06

- reply

📅 Original date posted:2015-07-14
📝 Original message:Le 14/07/2015 13:19, Milly Bitcoin a écrit :
>
>> If your email account is hacked and someone else gets a certificate in
>> your name, you'd be unable to *know* about it, because they would use a
>> different CA.
>
> Maybe I am confused but I thought you are using DNSSEC to sign the zones
> so only the domain owner could issue certificates for a zone (or
> corresponding email address). If you have "example.com" the domain
> owner of the domain would sign zone "joe.example.com" which can
> correspond to the "joe at example.com" email address. Under this scenario
> you would only have one CA per domain.
>
One CA per domain is indeed what I want to achieve. The paragraph you
quoted was about the current situation with email certs, where that is
not the case.

2023-06-07 15:42:05

- reply

📅 Original date posted:2015-07-14
📝 Original message:Mike Hearn wrote:
> Hi Thomas,
>
> FYI there is a company called Netki is also working on a kind of DNSSEC
> integration with BIP70,
> there's a thread here about their efforts:
> https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J
Hi Mike,
Thanks! I believe it is better to keep the current discussion on
bitcoin-dev, though.
> If you would like to work on this, perhaps it's worth teaming up with them?
> Obviously they plan to have an open spec and open source implementation.
>
I would love to work with Netki. However, it's not clear to me what they
are selling. OpenAlias is an open standard, not a company. In contrast,
Netki have very long Terms of Service, that do not help understand what
part of their solution is open-source, and what is the product. They
surely know about OpenAlias, it would be nice to hear what they think
about it.
> Now w.r.t. the other things - I think we have discussed this before, but to
> reiterate: the biggest flaw with doing things the way you suggest is that
> in practice, no email provider is going to implement your scheme any time
> soon. Most obviously the big web mail providers won't. Therefore hardly
> anyone will use it.
>
What I propose does not rely on email. Please read again.
I am proposing an alternative way to sign BIP70 requests. This is
independent from the communication channel used to send/receive them.
> Whilst having an extension cannot really hurt, obviously, BIP70 will not be
> amended to reduce the certificate types it allows in favour of a system
> that has a very low chance of mainstream adoption. Restricting options like
> that would just make no sense at all.
>
Hardly anyone uses email certificates today, so I don't think it would
affect a lot of users. In contrast, it would increase the security of
all users who don't use email certs, because they may receive a payment
request signed by an email cert.
> I think your primary concern is that if your email account is hacked,
> someone could get a cert issued in your name, and you'd be unable to revoke
> it?
If your email account is hacked and someone else gets a certificate in
your name, you'd be unable to *know* about it, because they would use a
different CA.
> But that's not quite true. Every CA I know of allows you to revoke a
> certificate that was issued for your email address if you have access to
> that email address. Now, if you don't know that this issuance took place,
> you cannot invoke that procedure of course .... but that's what certificate
> transparency is already working on solving in a scalable manner:
>
> https://crt.sh/
>
> That site doesn't currently index email address certs, but it certainly
> could with minimal extra effort by the creators as they're almost identical
> to domain name certs.
>
> So the existing infrastructure seems to have everything in place to solve
> that issue.
That does not look so... not until (1) BIP70 wallets integrate with
https://crt.sh, (2) you convince that service to index email certs (3)
you convince all CAs to report all email certs they issue to crt.sh.
Good luck with that!
> Now, if you still want a mechanism that eliminates the CA entirely, I think
> there's a better approach which is backwards compatible with existing email
> providers. It works like this: [...]
Again, that olution is for email only. We both agree that this is
solving yesterdays problems, so there's no need to discuss that.

2023-06-07 15:42:05

- reply

📅 Original date posted:2015-07-13
📝 Original message:Dear Bitcoin developers,
I would like to propose an extension of the signature scheme used in
the Payment Protocol (BIP70), in order to authorize payment requests
signed by user at domain aliases, where the alias is verified using
DNSSEC (OpenAlias).
Note that the Payment Protocol already includes the possibility to
sign requests with user at domain aliases, using so-called "SSL email
certificates". Email certificates do not require ownership of a domain
name. They are usually delivered by a trusted CA, to the owner of an
email address.
So, why extend BIP70? Well, I believe that SSL email certificates, as
they exist today, are not well suited for payment requests. The core
issue is that email certificates are not delivered by the entity that
owns the same domain. This has the following implications:
1. No cross-verification. Two different CAs may deliver certificates
for the same email address. Thus, if a user's mailbox is
compromised, the hacker can obtain a new certificate for the
compromised email address, from another CA, and sign payment
requests with it. OTOH, if the certificate was delivered by the
same entity, they could require revokation of the existing
certificate before issuing a new one. Revocation of a certificate
would require signing a challenge with the corresponding private
key.
2. Dilution of responsibilities. Three parties are involved in the
security of an email certificate: the owner of the email address,
the CA who signs the certificate, and the owner of the domain
hosting the email service. If something goes wrong and a user
claims that a payment request was not signed by them, it is not
possible to determine who is to blame: the user, the domain owner
or the CA? Any of these parties could have obtained or issued a new
certificate. OTOH, if the alias "user at domain" was issued by
"domain", we would have clear semantics and clear
responsibilities. Instead of involving three parties, as in "User X
hosted at domain Y was verified by trusted authority Z who is not
shown in the alias", the alias only involves two parties: "user X
was verified by domain Y". If domain Y misbehaves and issues a
second certificate for user X, while the first certificate is still
valid, then the first certificate can serve as a public proof that
they misbehaved.
3. Lowest common denominator: email is only a communication channel,
used for authentication by some CAs. Other CAs may decide to use
other, possibly better, identity verification procedures. However,
because of the absence of cross verification, the security of the
whole scheme will always be the security of an email address,
because it remains the method used by less regarding CAs.
In fact, these issues are so bad that I believe BIP70 should be
amended to reject email certificates.
These issues would be solved, if we could enforce that the user at domain
certificate was delivered by the same entity that controls the domain.
How can we do that? Clearly, we need to change the certificate chain
validation procedure. I see two methods to achieve this:
1. Keep using TLS and change the certificate chain validation.
2. Use DNSSEC and Openalias.
Method 1: Modified chain validation.
------------------------------------
This introduces a new type of user certificate, where:
- The commonName is a user at domain alias.
- The certificate for user at domain must be issued by a domain
certificate for the same domain (with some rules to allow
wildcards).
- Validation of the user at domain certificate does not require the
issuer certificate to have a CA bit.
This solution would probably be the easiest to deploy, because it uses
TLS certificate chain validation, which is already available in BIP70
compatible wallets. However, it will break compatibility with the
existing certificate validation procedures.
Method 2: DNSSEC and OpenAlias.
-------------------------------
OpenAlias (http://openalias.org) is a standard for storing Bitcoin
addresses and public keys in DNS TXT records. DNSSEC chain validation
imposes that a record is signed by its parent.
In order to use DNSSEC with BIP70, we may add a new pki_type to BIP70
payment requests (let me call it 'dnssec+btc'), that indicates that
the request has been signed with a Bitcoin public key, and that the
chain validation uses DNSSEC. The chain of signatures may be included
in the payment request.
This solution has my preference. It has been implemented in Electrum
and will be available in version 2.4.
Please let me know what you think. Standardizing that proposal will
probably require a new BIP number, because BIP70 is already final. I
am willing to help doing that. OpenAlias developers have also expressed
their support, and are willing to provide assistance.

2023-06-07 15:34:52

- reply

📅 Original date posted:2015-05-13
📝 Original message:Le 12/05/2015 18:10, Gavin Andresen a écrit :
> Added back the list, I didn't mean to reply privately:
>
> Fair enough, I'll try to find time in the next month or three to write up
> four plausible future scenarios for how mining incentives might work:
>
> 1) Fee-supported with very large blocks containing lots of tiny-fee
> transactions
> 2) Proof-of-idle supported (I wish Tadge Dryja would publish his
> proof-of-idle idea....)
> 3) Fees purely as transaction-spam-prevention measure, chain security via
> alternative consensus algorithm (in this scenario there is very little
> mining).
> 4) Fee supported with small blocks containing high-fee transactions moving
> coins to/from sidechains.
>
> Would that be helpful, or do you have some reason for thinking that we
> should pick just one and focus all of our efforts on making that one
> scenario happen?
>
> I always think it is better, when possible, not to "bet on one horse."
>
Sorry if I did not make myself clear. It is not about betting on one
single horse, or about making one particular scenario happen. It is not
about predicting whether something else will replace PoW in the future,
and I am in no way asking you to focus your efforts in one particular
direction at the expenses of others. Various directions will be explored
by various people, and that's great.
I am talking about what we know today. I would like an answer to the
following question: Do we have a reason to believe that Bitcoin can work
in the long run, without involving technologies that have not been
invented yet? Is there a single scenario that we know could work?
Exotic and unproven technologies are not an answer to that question. The
reference scenario should be as boring as possible, and as verifiable as
possible. I am not asking what you think is the most likely to happen,
but what is the most likely to work, given the knowledge we have today.
If I was asking: "Can we send humans to the moon by 2100?", I guess your
answer would be: "Yes we can, because it has been done in the past with
chemical rockets, and we know how to build them". You would probably not
use a space elevator in your answer.
The reason I am asking that is, there seems to be no consensus among
core developers on how Bitcoin can work without miner subsidy. How it
*will* work is another question.

2023-06-07 15:34:49

- reply

📅 Original date posted:2015-05-26
📝 Original message:Hello Mike,
>
> Are you aware of my proposal for network assurance contracts?
>
Yes I am aware of that; sorry for not mentioning it. I think it is an
interesting proposal, but I would not rely on it today, because it
includes a large share of unproven social experiment.
(Bitcoin too is a social experiment, but so far it has been working)
> But I agree with Gavin that attempting to plan for 20 years from now is
> ambitious at best. Bitcoin might not even exist 20 years from now, or might
> be an abandoned backwater a la USENET.
I agree with that, but I don't think it can be used as a way to justify
how decisions are made today.
The opposition to block size increase comes from two things:
(1) The perceived risk of increased centralization.
(2) Long-term considerations on the need for fee pressure.
I believe you and Gavin have properly addressed (1). Concerning (2), I
think the belief that miners can eventually be funded by a fee market is
wishful thinking. Thus, I am not against the proposed block size increase.
However, the issue of long-term mining incentives remains. So far, the
only proven method to incentivize mining has been direct block reward.
The easiest solution to ensure long-term viability of Bitcoin would be
to put an end to the original block halving schedule, and to keep the
block reward constant (this is what Monero does, btw). That solution is
inflationary, but in practice, users happen to lose private keys all the
time. The rate of coins loss would eventually converge to whatever rate
of emission is chosen, because the care people take of their coins
depends on their value.
Another solution, that does not break Bitcoin's social contract, would
be to keep the original block halving schedule, but to allow miners to
also redeem lost coins (defined as: coins that have not moved for a
fixed number of years. Some time averaging of the lost coins may be
needed in order to prevent non-productive miner strategies). That
solution would create less uncertainty on the actual money supply, and
better acceptability.
I do not expect such a solution to be adopted before miner incentives
become a problem. Neither am I attempting to predict the future; a
completely different solution might be found before the problem arises,
or Bitcoin might stop to exist for some other reason.
However, if I had to decide today, I would choose such a solution,
instead of relying on completely unproven mechanisms.
More important, since we need to decide about block size today, I want
to make it clear that my support is motivated by that long-term
possibility. I believe that the "we will need fee pressure" argument can
reasonably be dismissed, not because we don't know how Bitcoin will work
in 20 years, but because we know how it works today, and it is not
thanks to fee pressure.
Thomas

2023-06-07 15:34:45

- reply

📅 Original date posted:2015-05-12
📝 Original message:Thank you for your answer.
I agree that a lot of things will change, and I am not asking for a
prediction of technological developments; prediction is certainly
impossible. What I would like to have is some sort of reference scenario
for the future of Bitcoin. Something a bit like the Standard Model in
Physics. The reference scenario should not be a prediction of the
future, that's not the point. In fact, it will have to be updated
everytime technological evolutions or code changes render it obsolete.
However, the reference scenario should be a workable path through the
future, using today's technologies and today's knowlegde, and including
all planned code changes. It should be, as much as possible, amenable to
quantitative analysis. It could be used to justify controversial
decisions such as a hard fork.
Your proposal of a block size increase would be much stronger if it came
with such a scenario. It would show that you know where you are going.
Le 11/05/2015 19:29, Gavin Andresen a écrit :
> I think long-term the chain will not be secured purely by proof-of-work. I
> think when the Bitcoin network was tiny running solely on people's home
> computers proof-of-work was the right way to secure the chain, and the only
> fair way to both secure the chain and distribute the coins.
>
> See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
> half-baked thoughts along those lines. I don't think proof-of-work is the
> last word in distributed consensus (I also don't think any alternatives are
> anywhere near ready to deploy, but they might be in ten years).
>
> I also think it is premature to worry about what will happen in twenty or
> thirty years when the block subsidy is insignificant. A lot will happen in
> the next twenty years. I could spin a vision of what will secure the chain
> in twenty years, but I'd put a low probability on that vision actually
> turning out to be correct.
>
> That is why I keep saying Bitcoin is an experiment. But I also believe that
> the incentives are correct, and there are a lot of very motivated, smart,
> hard-working people who will make it work. When you're talking about trying
> to predict what will happen decades from now, I think that is the best you
> can (honestly) do.
>

2023-06-07 15:34:44

- reply

📅 Original date posted:2015-05-11
📝 Original message:The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep mining to protect the network. Such a steady
state regime does not exist today, because miners get most of their
reward from the block subsidy, which will progressively be removed.
Thus, today's 3 billion USD question is the following: Will a steady
state regime be reached in the future? Can such a regime exist? What are
the necessary conditions for its existence?
Satoshi's paper suggests that this may be achieved through miner fees.
Quite a few people seem to take this for granted, and are working to
make it happen (developing cpfp and replace-by-fee). This explains part
of the opposition to raising the block size limit; some people would
like to see some fee pressure building up first, in order to get closer
to a regime where miners are incentivised by transaction fees instead of
block subsidy. Indeed, the emergence of a working fee market would be
extremely reassuring for the long-term viability of bitcoin. So, the
thinking goes, by raising the block size limit, we would be postponing a
crucial reality check. We would be buying time, at the expenses of
Bitcoin's decentralization.
OTOH, proponents of a block size increase have a very good point: if the
block size is not raised soon, Bitcoin is going to enter a new, unknown
and potentially harmful regime. In the current regime, almost all
transaction get confirmed quickly, and fee pressure does not exist. Mike
Hearn suggested that, when blocks reach full capacity and users start to
experience confirmation delays and confirmation uncertainty, users will
simply go away and stop using Bitcoin. To me, that outcome sounds very
plausible indeed. Thus, proponents of the block size increase are
conservative; they are trying to preserve the current regime, which is
known to work, instead of letting the network enter uncharted territory.
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
OTOH, I also fail to see evidence that a limited block capacity will
lead to a functional fee market, able to sustain a steady state. A
functional market requires well-informed participants who make rational
choices and accept the outcomes of their choices. That is not the case
today, and to believe that it will magically happen because blocks start
to reach full capacity sounds a lot like like wishful thinking.
So here is my question, to both proponents and opponents of a block size
increase: What steady-state regime do you envision for Bitcoin, and what
is is your plan to get there? More specifically, how will the
steady-state regime look like? Will users experience fee pressure and
delays, or will it look more like a scaled up version of what we enjoy
today? Should fee pressure be increased jointly with subsidy decrease,
or as soon as possible, or never? What incentives will exist for miners
once the subsidy is gone? Will miners have an incentive to permanently
fork off the last block and capture its fees? Do you expect Bitcoin to
work because miners are altruistic/selfish/honest/caring?
A clear vision would be welcome.

2023-06-07 15:34:10

- reply

📅 Original date posted:2015-05-28
📝 Original message:Le 28/05/2015 17:53, Gavin Andresen a écrit :
>
> So my straw-man proposal would be: max size 2x average size over last 144
> blocks, calculated at every block.
>
I like that idea.
Average is a better choice than median. The median is not well defined
on discrete sets, as shown in your example, and there is no need to be
robust to outliers, thanks to the max size.

2023-06-07 15:34:03

- reply

📅 Original date posted:2015-05-10
📝 Original message:Le 11/05/2015 00:31, Mark Friedenbach a écrit :
> I'm on my phone today so I'm somewhat constrained in my reply, but the key
> takeaway is that the proposal is a mechanism for miners to trade subsidy
> for the increased fees of a larger block. Necessarily it only makes sense
> to do so when the marginal fee per KB exceeds the subsidy fee per KB. It
> correspondingly makes sense to use a smaller block size if fees are less
> than subsidy, but note that fees are not uniform and as the block shrinks
> the marginal fee rate goes up..
>
Oh I see, you expect the sign of the dE/dx to change depending on
whether fees exceed the subsidy. This is possible, but instead of the
linear identity, you have to increase the block size twice as fast as
the difficulty. In that case we would get (using the notations of my
previous email):
D' = D(1+x)
F' = F(1+2x)
and thus:
E' - E = x/(1+x)P(F-S)
The presence of the (F-S) factor means that the sign reversal occurs
when fees exceed subsidy.
> Limits on both the relative and absolute amount a miner can trade subsidy
> for block size prevent incentive edge cases as well as prevent a sharp
> shock to the current fee-poor economy (by disallowing adjustment below 1MB).
>
> Also the identity transform was used only for didactic purposes. I fully
> expect there to be other, more interesting functions to use.

2023-06-07 15:34:03

- reply

📅 Original date posted:2015-05-10
📝 Original message:Le 08/05/2015 22:33, Mark Friedenbach a écrit :
> * For each block, the miner is allowed to select a different difficulty
> (nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
> and this miner-selected difficulty is used for the proof of work check. In
> addition to adjusting the hashcash target, selecting a different difficulty
> also raises or lowers the maximum block size for that block by a function
> of the difference in difficulty. So increasing the difficulty of the block
> by an additional 25% raises the block limit for that block from 100% of the
> current limit to 125%, and lowering the difficulty by 10% would also lower
> the maximum block size for that block from 100% to 90% of the current
> limit. For simplicity I will assume a linear identity transform as the
> function, but a quadratic or other function with compounding marginal cost
> may be preferred.
>
Sorry but I fail to see how a linear identity transform between block
size and difficulty would work.
The miner's reward for finding a block is the sum of subsidy and fees:
R = S + F
The probability that the miner will find a block over a time interval is
inversely proportional to the difficulty D:
P = K / D
where K is a constant that depends on the miner's hashrate. The expected
reward of the miner is:
E = P * R
Consider that the miner chooses a new difficulty:
D' = D(1 + x).
With a linear identity transform between block size and difficulty, the
miner will be allowed to collect fees from a block of size: S'=S(1+x)
In the best case, collected will be proportional to block size:
F' = F(1+x)
Thus we get:
E' = P' * R' = K/(D(1+x)) * (S + F(1+x))
E' = E - x/(1+x) * S * K / D
So with this linear identity transform, increasing block size never
increases the miners gain. As long as the subsidy exists, the best
strategy for miners is to reduce block size (i.e. to choose x<0).

2023-06-07 15:31:26

- reply

📅 Original date posted:2015-03-12
📝 Original message:Hi Andreas,
I don't think it's a problem that BIP43 is tied to BIP32.
What I don't like is that you have to explore branches of the derivation
tree, in order to know if there is a wallet. As a result, it is not
possible for the software to give a negative answer, like "this wallet
is empty", because you do not know if you have explored all the possible
derivations; a new one may have been added after the software was written.
With a version number, you can answer "sorry this seed is not recognized
by me", and you do not need to be online to do that.
If you are online, you can answer "this wallet is empty" after exploring it.
Le 11/03/2015 16:31, Andreas Schildbach a écrit :
> Thanks Thomas, for sharing your experience!
>
> I'd like know why you think it's a problem that BIP43 is tied to BIP32?
> I understand we all agreed at least on the BIP32-derivation spec
> (excluding the BIP32-hierarchy spec)?
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

2023-06-07 15:31:25

- reply

📅 Original date posted:2015-03-11
📝 Original message:Thanks Mike, and sorry to answer a bit late; it has been a busy couple
of weeks.
You are correct, a BIP39 seed phrase will not work in Electrum, and vice
versa. It is indeed unfortunate. However, I believe BIP39 should not be
followed, because it reproduces two mistakes I did when I designed the
older Electrum seed system. Let me explain.
The first problem I have with BIP39 is that the seed phrase does not
include a version number.
Wallet development is still in an exploratory phase, and we should
expect even more innovation in this domain. In this context, it is
unwise to make decisions that prevent future innovation.
However, when we give a seed phrase to users, we have a moral obligation
to keep supporting this seed phrase in future versions. We cannot simply
announce to Electrum users that their old seed phrase is not supported
anymore, because we created a new version of the software that uses a
different derivation. This could lead to financial losses for users who
are unaware of these technicalities. Well, at least, that is how I feel
about it.
BIP39 and Electrum v2 have a very different ways of handling future
innovation. Electrum v2 seed phrases include an explicit version number,
that indicates how the wallet addresses should be derived. In contrast,
BIP39 seed phrases do not include a version number at all. BIP39 is
meant to be combined with BIP43, which stipulates that the wallet
structure should depend on the BIP32 derivation path used for the wallet
(although BIP43 is not followed by all BIP39 compatible wallets). Thus,
innovation in BIP43 is allowed only within the framework of BIP32. In
addition, having to explore the branches of the BIP32 tree in order to
determine the type of wallet attached to a seed might be somewhat
inefficient.
The second problem I see with BIP39 is that it requires a fixed
wordlist. Of course, this forbids innovation in the wordlist itself, but
that's not the main problem. When you write a new standard, it is
important to keep this standard minimal, given the goal you want to
achieve. I believe BIP39 could (and should) have been written without
including the wordlist in the standard.
There are two ways to derive a master key from a mnemonic phrase:
1. A bidirectional mapping between words and numbers, as in old
Electrum versions. Pros: bidirectional means that you can do Shamir
secret sharing of your seed. Cons: It requires a fixed wordlist.
2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
required. Cons: the mapping isn't bidirectional.
Electrum v1 uses (1). Electrum v2 uses (2).
Early versions of BIP39 used (1), and later they switched to (2).
However, BIP39 uses (2) only in order to derive the wallet keys, not for
its checksum. The BIP39 checksum uses (1), and it does requires a fixed
wordlist. This is just plainly inconsistent. As a result, you have
neither wordlist flexibility, nor Shamir secret sharing.
Having a fixed wordlist is very unfortunate. First, it means that BIP39
will probably never leave the 'draft' stage, until all languages of the
world have been added. Second, once you add a wordlist for a new
language, you cannot change it anymore, because it will break existing
seed phrases; therefore you have to be extremely careful in the way you
design these wordlists. Third, languages often have words in common.
When you add a new language to the list, you should not use words
already used by existing wordlists, in order to ensure that the language
can be detected. It leads to a first come first served situation, that
might not be sustainable in the future.
In order to support the old Electrum v1 seeds, all future versions of
Electrum will have to include the old wordlist. In addition, when
generating new seed phrases, Electrum now has to avoid collisions with
old seed phrases, because the old ones did not have a version number.
This is painful enough, I will not repeat the same errors twice.
Electrum v2 derives both its private keys and its checksum/version
number using a hash of the seed phrase. This means that wordlists can be
added and modified in the future, without breaking existing seed
phrases. It also means that it will be very easy for other wallets to
support Electrum seedphrases: it requires about 20 lines of code, and no
wordlist is required.
Thomas
Le 02/03/2015 16:37, Mike Hearn a écrit :
> Congrats Thomas! Glad to see Electrum 2 finally launch.
>
>
>> * New seed derivation method (not compatible with BIP39).
>
>
> Does this mean a "12 words" wallet created by Electrum won't work if
> imported into some other wallet that supports BIP39? Vice versa? This seems
> unfortunate. I guess if seeds are being represented with 12 words
> consistently, people will expect them to work everywhere.
>

2023-06-07 15:31:24

- reply

📅 Original date posted:2015-03-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Bitcoin devs,
I just tagged version 2.0 of Electrum:
https://github.com/spesmilo/electrum/tree/2.0
The electrum.org website will be updated later today. The release
notes are a bit dense, due to the large amount of changes and new
features in this release. In the coming weeks we will be adding more
detailed documentation to the wiki and to the website.
There has been a very long hiatus in Electrum releases, because it
took me a lot of time to decide about the new seed derivation method
and wallet structure. Now that this part is done, I hope that we will
resume to a faster release pace.
I would like to thank all the people who contributed to this release,
developers, beta testers, but also people from this list who provided
useful feedback.
Cheers,
Thomas
_____________________________
RELEASE-NOTES
# Release 2.0
* Before you upgrade, make sure you have saved your wallet seed on
paper.
* Documentation is now hosted on a wiki: http://electrum.orain.org
* New seed derivation method (not compatible with BIP39). The seed
phrase includes a version number, that refers to the wallet
structure. The version number also serves as a checksum, and it
will prevent the import of seeds from incompatible wallets. Old
Electrum seeds are still supported.
* New address derivation (BIP32). Standard wallets are single account
and use a gap limit of 20.
* Support for Multisig wallets using parallel BIP32 derivations and
P2SH addresses ("2 of 2", "2 of 3").
* Compact serialization format for unsigned or partially signed
transactions, that includes the BIP32 master public key and
derivation needed to sign inputs. Serialized transactions can be
sent to cosigners or to cold storage using QR codes (using Andreas
Schildbach's base 43 idea).
* Support for BIP70 payment requests:
- - Verification of the chain of signatures uses tlslite.
- - In the GUI, payment requests are shown in the 'Invoices' tab.
* Support for hardware wallets: Trezor (Satoshilabs) and Btchip (Ledger).
* Two-factor authentication service by TrustedCoin. This service uses
"2 of 3" multisig wallets and Google Authenticator. Note that
wallets protected by this service can be deterministically restored
from seed, without Trustedcoin's server.
* Cosigner Pool plugin: encrypted communication channel for multisig
wallets, to send and receive partially signed transactions.
* Audio Modem plugin: send and receive transactions by sound.
* OpenAlias plugin: send bitcoins to aliases verified using DNSSEC.
* New 'Receive' tab in the GUI:
- - create and manage payment requests, with QR Codes
- - the former 'Receive' tab was renamed to 'Addresses'
- - the former Point of Sale plugin is replaced by a resizeable
window that pops up if you click on the QR code
* The 'Send' tab in the Qt GUI supports transactions with multiple
outputs, and raw hexadecimal scripts.
* The GUI can connect to the Electrum daemon: "electrum -d" will
start the daemon if it is not already running, and the GUI will
connect to it. The daemon can serve several clients. It times out
if no client uses if for more than 5 minutes.
* The install wizard can be used to import addresses or private
keys. A watching-only wallet is created by entering a list of
addresses in the wizard dialog.
* New file format: Wallets files are saved as JSON. Note that new
wallet files cannot be read by older versions of Electrum. Old
wallet files will be converted to the new format; this operation
may take some time, because public keys will be derived for each
address of your wallet.
* The client accepts servers with a CA-signed SSL certificate.
* ECIES encrypt/decrypt methods, availabe in the GUI and using
the command line:
encrypt <pubkey> <message>
decrypt <pubkey> <message>
* The Android GUI has received various updates and it is much more
stable. Another script was added to Android, called Authenticator,
that works completely offline: it reads an unsigned transaction
shown as QR code, signs it and shows the result as a QR code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJU8y7fAAoJECvVgkt/lHDm78oP/2uIqCyOwLsAJGkAI3CPFxtw
WssFJlnCnFiA4tPv5pd7HdOgxQkTaPbUHftexfdd/lpfmFvxZVoHcA/32IIKFH63
BU2bnEyYOaW1A4XfNDQH6VG7eT2er1HOlHCtIgzRl0KJNmVggU6DnXnHkUs1PVvg
pyEIR7Xv3GiK7rcS4qCS/9COroqQGFOXJAiLnOaQP5KszT1bMUdoL7mBPTfavnla
LM+2MgKJOWv+JpHQCDp3XwAXX62LLsS2BjdK1Jt6OpGA6IuVQGBSaTIn5K81S+Yh
M6RDKbP3kObYQ+bzLvtWrzgUD3sdht/V8L5ZPS3+Jibvmhae2zRrm/YpJZ77Yjd4
7QliCFGH0+Gwle72yOempFGWULwq7p6yo4dVZXpj1G3XmbZXuvFg4jYeC/usCx+T
kQgMBPWME2m80fCzhJew1pRChSs/lzVreB0Lh6Tm/5Pibmy721J4oUr6oLkaR9Uy
NMrYqnSy0+tCEOXHrpCYhqogyzzdjOlv0gWKqB2uSkO5TkEHv2eyHeiZttAn11qO
sb85q/k0kYQBZZEvKJ9022eyKHjejDhQjKsCVIHhb81BJ1QYnZFIxBiKkVMxf0u5
sT2TTi18eOrYCUGD2WJ+ALyI1zN1sHO0/sn5+XzlC0jg+1KUXoo0j8NYnzmHb0Yx
5lbdlcaw0Uo7iWkFdMYT
=IGGP
-----END PGP SIGNATURE-----

2023-06-07 15:23:12

- reply

📅 Original date posted:2014-06-24
📝 Original message:Le 24/06/2014 11:44, Wladimir a écrit :
>> But IMO this is a passed stage. SPV wallets w/ Bloom filtering can
>> work without any special servers, so why require a 'close binding' to
>> a trusted bitcoin core?
>
> To clarify (and not piss off ThomasV :-): I do not think the idea of
> having servers with a reputation of their own is a passed stage. There
> are many things that cannot be done at SPV level security with just
> the P2P protocol yet. So having fewer but more trusted Electrum
> servers is a reasonable compromise.
>
Thanks for that :)
Note that my goal is to make the Electrum servers as trustless as
possible, and not to rely on some sort of 'reputation'.
Thomas

2023-06-07 15:20:20

- reply

📅 Original date posted:2014-04-26
📝 Original message:Le 26/04/2014 11:43, Mike Hearn a écrit :
> I'm not sure I understand why you need any special structure for this at
> all. The way I'd do it is just use regular HD wallets for everyone, of the
> regular form, and then swap the watching keys. Why do people need to be
> given a cosigner index at all, given that they all have unique root keys
> anyway?
>
>
I agree with that.
Perhaps the only thing that needs to be standardized is the order of
public keys in the redeem script: I think they should be sorted, so that
the p2sh address does not depend on the order of pubkeys.

2023-06-07 15:20:06

- reply

📅 Original date posted:2014-04-26
📝 Original message:I totally agree with gmaxwell here. The cost of interoperability is too
high. It would force us to freeze all features, and to require a broad
consensus everytime we want to add something new.
In addition, some partial level of compatibility would probably lead to
users not able to recover all their funds when they enter their seed in
another wallet. That is not acceptable, and should be avoided.
Le 25/04/2014 17:46, Gregory Maxwell a écrit :
>
> I don't believe that wallet interoperability at this level is possible
> in general except as an explicit compatibility feature. I also don't
> believe that it is a huge loss that it is so.
>
> The structure of the derivation defines and constrains functionality.
> You cannot be structure compatible unless you have the same features
> and behavior with respect to key management. To that extent that
> wallets have the same features, I agree its better if they are
> compatible— but unless they are dead software they likely won't keep
> the same features for long.
>
> Even if their key management were compatible there are many other
> things that go into making a wallet portable between systems; the
> handling of private keys is just one part: a complete wallet will
> have other (again, functionality specific) metadata.
>
> I agree that it would be it would be possible to support a
> compatibility mode where a wallet has just a subset of features which
> works when loaded into different systems, but I'm somewhat doubtful
> that it would be widely used. The decision to use that mode comes at
> the wrong time— when you start, not when you need the features you
> chose to disable or when you want to switch programs. But the obvious
> thing to do there is to just specify that a linear chain with no
> further branching is that mode: then that will be the same mode you
> use when someone gives you a master public key and asks you to use it
> for reoccurring changes— so at least the software will get used.
>
> Compatibility for something like a recovery tool is another matter,
> and BIP32 probably defines enough there that with a bit of extra data
> about how the real wallet worked that recovery can be successful.
>
> Calling it "vendor lock in" sounds overblown to me. If someone wants
> to change wallets they can transfer the funds— manual handling of
> private keys is seldom advisable, and as is they're going to lose
> their metadata in any case. No one expects to switch banks and to
> keep their account records at the new bank. And while less than
> perfect, the price of heavily constraining functionality in order to
> get another result is just too high.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:18:54

- reply

📅 Original date posted:2014-04-21
📝 Original message:Let me make a sacrilegious proposal: keep using the name "bitcoin", and
shift the decimal point.
There would be a short adaption period, where people will need to talk
about "new bitcoins" and "old bitcoins" in order to disambiguate them.
However, Bitcoin users are techies, so I don't think that the ambiguity
will be a big issue. I don't think lots of people will mistakenly send
1000 times more than the amount they intended.
The name "bitcoin" has a huge advantage over any other proposal, because
it is already established. No marketing is needed.
This kind of renaming has already taken place many times in history,
because the currency was debased. Bitcoin would be the first time it
happens in the other direction.

2023-06-07 15:18:10

- reply

📅 Original date posted:2014-04-09
📝 Original message:Le 09/04/2014 17:54, Gregory Maxwell a écrit :
> Sadly today Electrum requires more than a full node, it requires a
> number of large additional indexes over what a full node has and
> pruning is precluded. I don't think that increasing the resource
> utilization of the node is a good way to go there for the purposes
> expressed here. (not that electrum couldn't be used here, but not
> unmodified without the resource usage increasing route)
>
Electrum uses two large indexes:
address -> utxo
(patricia tree, aka "ultimate blockchain compression", see thread
started by Alan Reiner in the bitcointalk forum)
address -> spent history
The first index is not going to grow larger than what bitcoind already
needs to store, because bitcoind will always need to store utxos.
The second index threatens to become large. However, Electrum servers do
not keep the full histories, they prune older entries. Without adapting
Electrum clients, it would even be possible to keep only one bit per
address (to know whether that address has been used or not), and that
information is only used to restore wallets from seed, not during normal
operations.
If the first index (patricia tree) was implemented in bitcoind, that
would obviously be a big relief for electrum servers.
>> and that it might be an easier way to support
>> SPV clients than creating a new API in bitcoind for it since Stratum
>> itself already relies on bitcoind to provide it's services.
>
> Bitcoin's own P2P protocol is already the API for a ordinary SPV
> client. So I don't believe any new API would be require, except
> perhaps for some process management stuff (which also isn't provided
> for Electrum).
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

2023-06-07 15:18:04

- reply

📅 Original date posted:2014-04-24
📝 Original message:Le 24/04/2014 09:10, Pieter Wuille a écrit :
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
>
yes, I saw that.
In particular, bip64 stipulates that the wallet "never mixes coins
across different accounts". This is not what Electrum does currently.
The UI allows you to chose between two modes: activate a single account
(and the wallet will only use UTXOs from that acccount), or activate all
accounts (and spend from all of them simultaneously).
Concerning multisig addresses, I have changed my mind: Electrum will use
parallel BIP32 trees. A wallet will not mix standard and multisig
accounts. I think that is better in terms of UX.
I agree with Mike Hearn's view that wallets with multiple accounts are
probably too difficult to deal with for most users. If a user feels the
need to have different "accounting identities", they will probably
create different wallet files, instead of creating bip32 subwallets.
However, since multiple subwallets have been asked by many users,
Electrum will propose them. But this should not be the default. More
important, multiple accounts should never be required (in my previous
implementation, they were required for multisig, because the wallet was
creating multisig addresses in dedicated multisig accounts)
Thomas

2023-06-07 15:18:04

- reply

📅 Original date posted:2014-04-24
📝 Original message:Le 24/04/2014 09:21, Gregory Maxwell a écrit :
>
> It doesn't appear to me that reoccurring payments, receive accounts,
> multisig addresses, etc can be used with this proposal, but instead
> you must use a different purpose code and another BIP and are not
> compatible with the draft here.
>
> Am I misunderstanding it? Will Electrum be limiting itself in this
> way? I'd consider it a unfortunate loss of functionality if wallets
> couldn't implement reoccurring payment chains without making users
> generate entirely different wallets (which they couldn't share funds
> across) since addresses for recurring payments was one of the main
> motivations in BIP32.
>
>
No, Electrum will not be limiting itself in this way. I believe that we
are only at the beginning of exploring the different possibilities
opened by HD wallets. It will probably take years until we have clear
ideas on what users need, what choices they make, and how to organize
everything. Therefore it is too early to take decisions that might limit
future functionality.
I can see that it is very difficult today to find a consensus on wallet
structure between wallet developers. In addition, I changed my mind
several times on these questions, so I guess I will probably need to
change things again in the future.
This is why I decided to include a version number in Electrum seeds. The
version number will be updated everytime the wallet structure changes. I
know many developers do not follow me on this, but that is something I
am quite sure Electrum needs, despite all the other things I am not sure
about :)
I think it is too early to aim for inter-wallet compatibility today. I
guess we should postpone this goal, and move on with software releases.
As Andreas pointed out, we should just make sure that we do not import
an incompatible seed in another wallet, because not recovering all your
bitcoins would be a terrible user experience; the version number built
in the seed will ensure that for Electrum.

2023-06-07 15:18:03

- reply

📅 Original date posted:2014-04-24
📝 Original message:Le 23/04/2014 21:44, Luke-Jr a écrit :
> On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
>>
>> Examples: Electrum does not want to use accounts [...]
> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
> use accounts, [...]
To clarify:
Electrum plans to have bip32 accounts; Multibit will not, afaik.
I think Pavol just wanted to make an example.

2023-06-07 15:17:51

- reply

📅 Original date posted:2014-04-08
📝 Original message:+1
I would prefer that solution...
Le 08/04/2014 15:53, Pieter Wuille a écrit :
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
> This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>

2023-06-07 15:16:24

- reply

📅 Original date posted:2014-03-27
📝 Original message:>
> Related to this, here is another idea I would like to submit:
>
> Instead of using a "gap limit" (maximal number of consecutive unused
> addresses), I think we should get rid of the topology, and simply count
> the number of unused addresses since the beginning of the sequence.
> Indeed, the topology of the sequence of addresses is of no interest to
> the user. Users often misinterpret "gap limit" as the "number of unused
> addresses available", so I think we should just give them what they want
> :) This is easier to understand, and it makes things more predictable,
> because the wallet will always display the same number of unused
> addresses (except when it is waiting for confirmations).
>
>
> I'm not convinced that it is either simpler to implement nor simpler to
> understand. I considering every "account" as completely independent
> structure (except that it has been derived from master seed). Because of
> this, I don't see a reason why number of generated addresses in one
> account should affect available addresses of other account.
Sorry if I was not clear, but no, I was not proposing that... I propose
to count the number of unused addresses in each account, independently.
Here is an explanation with pictures:
Currently, Electrum does this:
x = used address
o = unused address
x x x o o x x x x o o o o o
| └───────┘ 5 unused addresses at the end (gap limit =5)
existing gap, size 2
Case 1:
Suppose the user decides to use the 4th address starting from the end:
x x x o o x x x x x o o o o
After 3 confirmations, Electrum will create one extra address:
x x x o o x x x x x o o o o o
└───────┘ 5 final address (one new)
Case 2:
The user, who understands nothing about topology, decides to use the
final address:
x x x o o x x x x o o o o x
After 3 confirmations, Electrum will create 5 new addresses:
x x x o o x x x x o o o o x o o o o o
| └───────┘ 5 new addresses
new gap (size 4)
You see that this leads to a number of newly created addresses that
depends on the address picked by the user. This is the behaviour that I
want to fix. I think it is bad for two reasons: First, because it is
unpredictable (I had a user who set his gap limit to 100, and then was
systematically using the last address of the list, ending up with a lot
of wasted addresses). Second, because the worst case scenario (case 2)
creates large gaps, which are less robust to blockchain reorgs than in
case 1. A reorg in case 1, where the last tx is cancelled will create no
gap. A reorg in case 2 can result in a gap that is larger than the limit
(5), if another transaction uses the final addresses. (this is why
Electrum has to wait for a few confirmations before adding addresses)
So, what I propose is to always have a constant number of unused
addresses in each account, instead of something that depends on the
topology. (this number can be 10 or 20, I don't mind, but I guess Mike
might prefer 20...)

2023-06-07 15:16:24

- reply

📅 Original date posted:2014-03-27
📝 Original message:Le 27/03/2014 14:44, Pavol Rusnak a écrit :
> On 03/27/2014 01:06 PM, Thomas Voegtlin wrote:
>> Yes, I was planning to increase the number of available unused addresses
>> to 10 or 20 in the bip32 version of Electrum.
>
> Also, we'd need to specify a "gap limit" for accounts as well. In TREZOR
> we currently use 0, which means that the scan will stop as soon as we
> hit first account with no transaction history (meaning that its first
> X=10 addresses are unused).
>
I agree with that. I was planning to do the same (no gap)
Note: Maybe we could just look at the first address of each account,
instead of the first 10 ?

2023-06-07 15:16:22

- reply

📅 Original date posted:2014-03-27
📝 Original message:Le 27/03/2014 13:49, Mike Hearn a écrit :
> Ah, BIP32 allows for a range of entropy sizes and it so happens that
> they picked 256 bits instead of 128 bits.
>
> I'd have thought that there is a right answer for this. 2^128 should not
> be brute forceable, and longer sizes have a cost in terms of making the
> seeds harder to write down on paper. So should this be a degree of freedom?
>
Here is what I understand:
2^128 iterations is not brute forcable today, and will not be for the
foreseeable future.
An EC pubkey of length n can be forced in approximately 2^(n/2)
iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
are 256 bits, would require 2^128 iterations. This is why unused
addresses (160 bits hash) are better protected than already used ones.
However, people tend to believe that a public key of size n requires 2^n
iterations. This belief might have been spread by this popular image:
https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146

2023-06-07 15:16:21

- reply

📅 Original date posted:2014-03-27
📝 Original message:Le 27/03/2014 12:30, Marek Palatinus a écrit :
> Ah, I forget to two things, which should be into the BIP as well:
>
> a) Gap factor for addresses; as Thomas mentioned, although some software
> can watch almost unlimited amount of unused addresses, this is serious
> concern for lightweight or server-based wallets like Electrum or
> myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
> experience so far) quite sane for most of users.
Yes, I was planning to increase the number of available unused addresses
to 10 or 20 in the bip32 version of Electrum.
Related to this, here is another idea I would like to submit:
Instead of using a "gap limit" (maximal number of consecutive unused
addresses), I think we should get rid of the topology, and simply count
the number of unused addresses since the beginning of the sequence.
Indeed, the topology of the sequence of addresses is of no interest to
the user. Users often misinterpret "gap limit" as the "number of unused
addresses available", so I think we should just give them what they want
:) This is easier to understand, and it makes things more predictable,
because the wallet will always display the same number of unused
addresses (except when it is waiting for confirmations).

2023-06-07 15:16:20

- reply

📅 Original date posted:2014-03-27
📝 Original message:Le 26/03/2014 21:49, Mike Hearn a écrit :
>
> * reserved is for "other stuff". I actually don't recall why we ended
> up with this. It may have been intended to split out multisig
> outputs etc from cointype. Marek, Thomas?
>
yes, this was intended to create multisig addresses from the same seed.
cointype was proposed after that.

2023-06-07 15:16:15

- reply

📅 Original date posted:2014-03-27
📝 Original message:Le 27/03/2014 12:39, Mike Hearn a écrit :
> One issue that I have is bandwidth: Electrum (and mycelium) cannot
> watch as many addresses as they want, because this will create too
> much traffic on the servers. (especially when servers send utxo merkle
> proofs for each address, which is not the case yet, but is planned)
>
>
> This is surprising and the first time I've heard about this. Surely your
> constraint is CPU or disk seeks? Addresses are small, I find it hard to
> believe that clients uploading them is a big drain, and mostly addresses
> that are in the lookahead region won't have any hits and so won't result
> in any downloads?
To be honest, I have not carried out a comprehensive examination of
server performance. What I can see is that Electrum servers are often
slowed down when a wallet with a large number (thousands) of addresses
shows up, and this is caused by disk seeks (especially on my slow VPS).
The master branch of electrum-server is also quite wasteful in terms of
CPU, because it uses client threads. I have another branch that uses a
socket poller, but that branch is not widely deployed yet.
I reckon that I might have been a bit too conservative, in setting the
number of unused receiving addresses watched by Electrum clients (until
now, the default "gap limit" has always been 5). The reason is that, if
I increase that number, then there is no way to go back to a smaller
value, because it needs to be compatible with all previously released
versions. However, Electrum servers performance has improved over time,
so I guess it could safely be raised to 20 (see previous post to slush).
In terms of bandwidth, I am referring to my Android version of Electrum.
When it runs on a 3G connection, it sometimes takes up to 1 minute to
synchronize (with a wallet that has hundreds of addresses). However, I
have not checked if this was caused by addresses or block headers.
>
> This constraint is not so important for bloom-filter clients.
>
>
> Bloom filters are a neat way to encode addresses and keys but they don't
> magically let clients save bandwidth. A smaller filter results in less
> upload bandwidth but more download (from the wallets perspective). So
> I'm worried if you think this will be an issue for your clients: I
> haven't investigated bandwidth usage deeply yet, perhaps I should.
>
> FWIW the current bitcoinj HDW alpha preview pre-gens 100 addresses on
> both receive and change branches. But I'm not sure what the right
> setting is.
Heh, may I suggest 20 in the receive branch?
For the change branch, there is no need to watch a large number of
unused addresses, because the wallet should try to fill all the gaps in
the sequence of change.
(Electrum does that. It also watches 3 unused addresses at the end of
that sequence, in order to cope with possible blockchain reorgs causing
gaps. As an extra safety, it also waits for 3 confirmations before using
a new change address, which sometimes results in address reuse, but I
guess a smarter strategy could avoid that).
>
> We also have to consider latency. The simplest implementation from a
> wallets POV is to step through each transaction in the block chain one
> at a time, and each time you see an address that is yours, calculate the
> next ones in the chain. But that would be fantastically slow, so we must
> instead pre-generate a larger lookahead region and request more data in
> one batch. Then you have to recover if that batch ends up using all the
> pre-genned addresses. It's just painful.
>
> My opinion, as far as Electrum is concerned, is that merchant accounts
> should behave differently from regular user accounts: While merchants
> need to generate an unlimited number of receiving addresses, it is also
> acceptable for them to have a slightly more complex wallet recovery
> procedure
>
>
> Maybe. I dislike any distinction between users and merchants though. I
> don't think it's really safe to assume merchants are more sophisticated
> than end users.
well, it depends what we mean by "merchant". I was thinking more of a
website running a script, rather than a brick and mortar ice cream
seller. :)
>
> but also because we want fully automated synchronization between
> different
> instances of a wallet, using only no other source of information than
> the blockchain.
>
>
> I think such synchronization won't be possible as we keep adding
> features, because the block chain cannot sync all the relevant data. For
> instance Electrum already has a label sync feature. Other wallets need
> to compete with that, somehow, so we need to build a way to do
> cross-device wallet sync with non-chain data.
Oh, I was not referring to label sync, but only to the synchronization
of the list of addresses in the wallet. Label sync is an Electrum plugin
that relies on a centralized server. Using a third party server is
acceptable in that case, IMO, because you will not lose your coins if
the server fails.

2023-06-07 15:16:14

- reply

📅 Original date posted:2014-03-27
📝 Original message:Le 27/03/2014 00:37, Andreas Schildbach a écrit :
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
I believe you have a good point here: we should not advertise wallets as
compatible if they are not 100% compatible.
One issue that I have is bandwidth: Electrum (and mycelium) cannot
watch as many addresses as they want, because this will create too
much traffic on the servers. (especially when servers send utxo merkle
proofs for each address, which is not the case yet, but is planned)
For this reason Electrum imposes a constraint on the number of virgin
addresses provided to the user. Although the current strategy used by
Electrum can certainly be improved, it will not scale up to having every
client watching thousands of addresses.
This constraint is not so important for bloom-filter clients. So I guess
that
it makes sense for Multibit to provide hundreds, or even thousands of
virgin
addresses to the user, regardless of how they are used. Such a wallet will
in general not be recoverable in Electrum, unless the user "helps" the
recovery procedure. (or the seed has metadata telling the software that
this is a Multibit wallet). So we have a problem here, if we advertise
these
wallets as compatible.
My opinion, as far as Electrum is concerned, is that merchant accounts
should behave differently from regular user accounts: While merchants
need to generate an unlimited number of receiving addresses, it is also
acceptable for them to have a slightly more complex wallet recovery
procedure
(for example, the wallet might show an option to "search for more
addresses",
and it might not need to watch "old" addresses anymore)
OTOH, I don't think we can ask regular users to do this, not only
because it
adds complexity to the wallet recovery procedure (which makes it scarier),
but also because we want fully automated synchronization between different
instances of a wallet, using only no other source of information than
the blockchain.
The first versions of Electrum allowed users to set the "gap limit"
parameter
in their GUI preferences, but I removed it from GUI after I realized it
was a bad
idea (users messed with it and did not understand what happened..)
With bloom filter clients I guess the distinction between these two use
cases
is not really necessary, because watching addresses is cheap. So it
would be
good to hear what you and Mike think about this problem. If you decide
to let
the user create hundreds of unused addresses (and I think it perfectly
makes
sense for you), then I guess it would be better for Electrum to give up on
compatibility, rather than running the risk of seeing only a subset of
addresses.
Another option is to handle these seeds as "merchant" accounts.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>> /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>> * cointype: This is zero for Bitcoin. This is here to support two
>> things, one is supporting alt coins based off the same root seed.
>> Right now nobody seemed very bothered about alt coins but sometimes
>> feature requests do come in for this. Arguably there is no need and
>> alt coins could just use the same keys as Bitcoin, but it may help
>> avoid confusion if they don't.
>>
>> More usefully, cointype can distinguish between keys intended for
>> things like multisig outputs, e.g. for watchdog services. This means
>> if your wallet does not know about the extra protocol layers
>> involved in this, it can still import the "raw" money and it will
>> just ignore/not see the keys used in more complex transactions.
>>
>> * reserved is for "other stuff". I actually don't recall why we ended
>> up with this. It may have been intended to split out multisig
>> outputs etc from cointype. Marek, Thomas?
>>
>> * account is for keeping essentially wallets-within-a-wallet to avoid
>> mixing of coins. If you want that.
>>
>> * change is 0 for receiving addresses, 1 for change addresses.
>>
>> * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:48

- reply

📅 Original date posted:2014-03-16
📝 Original message:Thanks again for having a look.
Given these problems, I have decided to remove
the encryption methods from the current release.
I retagged 1.9.8 and updated the packages.
Thomas
Le 16/03/2014 15:39, Gregory Maxwell a écrit :
> On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
>> thanks for your feedback!
>>
>> I was not aware that that implementation was flawed.
>> I will see how I can fix that code and get back to you.
> It also leaks on the order of 7 bits of data about the message per
> message chunk. I'm also think it's likely that there are some
> messages which are just incorrectly decrypted. ... it's really
> screwy and suspect.

2023-06-07 15:15:47

- reply

📅 Original date posted:2014-03-16
📝 Original message:thanks for your feedback!
I was not aware that that implementation was flawed.
I will see how I can fix that code and get back to you.
Thomas
Le 16/03/2014 14:54, Gregory Maxwell a écrit :
> On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
>> The encryption algorithm is ECIES, and code was was borrowed from
>> https://github.com/jackjack-jj/jeeq. In order to know the public
>> key corresponding to a Bitcoin address in your wallet, you can use
>> the 'getpubkeys' command. The 'decrypt' command assumes that the
>> wallet has the private key corresponding to the public key passed as
>> argument.
> The cryptosystem in that repository appears to be insecure in several
> ways and is not actually implementing ECIES.
>
> The most important of which is that instead of using a
> cryptographically strong mac tied to the ephemeral secret it uses a
> trivial 16 bit check value. This means that that I can decode an
> arbitrary message encrypted to a third person if they allow me to make
> no more than 65536 queries to a decryption oracle to decrypt some
> other message.
>
> Also, in the event that a random query to a decryption oracle yields a
> result (1:2^16 times) the result directly reveals the ECDH value
> because it is only additively combined with the message value. If the
> implementation does not check if the nonce point is on the curve (an
> easy implementation mistake) the result can yield a point on the twist
> instead of the curve which is far more vulnerable to recovery of the
> private key. ECIES uses a KDF instead of using the ECDH result
> directly to avoid this.
>
> There may be other problems (or mitigating factors) as it was very
> hard for me to follow what it was actually doing.
>
> (The particular implementation has a number of other issues, like
> apparently not using a cryptographically strong RNG for its EC nonce..
> but I assume you didn't copy that particular flaw)

2023-06-07 15:15:47

- reply

📅 Original date posted:2014-03-16
📝 Original message:I am happy to announce the release of Electrum 1.9.8.
This release includes some features initially planned for version 2.0.
Packages are available on https://electrum.org/download.html (signed by me)
Binaries for windows and mac will be available in the coming days
enjoy
Thomas
-----------------------
RELEASE NOTES
# Release 1.9.8
(This release includes features initially planned for version 2.0)
* Electrum servers were upgraded to version 0.9. The new server stores
a Patrica tree of all UTXOs, an idea proposed by Alan Reiner in the
bitcointalk forum. This property allows the client to directly
request the balance of any address. The new commands are:
1. getaddressbalance <address>
2. getaddressunspent <address>
3. getutxoaddress <txid> <pos>
* In addition, two commands for message encryption were added:
1. encrypt <pubkey> <message>
2. decrypt <pubkey> <message>
The encryption algorithm is ECIES, and code was was borrowed from
https://github.com/jackjack-jj/jeeq. In order to know the public
key corresponding to a Bitcoin address in your wallet, you can use
the 'getpubkeys' command. The 'decrypt' command assumes that the
wallet has the private key corresponding to the public key passed as
argument.
* The encrypt and decrypt functions are available in the Qt GUI (from
the menubar, or right click on one of your addresses if you want to
use its public key).
* Command-line commands that require a connection to the network spawn
a daemon, that remains connected and handles subsequent
commands. The daemon terminates itself if it remains unused for more
than one minute. The purpose of this is to make scripting more
efficient. For example, a bash script using many electrum commands
will open only one connection.

2023-06-07 15:15:07

- reply

📅 Original date posted:2014-03-11
📝 Original message:> Trezor and Electrum may be earlier than this.
Sorry for not joining the discussion earlier.
I have postponed the release of bip32 features in Electrum due to
ongoing discussions with Trezor and bitcoinj developers.
I planned to post a summary in a separate thread, but this info is also
relevant for this thread, so I'm posting here.
(sorry if this is a bit offtopic, though)
I plan to create a 2-factor authentication service that uses p2sh
addresses in Electrum.
All addresses are derived from the wallet root seed, and should be
recoverable from it.
(of course this departs from scenarios where master keys are generated
independently;
my opinion is that both should be possible)
So, when the user activates 2fa protection, the root private key is
deleted from their hard drive, as well as the
master private key of one of the branches used to create p2sh addresses
(which is sent to a remote server).
See this (fairly old) description here for more details:
https://bitcointalk.org/index.php?topic=274182.0
Since I still want to be able to generate 1of1 accounts after the 2fa
protection is activated,
1of 1 accounts should not be generated directly from the root of the tree.
Thus, an extra level must be inserted in the tree.
For example, 1of1 addresses can be derived as follows:
m/reserved'/n'
where n is the account index, and "reserved" is an index that indicates
the type of address.
(0 would be reserved for 1of1 addresses)
slush suggested that another layer of derivation would be useful, in
order to use wallets
with altcoins on the same seed. This lead to this type of derivation:
m/coin'/reserved'/n'
where "coin" would be 0 for Bitcoin, and "reserved" would be 0 for 1of1
addresses
Thomas

2023-06-07 15:12:24

- reply

📅 Original date posted:2014-01-24
📝 Original message:Le 24/01/2014 10:05, Peter Todd a écrit :
> On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote:
>> Hi slush,
>>
>> Thank you for your new proposal; it seems to be a compromise.
>>
>> @Christophe Biocca:
>> If the wordlist becomes part of the standard, then we will run into
>> problems of collisions once users ask for wordlists in every language.
>>
>> IMO the right approach is to implement checksums that do not depend
>> on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod
>> 2^k == 0 )
>> this would also allow us to implement sipa's variable stretching proposal.
>>
>> I understand this is not possible because of the computational
>> requirements of devices such as trezor.
> Is it? Surely the trezor can bruteforce, say, 8 bits == 0. How many
> SHA256/sec can the trezor hardware do? Generating your seed is a
> one-time thing after all - that taking 10-30s doesn't seem like a big
> deal to me.
>
> Even a 1/256th "checksum" will really cut down on the number of mistakes
> made and money lost.
slush, correct me if I'm wrong, but I don't think that's the only reason:
They want to generate a seed by combining entropy from the trezor device
and from the user's computer;
In addition, they want the computer to be able to check that the seed
actually was derived from the entropy it provided, using only a master
public key (the computer does not have access to the seed)
This is why they designed bip39 that way.
I think the new bip39 proposal could be used in Electrum as an option
for trezor, but I am reluctant to make it default, because it imposes
its own dictionary.

2023-06-07 15:12:23

- reply

📅 Original date posted:2014-01-20
📝 Original message:Hi slush,
Thank you for your new proposal; it seems to be a compromise.
@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions once users ask for wordlists in every language.
IMO the right approach is to implement checksums that do not depend
on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod 2^k
== 0 )
this would also allow us to implement sipa's variable stretching proposal.
I understand this is not possible because of the computational
requirements of devices such as trezor.
I am leaning toward considering these devices as a nonstandard case,
instead of enforcing a given wordlist in the standard.
Thomas
Le 21/01/2014 00:18, slush a écrit :
>
> On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca
> <christophe.biocca at gmail.com <mailto:christophe.biocca at gmail.com>> wrote:
>
> I remember the wordlist choice getting bikeshedded to death a
> month ago.
>
> I would just include the wordlist as part of the standard (as a
> recommendation) so that fully compliant implementations can correct a
> user's typos regardless of the original generator.
>
>
> That's exactly our attitude. We realized that have a community-wide
> agreement on the wordlist itself is simply imposible, so to reach at
> least some consensus we split the proposal to two parts - one what is
> essential to call itself a "bip39 compatible", i.e. converting the
> mnemonic to bip32 node and second which is optional, including our
> proposed wordlist, which has some advanced features like checksums
> etc. Now it is up to client developers to decide if they really insist
> on their superior wordlist or if they'll implement checksums following
> the full specification.
>
> Those who don't like it will have to deal with the compatibility
> concerns themselves, or get an alternate wordlist approved as a BIP.
>
> Odds are no one will go that route.
>
> At least Trezor and bitcoinj (Multibit) seems to be going in this way,
> which is 100% of clients which expressed interest in bip39 :-).
>
> slush
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140121/2f2ab616/attachment.html>

2023-06-07 15:11:31

- reply

📅 Original date posted:2014-01-07
📝 Original message:Le 07/01/2014 01:21, Mark Friedenbach a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/06/2014 10:13 AM, Peter Todd wrote:
>> On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
>>> I have written a Python-levelDB implementation of this UTXO
>>> hashtree, which is currently being tested, and will be added to
>>> Electrum servers.
>> Along the lines of my recent post on blockchain data:
>>
>> Is it going to be possible to do partial prefix queries on that
>> tree?
> There's really two tree structures being talked about here. Correct me
> if I'm wrong Thomas, but last time I looked at your code it was still
> implementing a 256-way PATRICIA trie, correct? This structure lends
> itself to indexing either scriptPubKey or H(scriptPubKey) with
> approximately the same performance characteristics, and in the
> "Ultimate blockchain compression" thread there is much debate about
> which to use.
You are right. The 256-way branching follows from the fact that
the tree was implemented using a key-value database operating
with byte strings (leveldb). With this implementation constraint,
a different branching would probably be possible but wasteful.
My recent code creates one leaf per unspent, and uses 56-byte
keys built as:
H(scriptPubKey) + txid + txpos
(This is not pushed yet, it needs cleanup. Previous code created one
leaf per address)
Partial prefix queries are possible with database iterators.
> In the process of experimentation I've since moved from a 256-way
> PATRICIA trie to a bitwise, non-level-compressed trie structure - what
> I call proof-updatable trees in the BIP. These have the advantage of
> allowing stateless application of one proof to another, and as
> consequence enable mining & mempool operations without access to the
> UTXO set, so long as proofs are initially provided in the transaction
> & block wire format.
I see the advantage of doing that, but this looks really far-fetched..
My understanding is that it would require a complete change in the
way clients and miners work. Could such a change be brought iteratively?

2023-06-07 15:11:29

- reply

📅 Original date posted:2014-01-05
📝 Original message:Hello and happy new year to this mailing list!
Thank you Mark for the incredible work you've been doing on this.
I am following this very closely, because it is of primary importance
for Electrum.
I have written a Python-levelDB implementation of this UTXO hashtree,
which is currently being tested, and will be added to Electrum servers.
My implementation follows Alan Reiner's idea to store the tree as items
in a key-value database. I believe that a C++ implementation like yours
will be at least an order of magnitude faster, and I am looking forward
to it.
I too believe that BIPs should define interoperability points, but probably
not implementation details. For the UTXO hashtree, this means that a BIP
should at least specify how the root hash is constructed. This might be the
only thing that needs to be specified.
However, I see no pressing issue with writing a BIP; it might be preferable
to implement and test different options first, and learn from that.
Thomas
Le 20/12/2013 02:47, Mark Friedenbach a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello fellow bitcoin developers. Included below is the first draft of
> a BIP for a new Merkle-compressed data structure. The need for this
> data structure arose out of the misnamed "Ultimate blockchain
> compression" project, but it has since been recognized to have many
> other applications.
>
> In addition to this BIP I am preparing three additional BIPs
> describing the use of this data structure in stateless validation &
> mining, the UBC address index for "SPV+" operating modes, document
> timestamping and merged mining.
>
> A Python implementation of this data structure is available here:
>
> https://github.com/monetizeio/python-bitcoin
>
> A C++ implementation is being worked on.
>
> As per the BIP-1 procedure, I am submitting this rough draft to the
> community for discussion. I welcome all comments and criticisms of
> both form and content.
>
> - -Mark
>
>
> ==Abstract==
>
> This BIP describes a [http://en.wikipedia.org/wiki/Hash_tree Merkle
> hash tree] variant of the [http://en.wikipedia.org/wiki/Trie
> prefix-tree data structure], ideally suited for encoding key-value
> indices which support memory-efficient proofs.
>
> ==Motivation==
>
> There are a number of applications which would benefit from having a
> data structure with the following properties:
>
> * '''Arbitrary mapping of keys to values.''' A ''key'' can be any
> bytestring, and its ''value'' any other bytestring.
> * '''Duplicate keys disallowed.''' Every key has one, and only one
> value associated with it. Some applications demand assurance that no
> key value is reused, and that this constraint can be checked without
> requiring access to the entire data structure.
> * '''Efficient look-up by key.''' The data structure should support
> sub-linear lookup operations with respect to the number of keys in the
> mapping. Logarithmic time or linear with respect to the length of the
> key should be achievable and would be sufficient for realistic
> applications.
> * '''Merkle compression of mapping structure.''' It should be possible
> to produce a reduced description of the tree consisting of a single
> root hash value which is deterministically calculated from the mapping
> structure.
> * '''Efficient proofs of inclusion.''' It should be possible to
> extract a proof of key/value mapping which is limited in size and
> verification time by the length of the key in the worst case.
> * '''Computation of updates using local information.''' Given a set of
> inclusion proofs, it should be possible to calculate adjustments to
> the local mapping structure (update or deletion of included mappings,
> or insertion between two included mappings which are adjacent in the
> global structure).
>
> Such applications include committed validation indices which enable
> stateless mining nodes, committed wallet indices which enable
> trust-less querying of the unspent transaction output set by
> <code>scriptPubKey</code>, efficient document time-stamping, and
> secure & efficient merged mining. This BIP describes an authenticated
> prefix tree which has the above properties, but leaves the myriad
> applications to be formalized in future BIPs.
>
> ==Data structure==
>
> This BIP defines a binary prefix tree. Such a structure provides a
> mapping of bitstrings (the ''keys'') to bytestrings (the ''values'').
> It is an acyclic binary tree which implicitly encodes keys within the
> traversal path -- a "left" branch is a 0, and a "right" branch is a 1.
> Each node is reachable by only one unique path, and reading off the
> branches taken (0 for each left, 1 for each right) as one follows the
> path from root to target yields the node's key.
>
> The particular binary prefix tree defined by this BIP is a hybrid
> PATRICIA / de la Brandais tree structure.
> [http://en.wikipedia.org/wiki/Radix_tree PATRICIA trees] compress a
> long sequence of non-branching nodes into a single interior node with
> a per-branch ''skip prefix''. This achieves significant savings in
> storage space, root hash calculation, and traversal time.
>
> A de la Brandais trie achieves compression by only storing branches
> actually taken in a node. The space savings are minimal for a binary
> tree, but place the serialized size of a non-branching interior node
> under the SHA-256 block size, thereby reducing the number of hash
> operations required to perform updates and validate proofs.
>
> This BIP describes the authenticated prefix tree and its many
> variations in terms of its serialized representation. Additional BIPs
> describe the application of authenticated prefix trees to such
> applications as committed indices, document time-stamping, and merged
> mining.
>
> ==Serialization format==
>
> As a hierarchical structure, the serialization of an entire tree is
> the serialization of its root node. A serialized node is the
> concatenation of five structures:
>
> node := flags || VARCHAR(extra) || value || left || right
>
> The <code>flags</code> is a single byte field whose composite values
> determine the bytes that follow.
>
> flags = (left_flags << 0) |
> (right_flags << 2) |
> (has_value << 4) |
> (prune_left << 5) |
> (prune_right << 6) |
> (prune_value << 7)
>
> The <code>left_flags</code> and <code>right_flags</code> are special
> 2-bit enumeration fields. A value of 0 indicates that the node does
> not branch in this direction, and the corresponding <code>left</code>
> or <code>right</code> branch is missing (replaced with the empty
> string in the node serialization). A value of 1 indicates a single bit
> key prefix for this branch, implicitly 0 for <code>left</code> and 1
> for <code>right</code>. A 2 indicates up to 7 bits of additional skip
> prefix (beyond the implicit first bit, making 8 bits total) are stored
> in a compact single-byte format. A 3 indicates a skip prefix with
> greater than 7 additional bits, stored length-prefix encoded.
>
> The single bit <code>has_value</code> indicates whether the node
> stores a data bytestring, the value associated with its key prefix.
> Since keys may be any value or length, including one key being a
> prefix of another, it is possible for interior nodes in addition to
> leaf nodes to have values associated with them, and therefore an
> explicit value-existence bit is required.
>
> The remaining three bits are used for proof extraction, and are masked
> away prior to hash operations. <code>prune_left</code> indicates that
> the entire left branch has been pruned. <code>prune_right</code> has
> similar meaning for the right branch. If <code>has_value</code> is
> set, <code>prune_value</code> may be set to exclude the node's value
> from encoded proof. This is necessary field for interior nodes, since
> it is possible that their values may be pruned while their children
> are not.
>
> The <code>value</code> field is only present if the bit
> <code>flags.has_value</code> is set, in which case it is a
> <code>VARCHAR</code> bytestring:
>
> switch flags.has_value:
> case 0:
> value := ε
> case 1:
> value := VARCHAR(node.value)
>
> The <code>extra</code> field is always present, and takes on a
> bytestring value defined by the particular application. Use of the
> <code>extra</code> field is application dependent, and will not be
> covered in this specification. It can be set to the empty bytestring
> (serialized as a single zero byte) if the application has no use for
> the <code>extra</code> field.
>
> value := VARCHAR(calculate_extra(node))
>
> The <code>left</code> and <code>right</code> non-terminals are only
> present if the corresponding <code>flags.left_flags</code> or
> <code>flags.right_flags</code> are non-zero. The format depends on the
> value of this flags setting:
>
> switch branch_flags:
> case 0:
> branch := ε
> case 1:
> branch := branch_node_or_hash
> case 2:
> prefix = prefix >> 1
> branch := int_to_byte(1 << len(prefix) | bits_to_int(prefix)) ||
> branch_node_or_hash
> case 3:
> prefix = prefix >> 1
> branch := VARINT(len(prefix) - 9) ||
> bits_to_string(prefix) ||
> branch_node_or_hash
>
> <code>branch_flags</code> is a stand-in meant to describe either
> <code>left_flags</code> or <code>right_flags</code>, and likewise
> everywhere else in the above pseudocode <code>branch</code> can be
> replaced with either <code>left</code> or <code>right</code>.
>
> <code>prefix</code> is the key bits between the current node and the
> next branching, terminal, and/or leaf node, including the implicit
> leading bit for the branch (0 for the left branch, 1 for the right
> branch). In the above code, <code>len(prefix)</code> returns the
> number of bits in the bitstring, and <code>prefix >> 1</code> drops
> the first bit reducing the size of the bitstring by one and
> renumbering the indices accordingly.
>
> The function <code>int_to_byte</code> takes an integer in the range
> [0, 255] and returns the octet representing that value. This is a NOP
> in many languages, but present in this pseudocode so as to be explicit
> about what is going on.
>
> The function <code>bits_to_int</code> interprets a sequence of bits as
> a little-endian integer value. This is analogous to the following
> pseudocode:
>
> def bits_to_int(bits):
> result = 0
> for idx in 1..len(bits):
> if bits[idx] == 1:
> result |= 1<<idx
>
> The function <code>bits_to_string</code> serializes a sequence of bits
> into a binary string. It uses little-endian bit and byte order, as
> demonstrated by the following pseudocode:
>
> def bits_to_string(bits):
> bytes = [0] * ceil(len(bits) / 8)
> for idx in 1..len(bits):
> if bits[idx] == 1:
> bytes[idx / 8] |= 1 << idx % 8
> return map(int_to_byte, bytes)
>
> <code>branch_node_or_hash</code> is either the serialized child node
> or its SHA-256 hash and associated meta-data. Context determines which
> value to use: during digest calculations, disk/database serialization,
> and when the branch is pruned the hash value is used and serialized in
> the same way as other SHA-256 values in the bitcoin protocol (note
> however that it is single-SHA-256, not the double-SHA-256 more
> commonly used in bitcoin). The number of terminal (value-containing)
> nodes and the serialized size in bytes of the fully unpruned branch
> are suffixed to the branch hash. When serializing a proof or
> snapshotting tree state and the branch is not pruned, the serialized
> child node is included directly and the count and size are omitted as
> they can be derived from the serialization.
>
> if branch_pruned or SER_HASH:
> branch_node_or_hash := SHA-256(branch) ||
> count(branch) ||
> size(branch)
> else:
> branch_node_or_hash := serialize(branch)
>
> As an example, here is the serialization of a prefix tree mapping the
> names men and women of science to the year of their greatest publication:
>
> >>> dict = AuthTree()
> >>> dict['Curie'] = VARINT(1898)
> >>> dict('Einstein') = VARINT(1905)
> >>> dict['Fleming'] = VARINT(1928)
> >>> dict['中本'] = VARINT(2009)
> >>> dict.serialize()
> # An bytestring, broken out into parts:
>
> # . Root node:
> 0x0e # left_flags: 2, right_flags: 3, has_value: 1
> 0x00 # extra: ε
>
> # .l Inner node: 0b01000
> 0x11 # 0b01000
> 0x07 # left_flags: 3, right_flags: 1
> 0x00 # extra: ε
>
> # .l.l Inner node: 0b01000011 0b01110101 0b01110010 0b01101001
> # 'C' 'u' 'r' 'i'
> # 0b01100101
> # 'e'
> 0x1abb3a599a02 # 0b01101110101011100100110100101100101
> 0x10 # has_value: 1
> 0x00 # extra: ε
> 0x03fd6a07 # value: VARINT(1911)
>
> # .l.r Inner node: 0b010001
> 0x0f # left_flags: 3, right_flags: 3
> 0x00 # extra: ε
>
> # .l.r.l Inner node: 0b01000101 0b01101001 0b01101110 0b01110011
> # 'E' 'i' 'n' 's'
> # 0b01110100 0b01100101 0b01101001 0b01101110
> # 't' 'e' 'i' 'n'
> 0x312ded9c5d4c2ded00 # 0b1011010010110111
> # 0b0011100110111010
> # 0b0011001010110100
> # 0b101101110
> 0x10 # has_value: 1
> 0x00 # extra: ε
> 0x03fd7107 # value: VARINT(1905)
>
> # .l.r.r Inner node: 0b01000110 0b01101100 0b01100101 0b01101101
> # 'F' 'l' 'e' 'm'
> # 0b01101001 0b01101110 0b01100111
> # 'i' 'n' 'g'
> 0x296c4c6d2dedcc01 # 0b0011011000110010
> # 0b1011011010110100
> # 0b10110111001100111
> 0x10 # has_value: 1
> 0x00 # extra: ε
> 0x03fd8807 # value: VARINT(1928)
>
> # .r Inner node: 0b11100100 0b10111000 0b10101101
> # '中'
> # 0b11100110 0b10011100 0b10101100
> # '本'
> 0x27938edab39c1a # 0b1100100101110001
> # 0b0101101111001101
> # 0b001110010101100
> 0x10 # has_value: 1
> 0x00 # extra: ε
> 0x03fdd907 # value: VARINT(2009)
>
> ==Hashing==
>
> There are two variations of the authenticated prefix tree presented in
> this draft BIP. They differ only in the way in which hash values of a
> node and its left/right branches are constructed. The variations,
> discussed below, tradeoff computational resources for the ability to
> compose operational proofs. Whether the performance hit is
> significant, and whether or not the added features are worth the
> tradeoff depends very much on the application.
>
> ===Variation 1: Level-compressed hashing===
>
> In this variation the referenced child node's hash is used in
> construction of an interior node's hash digest. The interior node is
> serialized just as described (using the child node's digest instead of
> inline serialization), the resulting bytestring is passed through one
> round of SHA-256, and the digest that comes out of that is the hash
> value of the node. This is very efficient to calculate, requiring the
> absolute minimum number of SHA-256 hash operations, and achieving
> level-compression of computational resources in addition to reduction
> of space usage.
>
> For example:
>
> >>> dict = AuthTree()
> >>> dict['a'] = 0xff
> >>> dict.serialize()
> 0x0200c3100001ff
> >>> dict.root
> AuthTreeNode(
> left_prefix = 0b01100001,
> left_hash =
> 0xbafa0e2bba3396c5e9804b6cbe61be82bc442c1121aed81f8d5de36e9b20dc2f,
> left_count = 1,
> left_size = 4)
> >>> dict.hash
> 0xb4837376022a7c9ddaa7d685ad183bcbd5d16c362b81fa293a7b9e911766cf3c
>
> Assuming uniform distribution of key values, level-compressed hashing
> has time-complexity logarithmic with respect to the number of keys in
> the prefix tree. The disadvantage is that it is not possible in
> general to "rebase" an operational proof on top of a sibling,
> particularly if that sibling deletes branches that result in
> reorganization and level compression of internal nodes used by the
> rebased proof.
>
> ===Variation 2: Proof-updatable hashing===
>
> In this variation, level-compressed branches are expanded into a
> series of chained single-branch internal nodes, each including the
> hash of its direct child. For a brach with a prefix N bits in length,
> this requires N chained hashes. Thanks to node-compression (excluding
> empty branches from the serialization), it is possible for each hash
> operation + padding to fit within a single SHA-256 block.
>
> Note that the serialization semantics are unchanged! The variation
> only changes the procedure for calculating the hash values of interior
> nodes. The serialization format remains the same (modulo differing
> hash values standing in for pruned branches).
>
> Using the above example, calling <code>dict.hash</code> causes the
> following internal nodes to be constructed:
>
> >>> node1 = AuthTreeNode(
> right_prefix = 0b1,
> right_hash =
> 0xbafa0e2bba3396c5e9804b6cbe61be82bc442c1121aed81f8d5de36e9b20dc2f,
> right_count = 1,
> right_size = 4)
> >>> node2 = AuthTreeNode( left_prefix=0b0, left_hash=node1.hash,
> left_count=1, left_size=4)
> >>> node3 = AuthTreeNode( left_prefix=0b0, left_hash=node2.hash,
> left_count=1, left_size=4)
> >>> node4 = AuthTreeNode( left_prefix=0b0, left_hash=node3.hash,
> left_count=1, left_size=4)
> >>> node5 = AuthTreeNode( left_prefix=0b0, left_hash=node4.hash,
> left_count=1, left_size=4)
> >>> node6 = AuthTreeNode(right_prefix=0b1, right_hash=node5.hash,
> right_count=1, right_size=4)
> >>> node7 = AuthTreeNode(right_prefix=0b1, right_hash=node6.hash,
> right_count=1, right_size=4)
> >>> node8 = AuthTreeNode( left_prefix=0b0, left_hash=node7.hash,
> left_count=1, left_size=4,
> value=0xff)
> >>> dict.hash == node8.hash
> True
> >>> dict.hash
> 0xc3a9328eff06662ed9ff8e82aa9cc094d05f70f0953828ea8c643c4679213895
>
> The advantage of proof-updatable hashing is that any operational proof
> may be "rebased" onto the tree resulting from a sibling proof, using
> only the information locally available in the proofs, even in the
> presence of deletion operations that result in level-compression of
> the serialized form. The disadvantage is performance: validating an
> updatable proof requires a number of hash operations lower-bounded by
> the length of the key in bits.
>
> ==Inclusion proofs==
>
> An inclusion proof is a prefix tree pruned to contain a subset of its
> keys. The serialization of an inclusion proof takes the following form:
>
> inclusion_proof := variant || root_hash || root_node || checksum
>
> Where <code>variant</code> is a single-byte value indicating the
> presence of level-compression (0 for proof-updatable hashing, 1 for
> level-compressed hashing). <code>root_hash</code> is the Merkle
> compression hash of the tree, the 32-byte SHA-256 hash of the root
> node. <code>tree</code> is the possibly pruned, serialized
> representation of the tree. And finally, <code>checksum</code> is the
> first 4 bytes of the SHA-256 checksum of <code>variant</code>,
> <code>root_hash</code>, and <code>root_node</code>.
>
> For ease of transport, the standard envelope for display of an
> inclusion proof is internet-standard base64 encoding in the following
> format:
>
> - -----BEGIN INCLUSION PROOF-----
> ATzPZheRnns6KfqBKzZs0dXLOxithdan2p18KgJ2c4O0DgARBwAauzpZmgIQAAP9agcPADEt7Zxd
> TC3tABAAA/1xBylsTG0t7cwBEAAD/YgHJ5OO2rOcGhAAA/3ZByEg+2g=
> - -----END INCLUSION PROOF-----
>
> Decoded, it looks like this:
>
> 0x01 # Level-compressed hashing
> # Merkle root:
> 0x3ccf6617919e7b3a29fa812b366cd1d5cb3b18ad85d6a7da9d7c2a02767383b4
> # Serialized tree (unpruned):
> 0x0e001107001abb3a599a02100003fd6a070f00312ded9c5d4c2ded00100003fd
> 0x7107296c4c6d2dedcc01100003fd880727938edab39c1a100003fdd907
> # Checksum:
> 0x2120fb68
>
> ==Operational proofs==
>
> An operational proof is a list of insert/update and delete operations
> suffixed to an inclusion proof which contains the pathways necessary
> to perform the specified operations. The inclusion proof must contain
> the key values to be updated or deleted, and the nearest adjacent key
> values for each insertion. The serialization of an operational proof
> takes the following form:
>
> operational_proof := variant || root_hash || tree ||
> VARLIST(delete*) || VARLIST(update*) ||
> new_hash || checksum
>
> delete := VARCHAR(key)
> update := VARCHAR(key) || VARCHAR(value)
>
> The first three fields, <code>variant</code>, <code>root_hash</code>,
> and <code>tree</code> are the inclusion proof, and take the same
> values described in the previous section. <code>deletes</code> is a
> list of key values to be deleted; each key value in this list must
> exist in the inclusion proof. <code>updates</code> is a list of key,
> value mappings which are to be inserted into the tree, possibly
> replacing any mapping for the key which already exists; either the key
> itself if it exists (update), or the two lexicographically closest
> keys on either side if it does not (insert) must be present in the
> insertion proof. <code>new_hash</code> is the resulting Merkle root
> after the insertion, updates, and deletes are performed, and
> <code>checksum</code> is the initial 4 bytes of the SHA-256 hash of
> the preceding fields.
>
> Just like inclusion proofs, an operational proof is encoded in base64
> for display and transport. Here's the same
>
> - -----BEGIN OPERATIONAL PROOF-----
> ATzPZheRnns6KfqBKzZs0dXLOxithdan2p18KgJ2c4O0LgARaIsVaQi/GdhOPOgA8p4Pu4PiEfEg
> lcmy3j7bOc7hXw0DLSeTjtqznBoQAAP92QcBMOS4reacrACzuZJbyP7fqIOf5VEk4iarG4+uPoZC
> oun8BztQMQBy0LHVeSY=
> - -----END OPERATIONAL PROOF-----
>
> Decoded and broken into its constituent fields:
>
> 0x01 # Level-compressed hashing
> # Original Merkle root:
> 0x3ccf6617919e7b3a29fa812b366cd1d5cb3b18ad85d6a7da9d7c2a02767383b4
> # Serialized tree (included keys: '中本'):
> 0x2e0011688b156908bf19d84e3ce800f29e0fbb83e211f12095c9b2de3edb39ce
> 0xe15f0d032d27938edab39c1a100003fdd907
> # Deletion list ['中本']:
> 0x01
> 0x30e4b8ade69cac
> # Insertion list []:
> 0x00
> # New Merkle root:
> 0xb3b9925bc8fedfa8839fe55124e226ab1b8fae3e8642a2e9fc073b50310072d0
> # Checksum:
> 0xb1d57926
>
> ~End of File~
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSs6HIAAoJEAdzVfsmodw4gooQAJm7XNsZjgdeTSpKIvUIU38f
> tQx2FD08hQdLl48me5mDUbHJgGlYINsKAgoZ8Mqwi/kHEEYhuIlLIX1p6Ovigidb
> 21BiVoOLdG1egGOwxp17DuwYaDPTppFTlN9TBjZzW6WKc7+4aNvyc1KtrbHIhtj/
> 04ekFyAn4U5UH0ht7CI79j0u3Kp85p5D4PyYZB2m82mzti6OxpSM4tXlMkDW7ihg
> QJwiZSjzejqTd7WF0zr0SLeGVRSN2A0dzUCoVsI98eIa3hkw2N4ae6dRkibyStOT
> V8VEDvHArEDlvu8jiryajhsom5mvtOOclNDkVXWAf/Te4gj05iYdTIvNvDEJtqsP
> XDbmw6GgV1kBLlLo0mp//t/+wr+nIvy+sVAP+eqtM/0vjaVXBkXxkUMqqNkrtVpB
> f3whq7nFahssUMSoWE93jgob1ayAax2XUALVMAXYsJl7b2MqBGlhiTZ8FQZ+TW4A
> tIpKeUprPmDvA18rO3SCbmLMQryZqYiH0sRyvUc5kvn3qCRHrISZNkEuK591eS+x
> BO1eOluPzVqeXPPSK1jvGeY0FNJtwzbov4nI1mzOvzQHLCvkHn5PhUFCK5tL5tAe
> b0Z5qwDV+SvVs7W1R7ejYBzEj77U1zuzZ9AtikOuvy+bNGrkIlpI49EyXHijm7C3
> Q6JacTuI0PelYji2gaBJ
> =BbDs
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&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:08:48

- reply

📅 Original date posted:2013-11-04
📝 Original message:Electrum version 1.9 is now released.
This version connects to multiple servers, and it also checks the SSL
certificates of servers it knows.
Please note that the BIP32 features are postponed (to version 2.0), due
to the discussions about mnemonic seed format.
Here is the changelog:
# Release 1.9
* The client connects to multiple servers in order to retrieve block
headers and find the longest chain
* SSL certificate validation (to prevent MITM)
* Deterministic signatures (RFC 6979)
* Menu to create/restore/open wallets
* Create transactions with multiple outputs from CSV (comma separated
values)
* New user interface for text mode, named "stdio" (does not use curses)
* Plugins are no longer tied to the qt GUI, they can reach all GUIs
* Proxy bugs have been fixed

2023-06-07 15:08:34

- reply

📅 Original date posted:2013-11-02
📝 Original message:Le 31/10/2013 12:18, slush a écrit :
> Oh, I forgot to one practical aspect; the way how the mnemonic is
> "mined" in Thomas proposal prevents usage in embedded devices, because
> difficulty of generating proper mnemonic is simply too high for
> embedded microcontrollers. Maybe this can be solved somehow by
> modifying the proposal, but right now it is a showstopper for us.
>
>
even if metadata is only 8 bits ? (that's about 256 hashes)

2023-06-07 15:08:33

- reply

📅 Original date posted:2013-11-03
📝 Original message:Le 03/11/2013 08:40, Timo Hanke a écrit :
> I think the communication would have to go the other way around. Trezor
> has to commit to a value First. Like this:
>
> Trezor picks random s and sends S=s*G to computer, keeping s secret.
> Computer picks random t and sends t to Trezor. Trezor makes r := s+t
> its internal master private key with corresponding master public key
> R := (s+t)*G. Since R = S+t*G, the computer can verify the master
> public key. As you say, the computer can then store R and can later
> verify for each derived pubkey that it was indeed derived from R, hence
> from his own entropy t.
I'm not sure how this differs from what I wrote...
However, if this is how it works, then my question remains:
The computer has no proof to know that pubkeys derived through bip32's
private derivations are derived from its own entropy...
This verification would only work for public (aka type2) derivations.
.. but maybe Trezor works in a different way? I think an explanation
from slush would be needed.
> However, Trezor could not use straight bip32 out of the box. The
> chaincode would have to be something like SHA(R). And the seed (that
> gets translated to mnemonic) would be r itself, making it 256 bit
> instead of only 128 bit.
>
> If the longer seed is bearable then this is a good way to do it.
>
> One question remains: if you only write down the mnemonic how can you be
> sure that it is correct and corresponds to the secret in Trezor? You
> cannot verify that on paper. You would have to restore it on some
> device, eg another empty Trezor, and see if it brings up the same master
> pubkey. Right?
>
I guess you have to trust Trezor that it derives R from r

2023-06-07 15:08:32

- reply

📅 Original date posted:2013-11-02
📝 Original message:> To be specific, we (in cooperation with / inspired by Timo Hanke)
> developed method how to prove that the seed generated by Trezor has
> been created using combination of computer-provided entropy and
> device-provided entropy, without leaking full private information to
> other computer, just because we want Trezor to be blackbox-testable
> and fully deterministic (seed generation is currently the only
> operation which uses any source of RNG).
>
Thanks for the explanation. Here is how I understand how it works,
please correct me if I'm wrong:
The user's computer picks a random number a, the Trezor picks a random
number b.
Trezor adds a and b in the secp256k1 group, and this creates a master
private key k.
Trezor sends the corresponding master public key K to the computer.
Thus, the computer can check that K was derived from a, without knowing b.
This also allows the computer to check that any bitcoin address derived
from K is derived from a, without leaking b. (and reciprocally)
However, it seems to me that this property will work only with bip32
public derivations; if a private derivation is used, don't you need to
know k?

2023-06-07 15:08:32

- reply

📅 Original date posted:2013-11-03
📝 Original message:Le 03/11/2013 07:41, Timo Hanke a écrit :
> No. You mean the computer would use B for this check? (k,K) could be
> rigged by Trezor, who computes b as k-a. Timo
I was just asking a question, in order to understand how this device
works, and what are its requirements.
if you think you can help, please explain.

2023-06-07 15:08:01

- reply

📅 Original date posted:2013-10-26
📝 Original message:here is a simple implementation, with some ideas on how to format the
metadata:
https://en.bitcoin.it/wiki/Talk:BIP_0039

2023-06-07 15:08:01

- reply

📅 Original date posted:2013-10-31
📝 Original message:Indeed, I want to include a version number in the seed phrase because
there are
multiple ways to define the tree structure used with BIP32. It is
certainly too early
to make final decisions on that, or to achieve a common standard.
Also, I can imagine that bip32 itself might be superseeded in the future.
I understand that encapsulating a version number in the seed phrase might
not be as important for other wallets as it is for Electrum. So it is
probably not
necessary to propose another BIP for that. I will simply implement it
for Electrum,
and I will try to do it in such a way that other wallets can use the
same format.
The other question we might be solving is strenghtening (your proposal).
I consider
that this is not a strong requirement for Electrum, because it does not
let the user
choose their seed phrase. However, if a few bits of the seed phrase are
allocated
for metadata, then I guess strenghtening can be part of it. That's
another good
reason to have a version number encapsulated in the seed.
I too wonder why the transformation needs to be bidirectional in bip39.
Le 26/10/2013 23:30, Pieter Wuille a écrit :
> Let's first try to agree on what we are solving.
>
> It seems that Thomas wants - in addition to the cryptographic data -
> to encode the tree structure, or at least version information about
> what features are used in it, inside the seed.
>
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
> structures. I do think we first need to see what possibilities and
> developments are possible related to it.
>
> In addition, information about the wallet structure is strictly less
> secret than the key data - it is even less confidential than address
> book data, transaction annotations, labels and comments and
> bookkeeping information. It could be backed up anywhere and everywhere
> without any repercussions, as far as I can see. I understand that in
> the case of Electrum, there is a strong reason to want this
> encapsulated together with the seed, but it's not really a requirement
> for most wallets.
> (if really needed, any key derivation scheme that starts from random
> strings can be augmented with metadata by enforcing property-bits on a
> hash of the string (so not of the output), as this data doesn't need
> protection from brute-forcing).
>
> Regarding other requirements, I wonder why we want the transformation
> to be bidirectional? If it is just about generating master seeds, one
> direction should be enough, and allows far nicer properties w.r.t.
> security. If we do settle on a standard for 'brainwallets', I would
> strongly prefer if it had at least some strengthening built-in, to
> decrease the impact of worst-case situations.
> If the reason is backward-compatibility, I think that any client that
> supports seeds already can just keep supporting whatever they
> supported before. Only if it matches both encoding schemes (as
> mentioned before) there is a potential collision (and in that case,
> the user could just be asked).
>

2023-06-07 15:08:00

- reply

📅 Original date posted:2013-10-25
📝 Original message:slush wrote :
> Two years ago I proposed exactly this and you refused to add extra
> information to mnemonic, because "it isn't necessary" and "it makes it
> longer to mnemonization". What changed since then?
I was wrong, and I fully acknowledge it.
My concern was that adding extra information would make the mnemonic
longer than 12 words.
In addition, you proposed to allocate these extra bits for a checksum,
not for metadata.
However, a checksum does not really add any information, because
Electrum checks the existence of a wallet directly from the blockchain.
So, my feeling at that time was that adding extra bits would increase
the risks (a longer seed is harder to memorize, increases the
probability of mistakes, etc), and did not bring any real benefit.
However, you showed since then how to solve this by using a slightly
longer dictionary, and I do like your solution, I find it absolutely
brilliant.
In addition, I realize now that metadata (ie a "version number") is
crucially needed, for the reasons mentioned in my previous post.
> Hm, what exactly do you need to store about wallet structure? I lived
> in opinion that everything is able to recover using CKD function to
> generate new addresses and blockchain lookups for their balances.
BIP32 gives a lot of freedom to wallet developers: it does not specify
which branches of the HD tree shall be used for which purpose.
However, if you want to recover a wallet from its mnemonic (a
requirement for Electrum), then you need to know which branches to explore.
In Electrum 1.9 I had to make some choices about branch allocation.
However, the decisions that I made are certainly not final, so it is
important to be able to change them in the future. Thus, this metadata
needs to be added to the mnemonic.
> Yes, that's true. It isn't possible to make everybody 100% happy. At
> least I wanted to be constructive and asked you to replace the most
> problematic words. No pull request from you so far.
The solution I propose is very different from BIP39, and it does not
require to predefine a dictionary.
My proposal is actually somewhat similar to Pieter Wuille's proposal,
which I discovered after his recent post.
( https://bitcointalk.org/index.php?topic=102349.0 )
> Yes, it was original idea. So far I don't think this is a problem. Of
> course some words may have some meaning across languages, but it
> should be easy to avoid them. There are tens of thousands words in
> every language and we need to pick "only" 2048 words to wordlist.
> ...
> Are your worries about overlapping words across languages a real issue?
No, there are not so many words that are frequent enough.
Overlapping will be an issue, especially if we go for a 4096 words
dictionary.
> If I understand this well, it is basically one-way algorithm "mnemonic
> -> seed", right? Seed cannot be printed out as mnemonic, because
> there's hashing involved, but the bi-directionality has been the
> original requirement for such algorithm (at least in Electrum and bip39).
You are right, this encoding is not symmetric.
Bi-directionality has never been a requirement for Electrum. May I ask
why you need bi-directionality in Trezor?
(the only reason I can think of is if you want to export a bip32 branch
into another wallet, but this would create a very long mnemonic string)
> Then, how is this different to picking 12 random words from dictionary
> and hashing them together? I don't see any benefit in that "mining"
> part of the proposal (except that it is lowering the entropy for given
> length of mnemonic).
it makes it possible to hash a utf8 string, and to retrieve the metadata
from the hash.
Thus we don't need to spend ages arguing about the best choice of a
dictionary, and to set it in stone.