<unnamed>

Public Key

npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47

Profile Code

nprofile1qqs85jayqpcw2sqjyy5xwxpvv6lw7kfxq0l8cu5ykuhl4t7wnk3qcpgpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qxtmfjh

Publishing to

relay.nostr.net

Last Notes

2023-08-16 02:49:04 CEST

- 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-21 01:25:28 CEST

- 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 13:15:34 CEST

- 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 19:42:39 CEST

- 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 16:16:41 CEST

- 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-07 20:09:41 CEST

- 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 20:07:30 CEST

- 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 20:06:06 CEST

- 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 20:05:22 CEST

- 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 20:05:21 CEST

- 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 20:05:16 CEST

- 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 20:05:15 CEST

- 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 19:53:02 CEST

- 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 19:51:27 CEST

- 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:42:43 CEST

- 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 17:34:45 CEST

- 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 17:34:44 CEST

- 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 17:34:10 CEST

- 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 17:34:03 CEST

- 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 17:34:03 CEST

- 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 17:31:26 CEST

- 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 17:31:25 CEST

- 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 17:31:24 CEST

- 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 17:20:20 CEST

- 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 17:20:06 CEST

- 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 17:18:54 CEST

- 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 17:18:10 CEST

- 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 17:18:04 CEST

- 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 17:18:04 CEST

- 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 17:18:03 CEST

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

- 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 17:16:24 CEST

- 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 17:16:22 CEST

- 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 17:16:21 CEST

- 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 17:16:20 CEST

- 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 17:16:15 CEST

- 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 17:16:14 CEST

- 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 17:15:47 CEST

- 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 17:15:07 CEST

- 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 17:12:24 CEST

- 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 17:12:23 CEST

- 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 17:08:32 CEST

- 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 17:08:32 CEST

- 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 17:08:01 CEST

- 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 17:08:00 CEST

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