Andreas Schildbach [ARCHIVE]

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

Public Key

npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7

Profile Code

nprofile1qqsry9dn6a7l78uya66663hmzgr235t90vl2wedgpd2gnm8r5upd90qu89q6j

Author Public Key

npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7

Show more details

Last Notes

2023-06-07 22:59:58

- reply

📅 Original date posted:2021-10-09
📝 Original message:I'm trying to finish off bitcoinj's implementation for sending to
taproot addresses. For this, I'd like to test against a wallet that can
receive to P2TR and spend back.
I've been trying to get a taproot address from Bitcoin Core 22.0 and
spent many hours, but in vain. Can someone please simply send my a
testnet wallet that has at least one taproot address? (I don't care
about anyone stealing my testnet coins, so don't worry about the
compromised private key.)
Thanks!

2023-06-07 18:21:14

- reply

📅 Original date posted:2019-10-21
📝 Original message:I guess then the best way to discover nodes that have reject messages
enabled is connecting/disconnecting to random nodes and send them
invalid transactions and keep the ones which reply with a reject message.
On 18/10/2019 22.53, John Newbery via bitcoin-dev wrote:
>> Is there a NODE_* bit we can use to pick peers that support this
> (useful!) feature?
>
> No. BIP 61 has no mechanism for advertising that a node will send REJECT
> messages.
>
> On Wed, Oct 16, 2019 at 12:43 PM John Newbery <john at johnnewbery.com
> <mailto:john at johnnewbery.com>> wrote:
>
> Following discussion on this mailing list, support for BIP 61 REJECT
> messages was not removed from Bitcoin Core in V0.19. The behaviour
> in that upcoming release is that REJECT messages are disabled by
> default and can be enabled using the `-enablebip61` command line option.
>
> Support for REJECT messages will be removed entirely in Bitcoin Core
> V0.20, expected for release in mid 2020. The PR to remove support
> was merged into Bitcoin Core's master branch this week.
>
> Adoption of new Bitcoin Core versions across reachable nodes
> generally takes several months.
> https://bitnodes.earn.com/dashboard/?days=365 shows that although
> v0.18 was released in May 2019, there are still several hundred
> reachable nodes on V0.17, V0.16, V0.15 and earlier software.
> Software that currently use REJECT messages from public nodes for
> troubleshooting issues therefore have plenty of time to transition
> to one of the methods listed by Marco in the email above.
>
> John
>
> On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Bitcoin Core may send "reject" messages as response to "tx",
> "block" or
> "version" messages from a network peer when the message could
> not be accepted.
>
> This feature is toggled by the `-enablebip61` command line
> option and has been
> disabled by default since Bitcoin Core version 0.18.0 (not yet
> released as of
> time of writing). Nodes on the network can not generally be
> trusted to send
> valid ("reject") messages, so this should only ever be used when
> connected to a
> trusted node. At this time, I am not aware of any software that
> requires this
> feature, and I would like to remove if from Bitcoin Core to make
> the codebase
> slimmer, easier to understand and maintain. Let us know if your
> application
> relies on this feature and you can not use any of the
> recommended alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P
> network protocol
> should be done by inspecting the log messages that are
> produced by a recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for
> blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by
> specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to
> indicate a
> transaction has propagated the network, nor should wallets use
> "reject"
> messages to set transaction fees. Wallets should rather use
> fee estimation
> to determine transaction fees and set replace-by-fee if
> desired. Thus, they
> could wait until the transaction has confirmed (taking into
> account the fee
> target they set (compare the RPC `estimatesmartfee`)) or
> listen for the
> transaction announcement by other network peers to check for
> propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0
> unless there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:21:13

- reply

📅 Original date posted:2019-10-17
📝 Original message:On 16/10/2019 18.43, John Newbery via bitcoin-dev wrote:
> Following discussion on this mailing list, support for BIP 61 REJECT
> messages was not removed from Bitcoin Core in V0.19. The behaviour in
> that upcoming release is that REJECT messages are disabled by default
> and can be enabled using the `-enablebip61` command line option.
Is there a NODE_* bit we can use to pick peers that support this
(useful!) feature?

2023-06-07 18:19:36

- reply

📅 Original date posted:2019-07-23
📝 Original message:(Rather than replying individually, I try to address questions and add
my remarks in one post.)
> Finally, regarding alternatives, the filter-generation code for
> BIP 157/158 has been in Bitcoin Core for some time, though the
> P2P serving side of things appears to have lost any champions
> working on it.
BIP 157/158 is not an alternative to BIP 37:
1) It causes way too much traffic for mobile users, and likely even too
much traffic for fixed lines in not so developed parts of the world.
2) It filters blocks only. It doesn't address unconfirmed transactions.
3) Afaik, it enforces/encourages address re-use. This stems from the
fact that the server decides on the filter and in particular on the
false positive rate. On wallets with many addresses, a hardcoded filter
will be too blurry and thus each block will be matched. So wallets that
follow the "one address per incoming payment" pattern (e.g. HD wallets)
at some point will be forced to wrap their key chains back to the
beginning. If I'm wrong on this one please let me know.
4) The filters are not yet committed to the blockchain. Until that
happens we'd have to trust a server to provide correct filters.
> Can you specify exactly which wallets those are?
Bitcoin Wallet, Breadwallet, BISQ and many smaller ones.
> the DNS seed infrastructure among others can easily direct
> wallets to those nodes
Last I checked none of the seeds did. But I agree this would be nice to
have.
> We eventually can’t expect - in the long run - that nodes provide
> disk/CPU intense services for free to clients not contributing back
> to the network.
I'm disappointed to learn that supporting 10M wallets gets discredited
down to "no contribution". Each node of course supports just a number of
them, but still...
> The fact that nobody cared about extending it for SW may also
> underline that BIP37 is seen as a conceptual mistake and/or "low
> interest in further extensions“.
I suspect this is a fallacy. BIP37 doesn't need to be extended for
SegWit. See Bitcoin Wallet and Breadwallet, both support SegWit and use
the original BIP 37.
It's true however that BIP 37 could be made simpler to work with, more
future-proof and more private by simply matching output scripts.
> [1] https://github.com/petertodd/bloom-io-attack
This claims to be a proof of concept, but it's missing the concept. I
could not find a description of the attack and why is it likely to be
exploited (and why it hasn't been exploited yet).
> CPU DoS attacks are also possible
If such an attack exists, it should be easy to defend against. Filter is
using too much CPU time → disconnect and blacklist the IP for some time.
I vaguely remember the infrastructure for misbehaving peers is already
present in bitcoind.
As a side note, Coinbase just announced their 30M'th wallet. I'm
convinced this massive run into custodial wallets is caused by the
public realizing around Dec 2017 that Bitcoin fails to scale. IMHO, BIP
37 is the only scaling technology that has proven successful and could –
if supported and improved rather than choked – continue to help holding
against the bitbanks trend.

2023-06-07 18:19:34

- reply

📅 Original date posted:2019-07-21
📝 Original message:An estimated 10+ million wallets depend on that NODE_BLOOM to be
updated. So far, I haven't heard of an alternative, except reading all
transactions and full blocks.
It goes without saying pulling the rug under that many wallets is a
disastrous idea for the adoption of Bitcoin.
> well-known DoS vectors
I asked many people, even some "core developers" at meetings, but nobody
ever was able to explain the DoS vector. I think this is just a myth.
Yes, you can set an overly blurry filter and thus cause useless traffic,
but it never exceeds just drinking from the full firehose (which this
change doesn't prohibit). So where is the point? An attacker will just
switch filtering off, or in fact has never used it.
> It is not anticipated that
> this will result in a significant lack of availability of
> NODE_BLOOM-enabled nodes in the coming years
Why don't you anticipate that? People almost never change defaults,
especially if it's not for their own immediate benefit. At the same
time, release notes in general recommend updating to the latest version.
I *do* anticipate this will reduce the number of nodes usable by a large
enough amount so that the feature will become unstable.
> clients
> which rely on the availability of NODE_BLOOM-supporting nodes on the
> P2P network should consider the process of migrating
> to a more modern (and less trustful and privacy-violating) alternative
> over the coming years.
There is no such alternative.
I strongly recommend postponing this change until an alternative exists
and then give developers enough time to implement, test and roll out.
I also think as long as we don't have an alternative, we should improve
the current filtering for segwit. E.g. testing the scripts themselves
and each scriptPubKey spent by any input against the filter would do,
and it also fixes the main privacy issue with server-side filtering
(wallets have to add two items per address to the filter).

2023-06-07 18:16:41

- reply

📅 Original date posted:2019-03-06
📝 Original message:In case anyone missed the announcement: bitcoinj 0.15, with support for
native segregated witness, has recently been released.
https://groups.google.com/d/msg/bitcoinj-announce/X6Zv1NSFxOk/KJACzHZMAQAJ
For operability testing, I just released new versions 7.0 of Bitcoin
Wallet. For now, they still create a keychain of legacy addresses but
they can send to native segwit addresses via Bech32.
Testnet:
https://play.google.com/store/apps/details?id=de.schildbach.wallet_test
Mainnet:
https://play.google.com/store/apps/details?id=de.schildbach.wallet
(At the time of this writing, you need to opt into beta in order to
receive 7.x: https://play.google.com/apps/testing/de.schildbach.wallet)
Receiving to native segwit addresses and spending from them will follow
in the coming days and weeks.

2023-06-07 18:16:37

- reply

📅 Original date posted:2019-03-13
📝 Original message:On 12/03/2019 23.14, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> These two cases are understood and handled by current code. Generally
>> the idea is take reject messages serious, but don't overrate the lack
>> of. Luckily, network confirmations fill the gap. (Yes, a timeout is
>
> I'd like to better understand this, but it would be easier to just
> read the code than ask a bunch of questions. I tried looking for the
> handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> and didn't really find and handling other than logging exceptions.
> Would you mind giving me a couple pointers to where in the code
> they're handled?
It's implemented in bitcoinj's TransactionBroadcast class. Received
reject messages are collected and -- if a certain consensus (currently:
half of connected peers) is reached -- a RejectedTransactionException is
raised.
The handling of that exception in Bitcoin Wallet is extremely
rudimentary. I think it still only shows the exception message. But
certainly I was hoping to improve on this soon.

2023-06-07 18:16:36

- reply

📅 Original date posted:2019-03-07
📝 Original message:Yes, I'm talking about P2P connections.
First and foremost, reject messages are an indication that the
transaction isn't going to confirm. Without these messages, we'd need to
revert to pre-BIP61 behaviour of using a timeout for reception of
network confirmations.
Regarding the content, these cases are useful to distinguish:
- Not enough fee
- UTXO already spent
- Tx validity/standardness (e.g. invalid signature)
While the last one in theority wouldn't be necessary if you produced
your software bug-free to begin with, this just isn't how software
development works. Developers need any indication they can get.
The first two happen even in the ideal case. Fees are impossible to
predict, and unintentional double spends happen because users clone
their wallet state.
On 07/03/2019 14.59, Sjors Provoost via bitcoin-dev wrote:
> Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network?
>
> What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping inputs)?
>
> Sjors
>
>> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>>
>> Reject messages cannot be replaced for debugging user problems. At least
>> unless you plan to make RPC or bitcoind logfiles available via the P2P
>> protocol (both probably not a good idea).
>>
>> The typical case is, I get mailed a wallet logfile with reject messages
>> and that's all I have. I cannot access the bitcoind logfile(s) of the
>> node(s) that generated the reject message in the first place. Nor can I
>> access their RPC interface.
>>
>> I strongly suggest re-enabling reject messages by default before 0.18.
>>
>>
>> On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
>>> Bitcoin Core may send "reject" messages as response to "tx", "block" or
>>> "version" messages from a network peer when the message could not be accepted.
>>>
>>> This feature is toggled by the `-enablebip61` command line option and has been
>>> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
>>> time of writing). Nodes on the network can not generally be trusted to send
>>> valid ("reject") messages, so this should only ever be used when connected to a
>>> trusted node. At this time, I am not aware of any software that requires this
>>> feature, and I would like to remove if from Bitcoin Core to make the codebase
>>> slimmer, easier to understand and maintain. Let us know if your application
>>> relies on this feature and you can not use any of the recommended alternatives:
>>>
>>> * Testing or debugging of implementations of the Bitcoin P2P network protocol
>>> should be done by inspecting the log messages that are produced by a recent
>>> version of Bitcoin Core. Bitcoin Core logs debug messages
>>> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
>>> (`-debuglogfile=<debug.log>`).
>>>
>>> * Testing the validity of a block can be achieved by specific RPCs:
>>> - `submitblock`
>>> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
>>> potentially invalid POW
>>>
>>> * Testing the validity of a transaction can be achieved by specific RPCs:
>>> - `sendrawtransaction`
>>> - `testmempoolaccept`
>>>
>>> * Wallets should not use the absence of "reject" messages to indicate a
>>> transaction has propagated the network, nor should wallets use "reject"
>>> messages to set transaction fees. Wallets should rather use fee estimation
>>> to determine transaction fees and set replace-by-fee if desired. Thus, they
>>> could wait until the transaction has confirmed (taking into account the fee
>>> target they set (compare the RPC `estimatesmartfee`)) or listen for the
>>> transaction announcement by other network peers to check for propagation.
>>>
>>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
>>> valid concerns about its removal.
>>>
>>> Marco
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:16:36

- reply

📅 Original date posted:2019-03-12
📝 Original message:(Posting again, since my previous reply didn't appear)
On 08/03/2019 01.52, Gregory Maxwell via bitcoin-dev wrote:
> That is already required because even in the presence of perfectly
> honest and cooperative hosts reject messages at most can only tell you
> about first-hop behaviour. It won't even tell you if the transaction
> was ever even attempted to be sent to a next hop. So alternative
> handling must be provided and must be reliable for the software to
> work at all regardless of reject messages.
>
> Rejection causes were also not stable or reliable because the validity
> criteria cannot generally be tested independently. For example, if a
> transaction is queued due to missing a parent it isn't rejected
> because missing the parent is often a temporary issue, but its feerate
> cannot be measured without the parent. Later, when the parent is
> obtained, the transaction can then be rejected due to feerate-- but no
> reject is sent then.
These two cases are understood and handled by current code. Generally
the idea is take reject messages serious, but don't overrate the lack
of. Luckily, network confirmations fill the gap. (Yes, a timeout is
still useful. But at least it almost never happens.)
> Similarly, the error state detected for things like invalid signatures
> are often not very useful. The software knows that script execution
> returned false, but in the general case _why_ it returned false is not
> clear, and a straightforward high performance validation
> implementation doesn't necessarily yield a good way of figuring out
> and propagating up that information. (I think invalid signatures end
> up returning a stack-nonempty state from validation currently, as an
> example of that).
Nevertheless, it has been proven as useful in debugging (just recently
when I implemented the witness signature hash in bitcoinj). I think
Wilmer Paulino summed up this point quite nicely in his reply to this
thread.

2023-06-07 18:16:35

- reply

📅 Original date posted:2019-03-06
📝 Original message:Reject messages cannot be replaced for debugging user problems. At least
unless you plan to make RPC or bitcoind logfiles available via the P2P
protocol (both probably not a good idea).
The typical case is, I get mailed a wallet logfile with reject messages
and that's all I have. I cannot access the bitcoind logfile(s) of the
node(s) that generated the reject message in the first place. Nor can I
access their RPC interface.
I strongly suggest re-enabling reject messages by default before 0.18.
On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected to a
> trusted node. At this time, I am not aware of any software that requires this
> feature, and I would like to remove if from Bitcoin Core to make the codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network protocol
> should be done by inspecting the log messages that are produced by a recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee estimation
> to determine transaction fees and set replace-by-fee if desired. Thus, they
> could wait until the transaction has confirmed (taking into account the fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
> valid concerns about its removal.
>
> Marco
>

2023-06-07 18:15:10

- reply

📅 Original date posted:2018-11-08
📝 Original message:On 08/11/2018 09.11, Dmitry Petukhov via bitcoin-dev wrote:
>> Copying addresses to the clipboard should be discouraged, rather than
>> supported.
>
> Do you know any reasonably convenient mechanism for end user to
> transfer an address from, say, a web page to the wallet address
> input field ?
- QR code scanning of a Bitcoin URI
- On Android: A "bitcoin:" URI intent or a BIP70 payment message intent
- On desktop OSes there are similar mechanisms to launch Apps from the
browser (e.g. for mailto: links)
> The clipboard is just a low-hanging fruit for malware, anyway. It just
> the most easy point to replace an address. If the computer is
> compromized, malware can edit the web page in the memory of the browser
> process, for example. If it shown as QR code, malware can decode,
> detect that it is an address, and replace the image of QR code.
For editing the clipboard your computer doesn't need to be compromised!
*Any* app can do it, without special permission.
> I think that the only way to protect from this is to add some form of
> authentication for an address - 2fa (transfer checksum via second
> channel), visual fingerprints for addresses, that will are hard to
> detect (and hence, replace) for malware, signing the destination address
> with the key of an address that is already known and checking the
> signature, etc.
For cases where the payee is a well-known entity the BIP70 payment
protocol has authentication via certificates. That doesn't work for the
"the person in front of you is the only trust anchor you have" usecase
though.

2023-06-07 18:15:09

- reply

📅 Original date posted:2018-11-07
📝 Original message:Copying addresses to the clipboard should be discouraged, rather than
supported.
It is an inherently insecure mechanism. Regardless of the OS used, any
application can monitor the clipboard for Bitcoin addresses and replace
any address with their own, usually without any specific permission or
confirmation by the user. Effectively this steals Bitcoins if the user
doesn't compare addresses manually.
This is a real risk, as this kind of malware has already been seen.
Never copy & paste Bitcoin addresses!
On 07/11/2018 15.09, Adam Ficsor via bitcoin-dev wrote:
> BIP: ?
> Layer: Applications
> Title: Address Paste Improvement
> Author: nopara73 <adam.ficsor73 at gmail.com
> <mailto:adam.ficsor73 at gmail.com>>, David Molnar <molnardavid84 at gmail.com
> <mailto:molnardavid84 at gmail.com>>
> Type: Standard Track
> Created: 2018-11-07
>
> Abstract. End-users often copy-paste addresses. This BIP aims to
> facilitate the user experience regarding this process.
>
> Motivation. Some services already implemented autopaste functions, which
> is done as follows: the user clicks to the address box and a Bitcoin
> address automatically gets pasted from the clipboard. Depending on the
> implementation, this could be either annoying or not permissive enough
> if it completely replaces the possibility of manually entering a Bitcoin
> address.
>
> The BIP Proposal can be found
> here: https://gist.github.com/nopara73/322dbd263a5c45267da87cffc36de6f6
>
> An implementation will soon follow in Wasabi Wallet.
>
> Regards,
> nopara73
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:11:39

- reply

📅 Original date posted:2018-04-15
📝 Original message:Yes, I guess the quicker filter exhaustion must be the reason why
bitcoinj doesn't make use of outpoints in filters for standard
transactions. I'll look into if I can change that.
On 04/14/2018 06:14 PM, Christian Decker via bitcoin-dev wrote:
> Note that this would compound the privacy leak that Jonas Nick used to
> identify address clusters via the bloom filters in one of his
> publications. By reducing the false positives when matching you can get
> very detailed clusters. Then again we know that bloom filters aren't
> good for privacy anyway, so this might be a non-issue.
>
> On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Why not add the outpoints owned by the wallet to the filter and
> watch for those instead of elements in the input script or witness data?
>
> On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi Andreas
>
> Thanks for bringing this up and this seems indeed to be suboptimal.
>
> > I wonder if Bitcoin Core would be willing to extend the BIP37 matching
> > rules such that data elements in the witness are also matched against?
>
> Bitcoin Core is not an identity that can be „willing to extend“
> (or reject) a feature.
> Someone needs to come up with a proposal (pull request).
>
> Maybe an extension for BIP37 would make sense (*meh*).
> Just inserting the witness data into the bloom filter seems to
> be an easy solution (CBloomFilter::IsRelevantAndUpdate())
>
> /jonas
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:11:38

- reply

📅 Original date posted:2018-04-13
📝 Original message:Anton, a developer on the bitcoinj maiing list, recently made me aware
[1] of a compatibility issue between segwit and BIP37 (Bloom Filtering).
The issue affects only P2WPKH and the special case of transactions
without change outputs (such as when emptying a wallet). In this case,
neither inputs not outputs contain any data elements that would cause a
match for the filter. The public key, which would match, goes to the
witness but not to the input.
My suggestion was to include an OP_RETURN output with a matching public
key in such transactions. Anton confirmed that this workaround is indeed
working. But of course it nullifies some of the segwit's size improvements.
I wonder if Bitcoin Core would be willing to extend the BIP37 matching
rules such that data elements in the witness are also matched against?
[1] https://groups.google.com/d/msg/bitcoinj/SJpLgjowc1I/V7u2BavvAwAJ

2023-06-07 18:06:30

- reply

📅 Original date posted:2017-09-30
📝 Original message:Generally agreed. This is why I nack'ed BIP72 years ago when we
discussed about standardization.
However, there are many ways to use BIP70 without BIP72. BIP72 is just a
kludge to biggy-pack the payment protocol onto BIP21. And also, as you
note, BIP72 can be easily fixed using a hash parameter.
On 09/29/2017 04:55 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote:
>> Andreas Schildbach wrote:
>>> This feels redundant to me; the payment protocol already has an
>>> expiration time.
>>
>> The BIP-70 payment protocol has significant overhead and most importantly requires back and forth. Emailing a bitcoin address or printing it on an invoice is much easier, so I would expect people to keep doing that.
>
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment qr
> codes don't cryptographically commit to the identity of the merchant, which
> means a MITM attacker can redirect the payment if they can obtain a SSL cert
> that the wallet accepts.
>
> For example, if I have a wallet on my phone and go to pay a
> merchant, a BIP-72 URI will look like the following(1):
>
> bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
>
> A wallet following the BIP-72 standard will "ignore the bitcoin
> address/amount/label/message in the URI and instead fetch a PaymentRequest
> message and then follow the payment protocol, as described in BIP 70."
>
> So my phone will make a second connection - likely on a second network with a
> totally different set of MITM attackers - to https://merchant.com
>
> In short, while my browser may have gotten the correct URL with the correct
> Bitcoin address, by using the payment protocol my wallet is discarding that
> information and giving MITM attackers a second chance at redirecting my payment
> to them. That wallet is also likely using an off-the-shelf SSL library, with
> nothing other than an infrequently updated set of root certificates to use to
> verify the certificate; your browser has access to a whole host of better
> technologies, such as HSTS pinning, certificate transparency, and frequently
> updated root certificate lists with proper revocation (see Symantec).
>
> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at least
> supports a h= parameter with a hash commitment to what the payment request
> should be, and will reject the MITM attacker if that hash doesn't match. But
> that's not actually in the standard itself, and as far as I can tell has never
> been made into a BIP.
>
> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP made
> to replace it.
>
> 1) As an aside, it's absolutely hilarious that this URL taken straight from
> BIP-72 has the merchant using PHP, given its truly terrible track record for
> security.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:06:27

- reply

📅 Original date posted:2017-09-29
📝 Original message:On 09/29/2017 03:45 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Sep 28, 2017 at 12:09:59PM +0200, Andreas Schildbach via bitcoin-dev wrote:
>> This feels redundant to me; the payment protocol already has an
>> expiration time.
>
> I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
> overlap all the usecases that addresses do anyway - I think we should consider
> bringing this important feature to Bitcoin addresses too.
Hasn't caught on? It is used for virtually all merchant transactions,
plus person to person transactions between Bitcoin Wallet users.

2023-06-07 18:06:27

- reply

📅 Original date posted:2017-09-29
📝 Original message:On 09/29/2017 11:55 AM, Peter Todd via bitcoin-dev wrote:
>>> I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
>>> overlap all the usecases that addresses do anyway - I think we should consider
>>> bringing this important feature to Bitcoin addresses too.
>>
>> Hasn't caught on? It is used for virtually all merchant transactions,
>> plus person to person transactions between Bitcoin Wallet users.
>
> "Virtually all"?
>
> I regularly pay with Bitcoin, and I haven't seen the payment protocol used in
> ages.
I regularly pay with Bitcoin, and I haven't seen the payment protocol
not being in use in ages.
> Can you name some users of it?
15+ Mio Coinbase users
~10 Mio BitPay users
8 Mio Bitcoin Wallet users
Plus Bitcoin Core, Electrum, etc (sorry no numbers)
Probably the only usecase for naked addresses is paper wallets, right?
I'm not sure if paper wallets can expire.

2023-06-07 18:06:25

- reply

📅 Original date posted:2017-09-28
📝 Original message:On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:
>> The payment request message is just as one-way as an address is. It is
>> already being emailed and printed on an invoice, in fact it often acts
>> as the invoice.
>
> True and the more complicated fields, like a digital signature, are optional. Are you suggesting BIP-70 payment requests should be rendered with bech32? How long would those be if it's just the address and expiration date?
I've not yet progressed that far in segwit support, but I can't think of
a reason why not. You can request coins to any script using the payment
protocol.
Regarding size, I've had no problems putting (unsigned) payment request
messages into QR codes. I doubt paying to a native segwit address will
change much in size. Protobuf is very efficient.
>> Even more problematic, if you were to include an expiry date in a
>> BIP-173 address and put that into a payment request, wallets wouldn't be
>> allowed to parse that expiry date from the script without violating the
>> BIP70 spec.
>
> Do tools that generate BIP-70 payment requests generate addresses themselves or are those input manually by a user? In the former case, I assume it could avoid setting the optional expiration date?
The BIP70 spec doesn't limit you on this, I guess either does exist.
Having two (or more!) optional expiration date adds unnecessary
complexity to the specs and implementations. E.g. what if the two do not
match up?
> Is it not allowed to scan the date even if it then sets the expires field to the same (redundant) value?
What do you mean by "scan the date"?

2023-06-07 18:06:24

- reply

📅 Original date posted:2017-09-28
📝 Original message:This feels redundant to me; the payment protocol already has an
expiration time.
On 09/27/2017 06:06 PM, Peter Todd via bitcoin-dev wrote:
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen; there
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing deposits.
> This also makes it difficult operationally to rotate private keys. I personally
> have even lost funds in the past due to people sending me BTC to addresses that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
>
> To help combat this problem, I suggest that we add a UI-level expiration time
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time is
> reached.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and terminology
> questions. Notably, the entire notion of addresses is flawed from a user point
> of view: their experience with them should be more like "payment codes", with a
> code being valid for payment for a short period of time; wallets should not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds themselves;
> some thought needs to be put into terminology.
>
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
>
> Both options have the advantage of working well at the UI level regardless of
> timezone: the former is sufficiently short that UI's can simply display an
> "exact" time (though note different leap second interpretations), while the
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the advantage of making
> it easy for services like exchanges to use addresses with relatively short
> validity periods, to reduce the risks of losses after a hack. Also, using at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:06:24

- reply

📅 Original date posted:2017-09-28
📝 Original message:On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev wrote:
>> This feels redundant to me; the payment protocol already has an
>> expiration time.
>
> The BIP-70 payment protocol has significant overhead and most importantly requires back and forth. Emailing a bitcoin address or printing it on an invoice is much easier, so I would expect people to keep doing that.
The payment request message is just as one-way as an address is. It is
already being emailed and printed on an invoice, in fact it often acts
as the invoice.
Even more problematic, if you were to include an expiry date in a
BIP-173 address and put that into a payment request, wallets wouldn't be
allowed to parse that expiry date from the script without violating the
BIP70 spec.

2023-06-07 18:05:32

- reply

📅 Original date posted:2017-09-07
📝 Original message:On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:
> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>> A solution is still needed to wallets who do not wish to use BIP43
>
> What if we added another byte field OutputType for wallets that do not
> follow BIP43?
>
> 0x00 - P2PKH output type
> 0x01 - P2WPKH-in-P2SH output type
> 0x02 - native Segwit output type
>
> Would that work for you?
I think that would work.
> The question is whether this field should be present only if depth==0x00
> or at all times. What is your suggestion, Thomas?
In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
we need this field. I think it should always be present if a chain is
limited to a certain script type.
There is however the case where even on one chain, script types are
mixed. In this case the field should be omitted and the wallet needs to
scan for all (known) types. Afaik Bitcoin Core is taking this path.

2023-06-07 18:05:22

- reply

📅 Original date posted:2017-09-05
📝 Original message:Generally I like the idea, but maybe we should come up with a
(Bech32-based?) new standard that also includes the key birthdate (aka
"wallet birthdate").
Also I heard Core will mix addresses of all types on the same HD chain.
What prefix would it pick? "*pub"?
On 09/05/2017 12:25 PM, Thomas Voegtlin via bitcoin-dev wrote:
> 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.

2023-06-07 18:03:49

- reply

📅 Original date posted:2017-07-04
📝 Original message:Your BIP would take away the only way the *receiver* has to raise the
fee: CPFP. And the receiver is arguably the more important party in this
question. After all the sender has no real incentive for his payment to
be confirmed; it's receiver who has.
On 07/02/2017 10:35 PM, Rhavar via bitcoin-dev wrote:
> ==Abstract==
>
> BIP125 allows transactions to opt into replaceability with a primary use
> case
> of allowing users to increase the fees of unconfirming transactions,
> helping create
> a more efficient fee market place.
>
> However this goal is hindered when the receiver of a transaction spends
> from the
> unconfirmed output, which exposes the sender to the awkward position of
> needing
> to pick between needing to pay an effectively unbounded amount of money
> as per the BIP125 rules, or not fee bump at all.
>
> This is especially problematic in the case of batched sends in which
> there are
> multiple independent receivers. In practice this means wallets and
> services can not effectively low ball the fee of transactions, with the
> intention of fee bumping due to the risk of the receiver spending or
> sweeping it before it confirms.
>
> In order to support a healthy fee marketplace, this proposal aims to
> increase
> the utility of bip125 by making transactions that spend an unconfirmed
> BIP125
> output non-standard.
>
>
> ==Summary==
>
> This policy specifies a max chain depth of 1 for any BIP125 transactions.
>
> ==Impact==
>
> Receivers of BIP125 transactions will need to wait until the transaction
> has confirmed before spending from it. This will not be significantly
> different
> than it is currently as they receivers need to be monitoring for
> replacements.
>
> If senders want to make further transactions before the BIP125
> transaction confirms,
> and need to utilize the change of the transaction: they will need to
> replace the
> transaction with a one that makes the other send in "pass through" style
> or first
> finalize the BIP125 transaction and then chain from the spend normally.
>
>
> -Ryan
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:02:12

- reply

📅 Original date posted:2017-06-19
📝 Original message:Just to give you a number: based on the statistics of the Bitcoin Wallet
app there are at least 2 million wallets depending on BIP37. Not all
would need instant notification but based on the daily support enquiries
instant notificaton is the most asked property of Bitcoin.
On 06/19/2017 02:26 PM, bfd--- via bitcoin-dev wrote:
> Several times. It's been debated if unconfirmed transactions are
> necessary, methods of doing more private filtering have been suggested,
> along with simply not filtering unconfirmed transactions at all. My
> collected data suggests that there is very little use of BIP37 at
> present, based on incoming connections to nodes I know end up in the DNS
> seed responses (no "SPV" clients do their own peer management).
>
>
> On 2017-06-19 12:58, Andreas Schildbach via bitcoin-dev wrote:
>> I'm not sure if this has been brought up elsewhere in this thread.
>>
>> This proposal doesn't seem to be a complete replacement of BIP37: It
>> doesn't provide a filter for unconfirmed transactions like BIP37 does.
>>
>> That means that most light clients will continue to use BIP37 even if
>> they may use this BIP as a supplement. Otherwise users would not get
>> timely notification of incoming payments any more.
>>
>>
>> On 06/01/2017 09:01 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
>>> Hi y'all,
>>>
>>> Alex Akselrod and I would like to propose a new light client BIP for
>>> consideration:
>>> *
>>> https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
>>> [...]
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:02:11

- reply

📅 Original date posted:2017-06-19
📝 Original message:On 06/19/2017 05:49 PM, Jonas Schnelli via bitcoin-dev wrote:
>>> It's been debated if [filtering of] unconfirmed transactions are
>>> necessary,
>>
>> Why would it not be needed? Any SPV client (when used as a payment-receiver)
>> requires this from a simple usability point of view.
>
>
> I think many users would be willing ...
> a) … to trade higher privacy (using client side filtering) for not having the „incoming transaction“ feature
> b) – if they want 0-conf – to fetch all inved transactions
Another number: I'm answering dozens of support inquiries about
delayed/missing transactions per day. Over the 7 years of Bitcoin
Wallet's existence, I estimate about 50000 inquiries.
On the other hand, I remember only 1 (one) inquiry about the privacy
problems of BIP37 (or privacy at all).
>From a regular user's point of view, privacy is non-issue. Sure,
everyone would take it for free, but certainly not if it a) delays
incoming payments or b) quickly eats up your traffic quota.

2023-06-07 18:02:11

- reply

📅 Original date posted:2017-06-19
📝 Original message:Most SPV wallets make it quite clear that unconfirmed transactions are
just that.
On 06/19/2017 06:36 PM, adiabat via bitcoin-dev wrote:
> This has been brought up several times in the past, and I agree with
> Jonas' comments about users being unaware of the privacy losses due to
> BIP37. One thing also mentioned before but not int he current thread
> is that the entire concept of SPV is not applicable to unconfirmed
> transactions. SPV uses the fact that miners have committed to a
> transaction with work to give the user an assurance that the
> transaction is valid; if the transaction were invalid, it would be
> costly for the miner to include it in a block with valid work.
>
> Transactions in the mempool have no such assurance, and are costlessly
> forgeable by anyone, including your ISP. I wasn't involved in any
> debate over BIP37 when it was being written up, so I don't know how
> mempool filtering got in, but it never made any sense to me. The fact
> that lots of lite clients are using this is a problem as it gives
> false assurance to users that there is a valid but yet-to-be-confirmed
> transaction sending them money.
>
> -Tadge
>

2023-06-07 18:02:10

- reply

📅 Original date posted:2017-06-19
📝 Original message:I'm not sure if this has been brought up elsewhere in this thread.
This proposal doesn't seem to be a complete replacement of BIP37: It
doesn't provide a filter for unconfirmed transactions like BIP37 does.
That means that most light clients will continue to use BIP37 even if
they may use this BIP as a supplement. Otherwise users would not get
timely notification of incoming payments any more.
On 06/01/2017 09:01 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> Hi y'all,
>
> Alex Akselrod and I would like to propose a new light client BIP for
> consideration:
> * https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
> [...]

2023-06-07 18:02:01

- reply

📅 Original date posted:2017-06-01
📝 Original message:In order for such messages to be dispatchable between apps, I suggest
prepending with an URI scheme, similar to the already existing
"bitcoin:" scheme.
Also I suggest defining a MIME type, e.g. for usage in NFC NDEF messages
or emails.
What is the relation of this BIP to BIP21 and BIP70-72? Is there a
reason for not extending BIP70?
On 06/01/2017 03:28 AM, Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> There's a pull request for a lightning payment format which I'd
> love wider review on. It's bech32 encoded, with optional parts tagged:
>
> https://github.com/lightningnetwork/lightning-rfc/pull/183
>
> There's an implementation with a less formal description here, too:
>
> https://github.com/rustyrussell/lightning-payencode
>
> Example:
> Send 2500 microbitcoin using payment hash 00010203040506...0102 to me
> @03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad
> within 1 minute from now (Tue 30 May 12:17:36 UTC 2017):
>
> lnbc2500u1qpvj6chqqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqz8slk6hqew9z5kzxyk33ast248j3ykmu3wncvgtgk0ewf5c6qnhen45vr43fmtzsh02j6ns096tcpfga0yfykc79e5uw3gh5ltr96q00zqppy6lfy
>
> Thanks!
> Rusty.
>

2023-06-07 17:59:26

- reply

📅 Original date posted:2017-04-06
📝 Original message:On 04/05/2017 11:37 PM, Gregory Maxwell via bitcoin-dev wrote:
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented in hardware.
Do you plan to release details about this, or is it already documented
somewhere?

2023-06-07 17:57:37

- reply

📅 Original date posted:2017-03-21
📝 Original message:Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
In Bitcoin Wallet, I use Base 43 (alphabet:
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
code encoding. I only leave out the space character because it gets
replaced by "+" in URLs.
On 03/20/2017 10:35 PM, Pieter Wuille via bitcoin-dev wrote:
> Hello everyone,
>
> I'd like to propose a new BIP for native segwit addresses to replace
> BIP 142. These addresses are not required for segwit, but are more
> efficient, flexible, and nicer to use.
>
> The format is base 32 and uses a simple checksum algorithm with strong
> error detection properties. Reference code in several languages as
> well as a website demonstrating it are included.
>
> You can find the text here:
> https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki
>
> Cheers,
>

2023-06-07 17:57:37

- reply

📅 Original date posted:2017-03-29
📝 Original message:On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote:
> On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitcoin-dev wrote:
>> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
>> In Bitcoin Wallet, I use Base 43 (alphabet:
>> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
>> code encoding. I only leave out the space character because it gets
>> replaced by "+" in URLs.
>
> Doing that only makes addresses a few % shorter, at the cost of significant
> downsides. For example, not everyone knows what those additional characters
> are called, particularly for non-English-speaking users. Non-alphanumeric
> characters also complicate using the addresses in a variety of contexts ('/'
> in particularly isn't valid in filenames).
I'm not convinced that transmitting addresses via voice should be a
usecase to target at. I don't understand your comment about non-english
speaking users. Obviously they cannot voice-communicate at all with
only-english-speaking users, so there is no need to communicate
voice-communicate addresses between them.
Addresses in QR codes, addresses in URLs and addresses in NFC NDEF
messages are the three most used forms.
Speaking of URLs, actually Base 32 (as well as Base 43) makes QR codes
*bigger* because due to the characters used for URL parameters (?&=)
those QR codes are locked to binary mode. To make them shorter, we'd
need to use something like "Base 64url" (or ideally Base 94 -- all
printable ASCII characters).

2023-06-07 17:56:54

- reply

📅 Original date posted:2017-03-06
📝 Original message:On 03/06/2017 06:37 AM, Tim Ruffing via bitcoin-dev wrote:
> And is the historical rate thing really necessary
> for typical applications?
Yes, it is. Basically all incoming transactions are historical, as your
wallet is likely not online when it happens.

2023-06-07 17:53:31

- reply

📅 Original date posted:2016-09-21
📝 Original message:On 09/21/2016 02:58 PM, Murch via bitcoin-dev wrote:
> Android Wallet for Bitcoin
The correct name is Bitcoin Wallet, or Bitcoin Wallet for Android (if
you want to refer to the Android version).

2023-06-07 17:53:27

- reply

📅 Original date posted:2016-09-21
📝 Original message:Just glancing over your BIP, I wonder if we should use Protobuf. It uses
this "flexible" format already and is quite compact/binary. We use
Protobuf already for the payment protocol, and there is very good tool
support.

2023-06-07 17:53:02

- reply

📅 Original date posted:2016-08-24
📝 Original message:FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
wallets do not need to scan from the beginning of the blockchain.
That doesn't mean BIP44 could not be final. There are some wallets that
interoperate on that standard and that's fine. The whole reason I
insisted on separating BIP43 from BIP44 is that someone else can come up
with a better "BIP44+" standard and not get into the way of existing
standards. I think BIP43 should be made final as well, if it isn't already.
On 08/24/2016 02:51 PM, Thomas Voegtlin via bitcoin-dev wrote:
> 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?
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:51:30

- reply

📅 Original date posted:2016-06-23
📝 Original message:On 06/22/2016 04:25 PM, Erik Aronesty via bitcoin-dev wrote:
>
> 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.
>
>
> Payment protocol is for when you buy stuff from purse.io
> <http://purse.io>, not really needed for face-to face transfers, end
> users, IMO.
What Andy said, plus there is an (unencrypted) version of BIP70 via
Bluetooth already in place. And its used in several thousand
face-to-face trades per day.

2023-06-07 17:51:16

- reply

📅 Original date posted:2016-06-21
📝 Original message:Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
because of its strong types, less vulnerability to malleability and very
good platform support. Having coded both, I can say Protobuf is not more
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
based on Protobuf, but that's another story.)
Yes, all extensions to BIP70 should go into new BIPs. Note the plural
here: if you have orthogonal ideas I strongly suggest one BIP per idea
so they can be discussed and implemented (or rejected) separately.
On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility
> is desired over the minor gains of efficiency in this protocol. Not too
> late to support JSON messages as the standard going forward
>
> - problematic reliance on merchant-supplied https (X509) as the sole
> form of mechant identification. alternate schemes (dnssec/netki), pgp
> and possibly keybase seem like good ideas. personally, i like keybase,
> since there is no reliance on the existing domain-name system (you can
> sell with a github id, for example)
>
> - missing an optional client supplied identification
>
> - lack of basic subscription support
>
> /Proposed for subscriptions:/
>
> - BIP0047 payment codes are recommended instead of wallet addresses when
> establishing subscriptions. Or, merchants can specify replacement
> addresses in ACK/NACK responses. UI confirms are /required /when there
> are no replacement addresses or payment codes used.
>
> - Wallets must confirm and store subscriptions, and are responsible for
> initiating them at the specified interval.
>
> - Intervals can /only /be from a preset list: weekly, biweekly, or 1,
> 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause
> suspension until the user re-verifies.
>
> - Wallets /may /optionally ask the user whether they want to be notified
> and confirm every interval - or not. Wallets that do not ask /must
> /notify before initiating each payment. Interval confirmations should
> begin at /least /1 day in advance of the next payment.
>
> /Proposed in general:
> /
> - JSON should be used instead of protocol buffers going forward. Easier
> to use, explain extend.
>
> - "Extendible" URI-like scheme to support multi-mode identity mechanisms
> on both payment and subscription requests. Support for keybase://,
> netki:// and others as alternates to https://.
>
> - Support for client as well as merchant multi-mode verification
>
> - Ideally, the identity verification URI scheme is somewhat
> orthogonal/independent of the payment request itself
>
> Question:
>
> Should this be a new BIP? I know netki's BIP75 is out there - but I
> think it's too specific and too reliant on the domain name system.
>
> Maybe an identity-protocol-agnostic BIP + solid implementation of a
> couple major protocols without any mention of payment URI's ... just a
> way of sending and receiving identity verified messages in general?
>
> I would be happy to implement plugins for identity protocols, if anyone
> thinks this is a good idea.
>
> Does anyone think https:// or keybase, or PGP or netki all by
> themselves, is enough - or is it always better to have an extensible
> protocol?
>
> - Erik Aronesty
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:50:44

- reply

📅 Original date posted:2016-05-14
📝 Original message:The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs
define balance retrieval never changes. This is to make sure you always
see the same balance on "same BIP" wallets (and same seed of course).
So if you want to add paths, it has to be a new BIP.
On 05/13/2016 03:16 PM, Daniel Weigl via bitcoin-dev wrote:
> Hello List,
>
> With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses.
> I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first.
>
> In my opinion there are two(?) different options:
>
> 1) Stay with the current Bip44 account, give the user for each public key the option to show it as a P2PKH-Address or a P2SH address and also scan the blockchain for both representation of each public key.
> +) This has the advantage, that the user does not need to decide or have to understand that he needs to migrate to a new account type
> -) The downside is that the wallet has to scan/look for ever twice as much addresses. In the future when we have a P2WPKH, it will be three times as much.
> -) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types
>
> 2) Define a new derivation path, parallel to Bip44, but a different 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user choose which account he want to add ("Normal account", "Witness account").
>
> m / purpose' / coin_type' / account' / change / address_index
>
> +) Wallet needs only to take care of 1 address per public key
> +) If you use more than one wallet on the same xPub/xPriv it will work or fail completely. You will notice it immediately that there is something wrong
> -) User has to understand that (s)he needs to migrate to a new account to get the benefits of SegWit
> +) Thus, its easier to make a staged roll-out, only user actively deciding to use SegWit will get it and we can catch bugs earlier.
>
> 3) other ideas?
>
> My personal favourite is pt2.
>
> Has any Bip44 compliant wallet already done any integration at this point?
>
> Thx,
> Daniel/Mycelium
>

2023-06-07 17:49:52

- reply

📅 Original date posted:2016-03-12
📝 Original message:Replying to the "fee" part of BIP75 (which as already noted should go to
a different BIP number imho):
It makes to sense to let the payee define a fee *rate*. The payee
doesn't know anything about how the payer's wallet is structured. In
extreme cases, as a payer I would keep all my tiny UTXOs (which would be
unspendable in a economic way) for the one payee who is willing to pay a
high enough rate...
Rather, I propose an absolute amount that the payee is willing to cover
should be declared.
Also, in order to avoid disputes I suggest the amount should be deducted
from the BIP70 payment message amount already. A wallet which
understands BIP75fee would add these two up for *display* puposes only.
The wallet should continue to use the existing fee policies. If it can
send the amount as specified by BIP70 and the fee is below the BIP75fee
amount, it would not mention any fees to the user. If it exceeds, it
would display just the exceeding amount.
On 03/11/2016 11:43 PM, Justin Newton via bitcoin-dev wrote:
> I think we would be open to either leaving them in, or doing a separate
> BIP. What do others think? I’d prefer to keep them together if the
> changes are non-controversial just to cut down on #of BIP’s, but thats
> not a strong preference.
>
> On Fri, Mar 11, 2016 at 3:54 AM, Andreas Schildbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I think it's a bad idea to pollute the original idea of this BIP with
> other extensions. Other extensions should go to separate BIPs,
> especially since methods to clarify the fee have nothing to do with
> secure and authenticated bi-directional BIP70 communication.
>
>
> On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote:
> > Hi everyone,
> >
> > Our BIP (officially proposed on March 1) has tentatively been assigned
> > number 75. Also, the title has been changed to "Out of Band Address
> > Exchange using Payment Protocol Encryption" to be more accurate.
> >
> > We thought it would be good to take this opportunity to add some
> > optional fields to the BIP70 paymentDetails message. The new
> fields are:
> > subtractable fee (give permission to the sender to use some of the
> > requested amount towards the transaction fee), fee per kb (the minimum
> > fee required to be accepted as zeroconf), and replace by fee
> (whether or
> > not a transaction with the RBF flag will be accepted with zeroconf). I
> > know it doesn't make much sense for merchants to accept RBF with
> > zeroconf, so that last one might be used more to explicitly refuse RBF
> > transactions (and allow the automation of choosing a setting based on
> > who you are transacting with).
> >
> > I see BIP75 as a general modernization of BIP70, so I think it
> should be
> > fine to include these extensions in the new BIP, even though these
> > fields are not specific to the features we are proposing. Please
> take a
> > look at the relevant section and let me know if anyone has any
> concerns:
> >
> https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails
> >
> > The BIP70 extensions page in our fork has also been updated.
> >
> > Thanks!
> >
> > James
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin at netki.com <mailto:justin at netki.com>
> +1.818.261.4248 <tel:+1.818.261.4248>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:49:51

- reply

📅 Original date posted:2016-03-12
📝 Original message:Yes, it makes sense. A BIP is something people refer to, either just by
its number or by URL, and with multiple orthogonal "sub-BIPs" it's
difficult to refer to. We have this problem with BIP32 already -- all HD
wallets implement the derivation part of BIP32 but almost none do
implement the hierarchy part (and use BIP43/44 instead). I tried to
split up BIP32 into two BIPs later (without any content changes), but it
was declined because of its final state.
There is no harm in using a BIP only for a small thing, BIP numbers are
infinite.
On 03/11/2016 08:32 PM, James MacWhyte via bitcoin-dev wrote:
> That's a valid point, and one we had thought of, which is why I wanted
> to get everyone's opinion. I agree the proposed field extensions have
> nothing to do with encryption, but does it make sense to propose a
> completely separate BIP for such a small thing? If that is the accepted
> way to go, we can split it into two and make a separate proposal.
>
> On Fri, Mar 11, 2016 at 5:48 AM Andreas Schildbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I think it's a bad idea to pollute the original idea of this BIP with
> other extensions. Other extensions should go to separate BIPs,
> especially since methods to clarify the fee have nothing to do with
> secure and authenticated bi-directional BIP70 communication.
>
>
> On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote:
> > Hi everyone,
> >
> > Our BIP (officially proposed on March 1) has tentatively been assigned
> > number 75. Also, the title has been changed to "Out of Band Address
> > Exchange using Payment Protocol Encryption" to be more accurate.
> >
> > We thought it would be good to take this opportunity to add some
> > optional fields to the BIP70 paymentDetails message. The new
> fields are:
> > subtractable fee (give permission to the sender to use some of the
> > requested amount towards the transaction fee), fee per kb (the minimum
> > fee required to be accepted as zeroconf), and replace by fee
> (whether or
> > not a transaction with the RBF flag will be accepted with zeroconf). I
> > know it doesn't make much sense for merchants to accept RBF with
> > zeroconf, so that last one might be used more to explicitly refuse RBF
> > transactions (and allow the automation of choosing a setting based on
> > who you are transacting with).
> >
> > I see BIP75 as a general modernization of BIP70, so I think it
> should be
> > fine to include these extensions in the new BIP, even though these
> > fields are not specific to the features we are proposing. Please
> take a
> > look at the relevant section and let me know if anyone has any
> concerns:
> >
> https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails
> >
> > The BIP70 extensions page in our fork has also been updated.
> >
> > Thanks!
> >
> > James
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:49:51

- reply

📅 Original date posted:2016-03-11
📝 Original message:I think it's a bad idea to pollute the original idea of this BIP with
other extensions. Other extensions should go to separate BIPs,
especially since methods to clarify the fee have nothing to do with
secure and authenticated bi-directional BIP70 communication.
On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote:
> Hi everyone,
>
> Our BIP (officially proposed on March 1) has tentatively been assigned
> number 75. Also, the title has been changed to "Out of Band Address
> Exchange using Payment Protocol Encryption" to be more accurate.
>
> We thought it would be good to take this opportunity to add some
> optional fields to the BIP70 paymentDetails message. The new fields are:
> subtractable fee (give permission to the sender to use some of the
> requested amount towards the transaction fee), fee per kb (the minimum
> fee required to be accepted as zeroconf), and replace by fee (whether or
> not a transaction with the RBF flag will be accepted with zeroconf). I
> know it doesn't make much sense for merchants to accept RBF with
> zeroconf, so that last one might be used more to explicitly refuse RBF
> transactions (and allow the automation of choosing a setting based on
> who you are transacting with).
>
> I see BIP75 as a general modernization of BIP70, so I think it should be
> fine to include these extensions in the new BIP, even though these
> fields are not specific to the features we are proposing. Please take a
> look at the relevant section and let me know if anyone has any concerns:
> https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails
>
> The BIP70 extensions page in our fork has also been updated.
>
> Thanks!
>
> James
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:48:08

- reply

📅 Original date posted:2016-01-26
📝 Original message:Discussion about reasoning of OP_RETURN aside, I think your
specification needs to be more precise/less ambiguous.
Here is what BIP70 currently says about PaymentDetails.outputs:
"one or more outputs where Bitcoins are to be sent. If the sum of
outputs.amount is zero, the customer will be asked how much to pay, and
the bitcoin client may choose any or all of the Outputs (if there are
more than one) for payment. If the sum of outputs.amount is non-zero,
then the customer will be asked to pay the sum, and the payment shall be
split among the Outputs with non-zero amounts (if there are more than
one; Outputs with zero amounts shall be ignored)."
As you can see, zero outputs are not ignored at all. They are used as an
indication to allow the user to set an amount. So if you'd come up with
one zero-amount OP_RETURN output, it would pop up an amount dialog.
Certainly not what you want, right?
On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote:
> It looks like my draft hasn't been approved by the mailing list so if
> anyone would like to read it it's also on Gist:
>
> https://gist.github.com/toby/9e71811d387923a71a53
>
> Luke - As stated in the Github thread, I totally understand where you're
> coming from but the fact is people *will* encode data on the blockchain
> using worse methods. For all of the reasons that OP_RETURN was a good
> idea in the first place, it's a good idea to support it in PaymentRequests.
>
> As for keyless - there's no way (that I know of) to construct a
> transaction with a zero value OP_RETURN in an environment without keys
> since the Payment Protocol is what defines the method for getting a
> transaction from a server to a wallet. You can make a custom transaction
> and execute it in the same application but without Payments there's no
> way to move transactions between two applications. You need to build the
> transaction where you execute it and thus need a key.
>
>
>
> On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr <luke at dashjr.org
> <mailto:luke at dashjr.org>> wrote:
>
> This is a bad idea. OP_RETURN attachments are tolerated (not
> encouraged!) for
> the sake of the network, since the spam cannot be outright stopped.
> If it
> could be outright stopped, it would not be reasonable to allow
> OP_RETURN. When
> it comes to the payment protocol, however, changing the current
> behaviour has
> literally no benefit to the network at all, and the changes proposed
> herein
> are clearly detrimental since it would both encourage spam, and
> potentially
> make users unwilling (maybe even unaware) participants in it. For these
> reasons, *I highly advise against publishing or implementing this
> BIP, even if
> the later mentioned issues are fixed.*
>
> On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote:
> > An example might be a merchant that adds the hash of a plain text invoice
> > to the checkout transaction. The merchant could construct the
> > PaymentRequest with the invoice hash in an OP_RETURN and pass it to the
> > customer's wallet. The wallet could then submit the transaction, including
> > the invoice hash from the PaymentRequest. The wallet will have encoded a
> > proof of purchase to the blockchain without the wallet developer having to
> > coordinate with the merchant software or add features beyond this BIP.
>
> Such a "proof" is useless without wallet support. Even if you argue
> it could
> be implemented later on, it stands to reason that a scammer will
> simply encode
> garbage if the wallet is not checking the proof-of-purchase upfront.
> To check
> it, you would also need further protocol extensions which are not
> included in
> this draft.
>
> > Merchants and Bitcoin application developers benefit from this BIP because
> > they can now construct transactions that include OP_RETURN data in a
> > keyless environment. Again, prior to this BIP, transactions that used
> > OP_RETURN (with zero value) needed to be constructed and executed in the
> > same software. By separating the two concerns, this BIP allows merchant
> > software to create transactions with OP_RETURN metadata on a server without
> > storing public or private Bitcoin keys. This greatly enhances security
> > where OP_RETURN applications currently need access to a private key to sign
> > transactions.
>
> I don't see how this has any relevance to keys at all...
>
> > ## Specification
> >
> > The specification for this BIP is straightforward. BIP70 should be fully
> > implemented with two changes:
> >
> > 1. Outputs where the script is an OP_RETURN and the value is zero should be
> > accepted by the wallet.
> > 2. Outputs where the script is an OP_RETURN and the value is greater than
> > zero should be rejected.
> >
> > This is a change from the BIP70 requirement that all zero value outputs be
> > ignored.
>
> This does not appear to be backward nor even forward compatible. Old
> clients
> will continue to use the previous behaviour and transparently omit any
> commitments. New clients on the other hand will fail to include
> commitments
> produced by old servers. In other words, it is impossible to produce
> software
> compatible with both BIP 70 and this draft, and implementing either
> would
> result in severe consequences.
>
> > As it exists today, BIP70 allows for OP_RETURN data storage at the expense
> > of permanently destroyed Bitcoin.
>
> It is better for the spammers to lose burned bitcoins, than have a
> way to
> avoid them.
>
> Luke
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:43:57

- reply

📅 Original date posted:2015-10-27
📝 Original message:On 10/26/2015 01:12 PM, Will White via bitcoin-dev wrote:
> I'm making a website to tell my bitcoin wallet program to donate to more
> than one address at a time. BIP71 needs me to include a URL to do this,
> and then the wallet has to find out the information from the URL. I'd
> prefer to just send my wallet a URI with all the information it needs to
> make the donations.
You can do this using a BIP70 payment request. It allows you to specify
several scripts (addresses) to pay to, and the individual amounts for
each script.
BIP70 payment requests can be transmitted via NFC, Bluetooth, HTTP(S),
Mail... see
https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests for
an overview.

2023-06-07 17:39:43

- reply

📅 Original date posted:2015-09-05
📝 Original message:Very cool! Thanks for tackling this.
On 09/05/2015 04:11 PM, Ken Shirriff via bitcoin-dev wrote:
> Use of the bitcoin symbol in text is inconvenient, because the bitcoin
> symbol isn't in the Unicode standard. To fix this, I've written a
> proposal to have the common B-with-vertical-bars bitcoin symbol added to
> Unicode. I've successfully proposed a new character for Unicode before,
> so I'm familiar with the process and think this has a good chance of
> succeeding. The proposal is at http://righto.com/bitcoin-unicode.pdf
>
> I received a suggestion to run this proposal by the bitcoin-dev group,
> so I hope this email is appropriate here. Endorsement by Bitcoin
> developers will help the Unicode Committee realize the importance of
> adding this symbol, so please let me know if you support this proposal.
>
> Thanks,
> Ken
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:38:26

- reply

📅 Original date posted:2015-08-29
📝 Original message:On 08/29/2015 06:31 PM, Richard Moore via bitcoin-dev wrote:
> I like the idea of having a standard for this, that all explorers (and
> even core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme,
> blockchain:// so that we can just use normal URL parsing libraries. The
> bitcoin: thing leads to additional code to mutate it into a proper URI
> before passing it to URL parsing. And I think it would be fine to
> include the type looking up. For example:
>
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
Good thinking! It might make sense to look at the existing de-facto
standard (e.g. blockexplorer.com, blockchain.info):
/tx/ for transactions
/block/ for blocks, supports both hash or height
/address/ for address

2023-06-07 17:37:39

- reply

📅 Original date posted:2015-08-21
📝 Original message:On 08/21/2015 07:55 AM, Peter Todd via bitcoin-dev wrote:
> 2) Bloom filter usage has declined significantly, as lite-SPV clients
> are moving towards using centralized, trusted, servers run by the wallet
> authors. For instance
> [Mycelium](https://github.com/mycelium-com/wallet),
> [GreenBits](https://github.com/greenaddress/GreenBits),
> [AirBitz](https://www.reddit.com/r/Bitcoin/comments/3etohn/whats_wrong_with_breadwallet/ctirou5),
> and [Electrum](https://electrum.org/#home) all fall in this category.
None of these wallets (except Electrum maybe) could gain a significant
amount of new users during the last year or so, if you look at the stats
of Google Play.
Specifically Mycelium lost a significant amount of users during the last
stress test when their centralized infrastructure was overloaded. As a
consenquence, their developer announced on Reddit to try moving the
wallet to SPV.
https://www.reddit.com/r/Bitcoin/comments/3db7qr/mycelium_servers_down/

2023-06-07 15:49:05

- reply

2023-06-07 15:42:38

- reply

📅 Original date posted:2015-07-21
📝 Original message:Hmm, the advanced QR code standards are perhaps even useful if we don't
change anything about BIP7x. Because if we can cram more data without
loosing scanning performance this maybe means also we can stay with the
data we have but improve scanning?

2023-06-07 15:34:25

- reply

📅 Original date posted:2015-05-26
📝 Original message:On 05/25/2015 11:05 PM, Peter Todd wrote:
> On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote:
>>> I see this behavior all the time. I am using the latest release, as far as I know. Version 4.30.
>>>
>>> The same behavior occurs in the Testnet3 variant of the app. Go in there with an empty wallet and receive one payment and wait for it to confirm. Then send a payment and, before it confirms, try to send another one. The wallet won't let you send the second payment. It'll say something like, "You need x.xxxxxx more bitcoins to make this payment." But if you wait for your first payment to confirm, then you'll be able to make the second payment.
>>>
>>> If it matters, I configure the app to connect only to my own trusted Bitcoin node, so I only ever have one active connection at most. I notice that outgoing payments never show as "Sent" until they appear in a block, presumably because the app never sees the transaction come in over any connection.
>>
>> Yes, that's the issue. Because you're connecting only to one node, you
>> don't get any instant confirmations -- due to a Bitcoin protocol
>> limitation you can only get them from nodes you don't post the tx to.
>
> Odd, I just tried the above as well - with multiple peers connected -
> and had the exact same problem.
It should work, I'm testing this regularly. Can you report an issue
through the app and attach your log when this happens again?

2023-06-07 15:34:24

- reply

📅 Original date posted:2015-05-25
📝 Original message:On 05/25/2015 10:03 PM, Matt Whitlock wrote:
> On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote:
>>> some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you
>>> can only spend confirmed UTXOs. I can't tell you how aggravating it is to
>>> have to tell a friend, "Oh, oops, I can't pay you yet. I have to wait for
>>> the last transaction I did to confirm first." All the more aggravating
>>> because I know, if I have multiple UTXOs in my wallet, I can make multiple
>>> spends within the same block.
>>
>> Andreas' wallet hasn't done that for years. Are you repeating this from
>> some very old memory or do you actually see this issue in reality?
>>
>> The only time you're forced to wait for confirmations is when you have an
>> unconfirmed inbound transaction, and thus the sender is unknown.
>
> I see this behavior all the time. I am using the latest release, as far as I know. Version 4.30.
>
> The same behavior occurs in the Testnet3 variant of the app. Go in there with an empty wallet and receive one payment and wait for it to confirm. Then send a payment and, before it confirms, try to send another one. The wallet won't let you send the second payment. It'll say something like, "You need x.xxxxxx more bitcoins to make this payment." But if you wait for your first payment to confirm, then you'll be able to make the second payment.
>
> If it matters, I configure the app to connect only to my own trusted Bitcoin node, so I only ever have one active connection at most. I notice that outgoing payments never show as "Sent" until they appear in a block, presumably because the app never sees the transaction come in over any connection.
Yes, that's the issue. Because you're connecting only to one node, you
don't get any instant confirmations -- due to a Bitcoin protocol
limitation you can only get them from nodes you don't post the tx to.

2023-06-07 15:34:21

- reply

📅 Original date posted:2015-05-09
📝 Original message:Actually your assumption is wrong. Bitcoin Wallet (and I think most, if
not all, other bitcoinj based wallets) picks UTXO by age, in order to
maximize priority. So it keeps the number of UTXOs low, though not as
low as if it would always pick *all* UTXOs.
On 05/09/2015 07:09 PM, Jim Phillips wrote:
> Forgive me if this idea has been suggested before, but I made this
> suggestion on reddit and I got some feedback recommending I also bring
> it to this list -- so here goes.
>
> I wonder if there isn't perhaps a simpler way of dealing with UTXO
> growth. What if, rather than deal with the issue at the protocol level,
> we deal with it at the source of the problem -- the wallets. Right now,
> the typical wallet selects only the minimum number of unspent outputs
> when building a transaction. The goal is to keep the transaction size to
> a minimum so that the fee stays low. Consequently, lots of unspent
> outputs just don't get used, and are left lying around until some point
> in the future.
>
> What if we started designing wallets to consolidate unspent outputs?
> When selecting unspent outputs for a transaction, rather than choosing
> just the minimum number from a particular address, why not select them
> ALL? Take all of the UTXOs from a particular address or wallet, send
> however much needs to be spent to the payee, and send the rest back to
> the same address or a change address as a single output? Through this
> method, we should wind up shrinking the UTXO database over time rather
> than growing it with each transaction. Obviously, as Bitcoin gains wider
> adoption, the UTXO database will grow, simply because there are 7
> billion people in the world, and eventually a good percentage of them
> will have one or more wallets with spendable bitcoin. But this idea
> could limit the growth at least.
>
> The vast majority of users are running one of a handful of different
> wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase;
> Circle; Blockchain.info; and maybe a few others. The developers of all
> these wallets have a vested interest in the continued usefulness of
> Bitcoin, and so should not be opposed to changing their UTXO selection
> algorithms to one that reduces the UTXO database instead of growing it.
>
> From the miners perspective, even though these types of transactions
> would be larger, the fee could stay low. Miners actually benefit from
> them in that it reduces the amount of storage they need to dedicate to
> holding the UTXO. So miners are incentivized to mine these types of
> transactions with a higher priority despite a low fee.
>
> Relays could also get in on the action and enforce this type of behavior
> by refusing to relay or deprioritizing the relay of transactions that
> don't use all of the available UTXOs from the addresses used as inputs.
> Relays are not only the ones who benefit the most from a reduction of
> the UTXO database, they're also in the best position to promote good
> behavior.
>
> --
> *James G. Phillips
> IV* <https://plus.google.com/u/0/113107039501292625391/posts>
> /"Don't bunt. Aim out of the ball park. Aim for the company of
> immortals." -- David Ogilvy
> /
>
> /This message was created with 100% recycled electrons. Please think
> twice before printing./
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:31:35

- reply

📅 Original date posted:2015-03-12
📝 Original message:Thy, your message threading is broken. Can you make sure your mail
program uses the correct message ID when replying?

2023-06-07 15:31:33

- reply

📅 Original date posted:2015-03-12
📝 Original message:On 03/12/2015 07:27 PM, Natanael wrote:
>
> Den 12 mar 2015 17:48 skrev "Mike Hearn" <mike at plan99.net
> <mailto:mike at plan99.net>>:
>>>
>>> b) "Creation date" is just a short-term hack.
>>
>>
>> I agree, but we need things to be easy in the short term as well as
> the long term :)
>>
>> The long term solution is clearly to have the 12 word seed be an
> encryption key for a wallet backup with all associated metadata. We're
> heading in that direction one step at a time. Unfortunately it will take
> time for wallets to start working this way, and all the pieces to fall
> into place. Restoring from the block chain will be a semi regular
> operation for users until then.
>
> This have been mentioned a few times before, and what I think is
> necessary is to create a common file format that can be interpreted by a
> library which all wallets can use. I see it as similar as the work to
> create libconsensus for parsing the blockchain.
I'm afraid this will never fly. Wallets are just too different and
that's a good thing! For example, by design choice Bitcoin Wallet and
bitcoinj doesn't support multiple accounts. How would it ever import
wallets from MultiBit or Mycelium?
Bitcoinj-based wallets could probably share the bitcoinj protobuf wallet
format (or whatever format we will be at the time of the "merge" – we
already have tons of requirements piling up!). This would mean bitcoinj
is the "consensus library equivalent" you were mentioning.

2023-06-07 15:31:31

- reply

📅 Original date posted:2015-03-12
📝 Original message:For reasonably skilled users your points are valid, but I'm sure you
also – like me – encountered the kind of user who has absolutely no clue
but thinks he understands. S/he will ignore warnings and run into
troubles. This generates a huge amount of support cases and likely tears
about lost coins.
The simple fact that someone elses broken RNG implementation/wrapper
could compromise the security of my software frightens me.
On 03/11/2015 08:04 PM, Jim wrote:
> The wallet words system isn't perfect for sure but it does help the user in two main ways:
> 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
> 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
>
> I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
>
> It can be a simple help page saying:
> "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
> If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
>
> That way users have clear instructions on how to recover their bitcoins.
> Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
>

2023-06-07 15:31:30

- reply

📅 Original date posted:2015-03-12
📝 Original message:That doesn't work for mobile wallets, because we need to consider the
offline case. To fix this, we'd need to extend BIP70 to tell the
merchant where to forward the half-signed transaction to. Then again I'm
not sure if we want that, for privacy reasons. In any case, practical
multisig is still a looong way off.
On 03/12/2015 12:50 AM, devrandom wrote:
> I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig. The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key. The oracle
> would have different security thresholds for countersigning the mobile.
>
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling.
>
> On 2015-03-11 04:22 PM, Mike Hearn wrote:
>> Users will want to have wallets shared between devices, it's as simple
>> as that, especially for mobile/desktop wallets. Trying to stop them from
>> doing that by making things gratuitously incompatible isn't the right
>> approach: they'll just find workarounds or wallet apps will learn how
>> to import seeds from other apps. Better to just explain the risks and
>> help people mitigate them.
>>
>> On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine <voisine at gmail.com
>> <mailto:voisine at gmail.com>> wrote:
>>
>> I'm not convinced that wallet seed interoperability is such a great
>> thing. There is a wide variability in the quality and security level
>> of wallet implementations and platforms. Each new device and wallet
>> software a user types their seed into increases their attack surface
>> and exposure to flaws. Their security level is reduced to the lowest
>> common denominator. I see the need for a "fire exit", certainly, but
>> we must also remember that fire exits are potential entrances for
>> intruders.
>>
>> Aaron Voisine
>> co-founder and CEO
>> breadwallet.com <http://breadwallet.com>
>>
>> On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell
>> <gmaxwell at gmail.com <mailto:gmaxwell at gmail.com>> wrote:
>>
>> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>> <ricardojdfilipe at gmail.com <mailto:ricardojdfilipe at gmail.com>>
>> wrote:
>> > i guess you look at the glass half full :)
>> > even though what you say is true, we should aim for wallets not to
>> > require those instructions, by standardizing these things in BIPs.
>> > let's hope bitcoin doesn't fail in standards as our industries have in
>> > the past...
>>
>> There are genuine principled disagreements on how some things should
>> be done. There are genuine differences in functionality.
>>
>> We cannot expect and should not expect complete compatibility.
>> If you
>> must have complete compatibility: use the same software (or
>> maybe not
>> even then, considering how poor the forward compatibility of some
>> things has been..).
>>
>> What we can hope to do, and I think the best we can hope to do,
>> is to
>> minimize the amount of gratuitous incompatibility and reduce the
>> amount of outright flawed constructions (so if there are choices
>> which
>> must be made, they're at least choices among relatively good
>> options).
>>
>> ------------------------------------------------------------------------------
>> 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
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>

2023-06-07 15:31:30

- reply

📅 Original date posted:2015-03-12
📝 Original message:On 03/12/2015 01:11 AM, Gregory Maxwell wrote:
> Ultimately, the most fundamental compatibility is guaranteed: you can
> always send your funds to another wallet. This always works and
> guarantees that you are never locked in to a single wallet. It is well
> tested and cannot drive any software in to weird or confused states.
This.

2023-06-07 15:31:25

- reply

📅 Original date posted:2015-03-11
📝 Original message: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)?

2023-06-07 15:31:24

- reply

📅 Original date posted:2015-03-02
📝 Original message:Congrats on the release! Electrum is a very nice wallet.
On 03/01/2015 04:23 PM, Thomas Voegtlin wrote:
> 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.
>
> ------------------------------------------------------------------------------
>
>
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/
>

2023-06-07 15:31:22

- reply

📅 Original date posted:2015-02-26
📝 Original message:On 02/26/2015 12:14 PM, Oleg Andreev wrote:
>
>> Base43 is the same as any BaseX standard, but using a different alphabet
>> (43 characters). It's meant to be used for efficiently storing binary
>> data into QR codes. The alphabet is picked to match the 'Alphanumeric'
>> input mode of QR codes as closely as possible, but at the same time be
>> allowed in URIs.
>
> Does it mean Base58 or Base64 take more space in QR code than Base43? Do you have an estimate of the gains?
Both Base58 and Base64 force QR codes into binary encoding. Base64 can
take 6 bits per char, binary of course has 8 bits per char. So you're
wasting 25% of space if you use Base64, a little bit more with Base58.
Base43 takes log2(43) = 5.43 bits per char, while each char uses up 5.5
bits in QR codes in 'Alphanumeric' encoding. So that's a waste of 1.3%.
Source for QR code standard: http://en.wikipedia.org/wiki/QR_code

2023-06-07 15:31:21

- reply

📅 Original date posted:2015-02-26
📝 Original message:Yeah, you'd be limited to simple usecases. X509 signing or lots of
outputs will make the QR code hard to scan. However, if all you want to
do is send to a custom script (without using P2SH) I invite you to have
a look at
https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/ui/InputParser.java#L86
https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Qr.java#L134
https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/util/Base43.java
Basically it's "BITCOIN:-" plus the payment request in Base43 encoded
form. I picked Base43, because that's optimized for QR codes.
On 02/24/2015 04:58 PM, Oleg Andreev wrote:
> Hi,
>
> I wonder if there is a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The goal is to allow device to generate a multi-output payment request on its own, without relying on the server and x509 certificates. When scanned via QR code from, say, POS, it's pretty secure, so no additional authentication needed.
>
> I'd like something like this:
>
> bitcoin:?r=data://<base64url-encoded-payment-request>
>
> If there's no standard for that, would it be a good idea to extend BIP72 this way?
> ------------------------------------------------------------------------------
> 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/
>

2023-06-07 15:31:13

- reply

📅 Original date posted:2015-02-22
📝 Original message:On 02/22/2015 11:39 PM, Eric Voskuil wrote:
> The MAC address (and resource name) should be encoded using base58. This
> is shorter than base16, is often shorter than base64, better
> standardized and does not require URI encoding, and is generally
> available to implementers.
Of course this is just a minor detail, but Base64Url is well defined,
almost always more efficient than Base58 and never less efficient, and
implemented in way more libraries and OSes than Base58. Base58 was
designed for copy-typing by humans.

2023-06-07 15:31:13

- reply

📅 Original date posted:2015-02-22
📝 Original message:Jan, this is great stuff! Thanks for sharing your experiences.
I think the 4k payments requests issue must be solvable somehow. I had
no trouble transmitting that amount via NFC, although yes a bit of delay
was noticable.
About payment_url: Protobuf allows changing optional to repeated and yes
it's backwards compatible. Which is why I'm personally against parsing
two fields rather than just one.
> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?
No it isn't. It's implemented in bitcoinj though.

2023-06-07 15:31:10

- reply

📅 Original date posted:2015-02-26
📝 Original message:On 02/23/2015 04:09 PM, Jan Vornberger wrote:
> I'm still concerned that the fact, that Bluetooth is often disabled, is a
> problem for the UX. And it's not just a one-time thing as with NFC,
> which is - in my experience - also often disabled, but then people turn
> it on and leave it on.
It's the same with Bluetooth. More and more people use audio via
Bluetooth, mostly because they use a headset or stream their music to
their stereo at home.
Those that still switch off Bluetooth all the time can simply press a
button. It can't be any easier.
> Another idea could be to request the permission BLUETOOTH_ADMIN which,
> as far as I know, allows you to programmatically turn on Bluetooth
> without user interaction.
True, but those people who switch off Bluetooth will also simply not
install the app because of that permission.
If only Android had optional permissions... )-:

2023-06-07 15:31:07

- reply

📅 Original date posted:2015-02-26
📝 Original message:On 02/24/2015 11:41 AM, Mike Hearn wrote:
> Does this not also require the BT publication of the script for a P2SH
> address?
>
>
> You mean if the URI you're serving is like this?
>
> bitcoin:3aBcD........?bt=....
>
> Yes it would. I guess then, the server would indicate both the script,
> and the key within that script that it wanted to use. A bit more complex
> but would still work to save URI space.
What if the script doesn't use any key at all?
Somehow this "re-using" the fallback address idea feels less and less
appealing to me. I think we should add our own parameter and let go of
fallback addresses as soon as possible. If will waste space during the
transition period, but after that it should make no difference any more.

2023-06-07 15:31:07

- reply

📅 Original date posted:2015-02-22
📝 Original message:On 02/22/2015 11:37 PM, Andy Schroder wrote:
> Andreas and I had a number of private discussions regarding the
> payment_url parameter. I had suggested a "additional_payment_urls"
> repeated parameter, but he didn't seem to like that idea and I
> personally am indifferent, so that is why we decided to just change
> payment_url to a repeated field. The spec is simpler without the
> "additional_payment_urls", but the wallets have to be a little bit
> smarter finding the right url they want to use in the list. It's maybe
> not a bad idea for the wallet to try all payment_url mechanisms in
> parallel. Should we add this as a recommendation to wallets in TBIP75?
I think it will cause too much chaos. My recommendation for the
payment_url field is prefer the same mechanism that was used for
fetching the payment request. Only if the recommendation fails use the
alternatives in order (or in reverse order, I'm not sure at the moment).
> Regarding the NFC data formats. I would like to clarify that the wallets
> are having those events dispatched by the android OS. The "URI" and
> "mime type" events are sent to the application in the same way as from
> other sources such as a web browser, e-mail, stand alone QR code scanner
> app, etc.. So, I don't think the wallet actually knows it is receiving
> the event from NFC.
I think it can know. The method for catching these intents is very
similar and you can reuse almost all code, but in fact you need to add
an additional line to your AndroidManifest.xml.
> That is one reason why so many existing wallets
> happen to support BIP21 payment request via NFC.
Many? Bitcoin Wallet and its forks were the only ones for about a year.
Only recently Mycelium caught up and the others still do not care I guess.
> I'm a little weary sending the "mime
> type" based format over NFC because of backwards compatibility and
> because of the long certificate chain that needs to be transferred. You
> want that tap to be as robust and fast as possible. A bluetooth
> connection can have a retry without any user interaction.
I agree whatever we do must be robust. However I see no reason why NFC
can't be robust, see my previous post.
> I don't really like the Airbitz proposal. Figuring out if your selecting
> is the right one is a real nuisance. The idea is neat in a few
> applications, but I just don't think it is going to work for people as
> the most efficient and trouble free option day to day. I realize they
> are probably doing it to work with Apple's limited functionality phones
> (and BLE is a new buzz word). However, I don't think we should base
> bitcoin around what Apple wants us to do. They've already had their war
> on bitcoin. They are going to do whatever they can to protect their NFC
> based payment system. We need to make their platform the the less
> desirable one if they are going to play the game that way. If that means
> an Airbitz like proposal is implemented as a fallback, maybe that is
> fine and POS systems need to support both, but I just don't think we
> should limit what we can do because of Apple's products capabilities.
Ack on Airbitz, and ack on our relationship to Apple (-:
> There is also the "ack" memo that I mentioned in reference [2]. I think
> we can improve upon this really. Can we make a new status field or
> different bluetooth message header? I know Andreas didn't want to change
> it because that is how his app already works, but I don't think the way
> it is is ideal.
I'm not against improving this point, but I felt the BT enhancements and
the r,r1,r2 proposals are already getting complex enough. I would like
to simplify the proposal by moving unrelated things to somewhere else.

2023-06-07 15:31:06

- reply

📅 Original date posted:2015-02-23
📝 Original message:On 02/23/2015 11:58 AM, Mike Hearn wrote:
> You're right that just sending the session key is simpler. I
> originally suggested doing ECDHE to set up an encrypted channel
> for the following reasons: [...]
I read from your answer that even if we use ECDHE, we can't use it for
every situation. So in any case we need the simple bootstrap via a
session key parameter. My suggestion is defer ECDHE for now but keep it
in mind. We can add it later I think.
> These discussions keep coming up. I think the next step is for someone
> to upgrade Andreas' wallet to support encrypted connections and the
> TBIPs, to see what happens.
I happily step up and do the implementation work on the app side. A
first step could be:
- If there is an "s" parameter present wrap the Bluetooth connections
with AES. Sounds good?

2023-06-07 15:31:06

- reply

📅 Original date posted:2015-02-23
📝 Original message:On 02/23/2015 01:18 PM, Mike Hearn wrote:
> I read from your answer that even if we use ECDHE, we can't use it for
> every situation.
>
> Which situations do you mean? I think it can be used in every situation.
> It's the opposite way around - a fixed session key in the URI cannot be
> used in every situation.
Ok sorry probably I read wrong.

2023-06-07 15:31:04

- reply

📅 Original date posted:2015-02-23
📝 Original message:I think at this point I'd like to bring back my original suggestion of
using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
transmit some secret that could be eavesdropped, but at least the
session could not be decrypted from recordings.
Anyway, establishing a "mostly secure" session is clearly an improvement
to no protection at all. If we can't find a solution to the dilemma of
how to exchange the secret, I suggest going ahead with what we have and
make the best from it.
On 02/23/2015 08:36 AM, Andy Schroder wrote:
> I agree that NFC is the best we have as far as a trust anchor that you
> are paying the right person. The thing I am worried about is the privacy
> loss that could happen if there is someone passively monitoring the
> connection. So, in response to some of your comments below and also in
> response to some of Eric Voskuil's comments in another recent e-mail:
>
> Consider some cases:
>
> If NFC is assumed private, then sending the session key over the NFC
> connection gives the payer and the payee assumed confidence that that a
> private bluetooth connection can be created.
>
> If the NFC actually isn't private, then by sending the session key over
> it means the bluetooth connection is not private. An eavesdropper can
> listen to all communication and possibly modify the communication, but
> the payer and payee won't necessarily know if eavesdropping occurs
> unless communication is also modified (which could be difficult to do
> for a really low range communication).
>
> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> unmodified but actually monitored by an eavesdropper) and use that
> public key received via NFC to encrypt a session key and send it back
> via bluetooth, to then initiate an encrypted bluetooth connection using
> that session key for the remaining communication, then the payee still
> receives payment as expected and the payer sends the payment they
> expected, and the eavesdropper doesn't see anything.
>
> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> actually modified by an eavesdropper) and use that public key received
> via NFC to encrypt a session key and send it back via bluetooth, to then
> initiate an encrypted bluetooth connection using that session key for
> the remaining communication, then the payee receives no payment and the
> attack is quickly identified because the customer receives no product
> for their payment and they notify the payee, and hopefully the problem
> remedied and no further customers are affected. The privacy loss will be
> significantly reduced and the motive for such attacks will be reduced.
> It's possible a really sophisticated modification could be done where
> the attacker encrypts and decrypts the communication and then relays to
> each party (without them knowing or any glitches detected), but I guess
> I'm not sure how easy that would be on such a close proximity device?
>
> Erick Voskuil mentioned this same problem would even occur if you had a
> hardwired connection to the payment terminal and those wires were
> compromised. I guess I still think what I am saying would be better in
> that case. There is also more obvious physical tampering required to
> mess with wires.
>
> I'm not sure if there is any trust anchor required of the payer by the
> payee, is there? Eric also mentioned a need for this. Why does the payer
> care who they are as long as they get a payment received? Just to avoid
> a sophisticated modification" that I mention above? I can see how this
> could be the case for a longer range communication (like over the
> internet), but I'm not convinced it will be easy on really short ranges?
> It's almost like the attacker would be better off to just replace the
> entire POS internals than mess with an attack like that, in which case
> everything we could do locally (other than the payment request signing
> using PKI), is useless.
>
> I'm not a cryptography expert so I apologize if there is something
> rudimentary that I am missing here.
>
> Andy Schroder
>
> On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
>> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>>> I guess we need to decide whether we want to consider NFC communication
>>> private or not. I don't know that I think it can be. An eavesdropper can
>>> place a tiny snooping device near and read the communication. If it is
>>> just passive, then the merchant/operator won't realize it's there. So, I
>>> don't know if I like your idea (mentioned in your other reply) of
>>> putting the session key in the URL is a good idea?
>> I think the "trust by proximity" is the best we've got. If we don't
>> trust the NFC link (or the QR code scan), what other options have we
>> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
>> as well of course.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:31:01

- reply

📅 Original date posted:2015-02-22
📝 Original message:On 02/23/2015 12:32 AM, Andy Schroder wrote:
> I guess we need to decide whether we want to consider NFC communication
> private or not. I don't know that I think it can be. An eavesdropper can
> place a tiny snooping device near and read the communication. If it is
> just passive, then the merchant/operator won't realize it's there. So, I
> don't know if I like your idea (mentioned in your other reply) of
> putting the session key in the URL is a good idea?
I think the "trust by proximity" is the best we've got. If we don't
trust the NFC link (or the QR code scan), what other options have we
got? Speaking the session key by voice? Bad UX, and can be eavesdropped
as well of course.

2023-06-07 15:29:57

- reply

📅 Original date posted:2015-02-06
📝 Original message:On 02/06/2015 01:36 AM, Eric Voskuil wrote:
> The main advantage of BLE over BT is that it uses much less power, with
> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
> be even greater and connection latency lower than BT. For payment
> purposes the lower bandwidth isn't much of a hit.
I'm all for extending the BT:<mac> scheme to Bluetooth LE. If you have
ideas how this can be done please let us know. I haven't had a chance to
play around with LE because none of my devices support it.
I suspect the way how Bluetooth LE transfers files (like payment
requests) is opening a plain old Bluetooth socket. If this is true, I'm
afraid Bluetooth LE would not add anything for sending the BIP70
messages back and forth. Note signed payment requests can easily be 4 kB
in size, so speed *does* matter.

2023-06-07 15:29:57

- reply

📅 Original date posted:2015-02-06
📝 Original message:On 02/06/2015 02:40 AM, Andy Schroder wrote:
> Where is a more appropriate place to discuss the other issues you have
> at length?
What's wrong with this mailing list?

2023-06-07 15:29:37

- reply

📅 Original date posted:2015-02-05
📝 Original message:Thanks Paul, for writing up your protocol!
First thoughts:
For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
publish BIP70 payment requests instead. URIs mainly stick around because
of QR codes limited capacity. BIP70 would partly address the "copycat"
problem by signing payment requests.
In your Motivation section, I miss some words about NFC. NFC already
addresses all of the usability issues mentioned and is supported by
mobile wallets since 2011. That doesn't mean your method doesn't make
sense in some situations, but I think it should be explained why to
prefer broadcasting payment requests over picking them up via near field
radio.
On 02/05/2015 09:01 AM, Paul Puey wrote:
> Airbitz has developed and implemented a method for communicating a
> bitcoin URI across Bluetooth (BLE) or any other P2P, mid range,
> wireless, broadcast medium. The currently documented implementation is
> available in our iOS and Android mobile wallet (updated Android version
> with BLE coming in about 1 week). We would like to have the BIP pulled
> into Github for review and discussion. Here is the current BIP:
>
>
> BIP: TBD
>
> Title: P2P Wireless URI transfer
>
> Authors: Thomas Baker <tom’at’airbitz.co <http://airbitz.co>>, Paul Puey
> <paul’at’airbitz.co <http://airbitz.co>>
>
> Contributors: Joey Krug <joeykrug’at’gmail.com <http://gmail.com>>
>
> Status: proposal
>
> Type: Standards Track
>
> Created: 2015-01-12
>
>
> Table of Contents
>
> *
>
> Abstract
>
> *
>
> Motivation
>
> *
>
> Specification
>
> *
>
> Compatibility
>
> *
>
> Examples
>
> *
>
> References
>
>
> Abstract
>
> This is a protocol for peer-to-peer wireless transfer of a URI request
> using an open broadcast or advertisement channel such as Bluetooth,
> Bluetooth Low Energy, or WiFi Direct.
>
>
> Motivation
>
> There are disadvantages for a merchant (requester) and customer (sender)
> to exchange a URI request using QR codes that can be eliminated by using
> wireless broadcast or advertisements.
>
> Current QR code scan method to transfer a request URI from merchant
> (Requester) to customer (Sender) is cumbersome. A usual scenario is a
> merchant with a POS terminal for order entry and a separate tablet for
> transacting payments with bitcoin, and a customer with a smartphone.
> After the order is entered, the merchant enters payment request
> information into the tablet, generates the QR code representing the URI,
> and presents this to the customer. The customer prepares to scan the QR
> code with their smartphone by maneuvering the camera to the tablet. The
> tablet screen must be relatively clean, point at the customer, and held
> steady. The smartphone camera lens must be clean, point at the tablet
> screen, come into range, and held steady to focus and wait for a QR
> scan. Environmental conditions such as bright outdoor sunlight, indoor
> spot lights, or significant distance between QR code and camera can
> create difficult and cumbersome experiences for users.
>
> Using a wireless local broadcast allows the merchant to just enter the
> payment and wait. The tablet and smartphone are not maneuvered to align
> in any way. The customer observes broadcast listings, selects the
> appropriate one from possible simultaneous broadcasts from other POS
> stations nearby, examines the URI request details such as amount, and
> decides whether to send funds, initiating a bitcoin network transfer.
> The merchant and customer then receive the transaction confirmations and
> are done with the sale. Merchant and customer devices are kept private
> and secured in their own possession.
>
> The URI and other broadcast identification (Joe’s Grill #1) only contain
> public information. However, a copycat broadcaster acting as MITM might
> duplicate the broadcast simultaneously as the merchant, attempting to
> lure the customer to send funds to the copycat. That attack is mitigated
> with this broadcast method because of the partial address in the broadcast.
>
>
> Specification
>
> Requester generates a bitcoin URI request of variable length, and a
> limited descriptive identifier string. Requester then broadcasts the
> URI’s partial public address (<paddress>) plus identifier (<id>) over a
> publicly visible wireless channel.
>
> Sender scans for broadcasts on their device, examines and selects the
> desired request by the identifier and partial address. This connects a
> data channel to Requester.
>
> Requester sends full URI back over the data channel.
>
> Sender device ensures <paddress> is part of the full URI public address
> and checks the full address integrity. Checking the broadcast and full
> URI integrity prevents a copycat device within range from copying the
> partial address and fooling the customer into sending funds to the
> copycat instead.
>
> Below is a description of the protocol through Bluetooth Smart (Low Energy).
>
> Requestor Sender - Bitcoin transaction roles
>
> Peripheral Central - Bluetooth GAP definitions
>
> Mode Mode
>
> 1 |------------->| - Requestor Advertises partial bitcoin: URI +
> Name
>
> | ... |
>
> 2 |<-------------| - Subscribe then send sender's Name,
> requesting a response
>
> 3 |------------->| - ACK
>
> 4 |<-------------| - request Read Characteristic from peripheral
>
> 5 |------------->| - Sender receives full bitcoin: URI
>
>
> 1.
>
> Peripheral advertises over a service UUID a BLE extended
> advertisement with a Scan Response containing the partial address of
> a bitcoin URI and a Name, any plain text. The entire response is
> limited to 26 characters. The first 10 make up the first 10
> characters of the bitcoin URI public address where to send bitcoin,
> and must be present. The remaining characters are any plain text
> such as “The Habit 1” or “Starbucks-Reg 1”, more human readable
> information. The partial address serves as a check against a nearby
> attacker who may try to lure a Sender into sending payment to a
> separate wallet by advertising a similar Scan Response but cannot
> replicate a public address with the same leading 10 characters and
> different trailing characters.
>
> 2.
>
> When the Central scans the advertisement, it may display the Scan
> Response in a human readable listing using the two pieces of
> information. If Central chooses this advertisement to receive the
> full request, it then subscribes to the service and writes the
> characteristic (a second UUID) with it’s own name, or a blank if not
> sending a name, to the Peripheral.
>
> 3.
>
> Peripheral gets a characteristic write request of the Central’s
> name, and acknowledges the receipt by sending a server response.
>
> 4.
>
> Central receives a characteristic write (from the response) and
> immediately requests the entire bitcoin URI by issuing a read
> request on that characteristic.
>
> 5.
>
> Peripheral receives the read request and sends the entire bitcoin
> URI over that characteristic up to 512 bytes.
>
> This ends the proposed specification as the bitcoin URI transfer is
> complete. The Sender would then normally confirm the request and decide
> whether to initiate the fund transfer.
>
>
> Compatibility
>
> There are no prior BIPs covering this.
>
>
> Examples
>
> Airbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.
>
>
> References
>
>
>
>
>
> logo
> *Paul Puey* CEO / Co-Founder, Airbitz Inc
> +1-619-850-8624 | http://airbitz.co <http://airbitz.co/> | San Diego
> <http://facebook.com/airbitz> <http://twitter.com/airbitz> <https://plus.google.com/118173667510609425617> <https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey> <https://angel.co/paul-puey>
>
> *DOWNLOAD THE AIRBITZ WALLET:*
>
> <https://play.google.com/store/apps/details?id=com.airbitz><https://itunes.apple.com/us/app/airbitz/id843536046>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:29:27

- reply

📅 Original date posted:2015-02-03
📝 Original message:On 02/03/2015 11:10 AM, Pavol Rusnak wrote:
> Another option that might make sense is the block number.
Not really IMHO. Keys can be used on multiple blockchains.

2023-06-07 15:29:27

- reply

📅 Original date posted:2015-02-03
📝 Original message:On 02/03/2015 10:33 AM, Levin Keller wrote:
> Why not have more descriptive parameters? Saving on data?
Yes. QR codes are very size sensitive.

2023-06-07 15:29:27

- reply

📅 Original date posted:2015-02-03
📝 Original message:On 02/03/2015 01:22 AM, Pavol Rusnak wrote:
> Hm, let me put the questions the other way around:
>
> What gap limit should a wallet use if it encounters h=bip32?
It should follow the spec. I know BIP32-hierarchy is short on gap
limits, which is why (amongst other reasons) I expect
BIP32-hierarchy-based wallets migrate to a better standard at some time.
> What h value should I use for myTREZOR wallets? Which is essentially a
> BIP44 wallet that produces h=bip32 xpubs with gap limit 20 ...
If it follows BIP32, h=bip32 is fine.

2023-06-07 15:29:26

- reply

📅 Original date posted:2015-02-02
📝 Original message:On 02/02/2015 03:47 PM, vv01f wrote:
>>> Uff, I would expect YYYYMMDD there so it's human readable as well.
>>
>> Those strings are not meant to be read by humans. YYYYMMDD is more
>> complicated than necessary, given that Bitcoin deals with seconds since
>> epoch everywhere.
>
> First that is a pitty .. as its simply a waste of storage.
>
> but back to Pavol's point: IMHO no harm to anything, as Bitcoin never
> has any valid timestamp below ~1230768000 (jan2009) and thus will always
> have 10 digits.. you can easily identify 8 char long timestamp as the
> proposed format.
> And there never is anything wrong with having a transparent, human
> readable option - especially when it saves 2 bytes in e.g. qr-codes.
Pavol's suggestion saves 2 chars only because its just a date. I think
the creation date should be at least precise to the hour, if not to the
minute.
But anyhow, if everyone prefers a human readble date format I will bow
to the majority.

2023-06-07 15:29:26

- reply

📅 Original date posted:2015-02-02
📝 Original message:On 02/02/2015 03:56 PM, Pavol Rusnak wrote:
> To me it seems more important to describe how addresses should be
> discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G)
> instead of how the xpub was created/obtained (bip32 vs bip44).
>
> What do you thing about changing ?h=bip32 to something like
>
> ?t=01&g=20
>
> - t=01 meaning that chains 0 and 1 should be scanned (feel free to
> change "01" into any other descriptive string)
> - g=20 meaning that gap 20 should be used
I don't think that parameterizing will work, we can't predict future
BIPs. It's the same as for BIP43, in the end we agreed on just putting
the BIP number.

2023-06-07 15:29:25

- reply

📅 Original date posted:2015-02-02
📝 Original message:On 02/02/2015 01:59 PM, Pavol Rusnak wrote:
>> It's h=bip32 for the hierarchy used and
>
> Do I understand this correctly and h=bip32 hierarchy means that both
>
> xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44
> generated xpubs as well?)
Yes, except that BIP32-hierarchy and BIP44 differ in some requirements
(e.g. gap limit).
>> c=123456 for the creation date of the wallet (in seconds since epoch).
>
> Uff, I would expect YYYYMMDD there so it's human readable as well.
Those strings are not meant to be read by humans. YYYYMMDD is more
complicated than necessary, given that Bitcoin deals with seconds since
epoch everywhere.

2023-06-07 15:29:25

- reply

📅 Original date posted:2015-02-02
📝 Original message:On 02/02/2015 12:33 PM, Mike Hearn wrote:
> I looked at what Andreas is doing a few days ago - basically it's just
> an xpub string with a ?a=b&c=d query string added to the end, with a
> hierarchy type specifier and something else I forgot, encoded into a QR
> code.
It's h=bip32 for the hierarchy used and
c=123456 for the creation date of the wallet (in seconds since epoch).
I pondered about if we should add a scheme (e.g. "bitcoin-xpub:") but
decided to start without. The only advantage I currently see would be it
could be used on Android to dispatch intents to the right app(s).

2023-06-07 15:25:43

- reply

📅 Original date posted:2014-09-15
📝 Original message:On 09/12/2014 08:43 PM, Aaron Voisine wrote:
> Should BIP72 require that signed payment requests be from the same
> domain,
Although it currently does not seem to be used that way, I'd like to see
merchants sign their payment requests but store them on their payment
processors server. Currently if you buy from Humble Bundle, all you see
is Coinbase which is unfortunate.
> and also require https?
I think that's unrealistic. HTTP is already in use, and also the
proposed spec is open to other transports, e.g. Bluetooth which is also
already in common use.

2023-06-07 15:25:43

- reply

📅 Original date posted:2014-09-15
📝 Original message:I agree that this would be another way of achieving the same goal. I'd
be fine with that if there is a majority.
However, I also see downsides of this approach:
1. It's more complicated. It touches more BIPs, and although signing is
terribly difficult its still more difficult than just hashing. E.g.
signing the payment request twice (ECC + X.509) poses the question in
which order you sign, and which signature fields to null for signing.
2. Isn't it discouraged to disclose the public key you're going to
receive coins on? (not sure about that)
3. Unlike an hash we can just re-assign to different objects (see my
proposal) I think we cannot easily do the same with a signature. It's
probably not very important to have this option, but still it should be
considered.
4. I'm afraid of the idea of re-purposing the BIP21 address. Someone
might send money to it although it isn't meant to receive money any more
(service is already using an advanced BIP70 usecase). A clear separation
into two parameters would prevent such mistakes, and as soon as the
address can go away the URL needn't be longer than it used to be.
5. A hash can be checked without knowing a secret. Are we excluding
stateless devices (e.g. proxies, smartwatches)?
Generally about the URL length discussion:
Currently we have address, amount and r, and it works well. In future we
would have h and r.
So all we need to do is make sure h not longer than address+amount. I
think this is already the case with untruncated SHA256 hashes. But I'd
be fine with truncating to maybe 192 bits to save a few characters.
On 09/12/2014 06:31 PM, Mike Hearn wrote:
> Putting aside the question of necessity for a moment, a more efficient
> approach to this would be;
>
> 1. Add another marker param like &s to the end of the URL
> 2. Add another field to PaymentRequest that contains an ECC signature
> calculated using the public key that hashes to the address in the URI
> 3. Upgraded wallets look for the additional param and if it's there,
> expect to find the PaymentDetails signed with the address key. PKI
> signing of course is still useful to provide an actual identity for
> receipts, display on hardware wallets, dispute mediation etc.
>
> This adds only a few characters to a normal backwards-compatible QR
> code, and is not hard to implement.
>
>
> On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike at plan99.net
> <mailto:mike at plan99.net>> wrote:
>
> That way we leave up to implementers to experiment with different
> lengths and figure out what the optimum is
>
>
> Ah, that's a good suggestion if we do go this way.
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:25:41

- reply

📅 Original date posted:2014-09-12
📝 Original message:On 09/12/2014 03:49 PM, Mike Hearn wrote:
> (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
> here is that a MITM intercepts the payment request, which will be
> typically requested just seconds after the QR code is vended. 80 bits of
> entropy would still be a lot and take a long time to brute force, whilst
> keeping QR codes more compact, which impacts scannability.
To put that into perspective, here is how a bitcoin: URI would look like:
bitcoin:?h=J-J-4mra0VorfffEZm5J7mBmHGKX86Dpt-TnnmC_fhE&r=http://wallet.schildbach.de/bip70/r1409992884.bitcoinpaymentrequest
(obviously for real-world usage you would optimize the "r" parameter)
I looked at the list in this doc to evaluate what's easily available:
https://code.google.com/p/guava-libraries/wiki/HashingExplained
I thought SHA1 has a bad reputation these days, and we don't save much
by using it. I don't know anything about Murmur. MD5 is clearly broken.
What hash function would you recommend?
> (2) This should *not* be necessary in the common HTTPS context.
It is. People can't check names. People don't want to check names.
People can't get certificates for lots of reasons. X.509 is centralized.
X.509 has had serious security issues in the past. And shit continues to
happen.
To sum up, X.509 can't replace the trust anchor that is established by
scanning a QR code or tapping two devices together.
> (3) This can be useful in the Bluetooth context, but then again, we
> could also do things a different way by signing with the key in the
> first part of the URI, thus avoiding the need for a hash.
Sure. But signing is harder than just calculating a hash.

2023-06-07 15:25:40

- reply

📅 Original date posted:2014-09-12
📝 Original message:On 09/12/2014 12:11 PM, Mark van Cuijk wrote:
> On 12 Sep 2014, at 11:55 , bitcoin-development-request at lists.sourceforge.net wrote:
>
>> The hash is meant to link the trust anchor (e.g. the QR code) to the
>> payment request message in a secure way. This will solve the problem
>> several apps are comparing address+amount fields as a workaround
>> instead, preventing some advanced BIP70 usecases. When these apps read a
>> matching hash, they need not compare any of the other fields.
>
> Sounds like a good plan.
>
> Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently working with some parties in a supply chain to allow a consumer payment on a retail website to automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction. This behaviour would prohibit this use case.
Hard to say, but here is my last assertion:
- Bitcoin Wallet
- Hive Bitcoin Wallet (checked by source)
- countless (> 300) forks/clones of Bitcoin Wallet
Since you're planning an advanced BIP70 usecase, you'll also have to
deal with the many wallets that don't support BIP70 at all.

2023-06-07 15:25:39

- reply

📅 Original date posted:2014-09-12
📝 Original message:This is the discussion post corresponding to this PR:
https://github.com/bitcoin/bips/pull/106
"Amend BIP72 by an "h" parameter, which contains a hash of the
PaymentRequest message that is fetched via the "r" parameter.
The hash is meant to link the trust anchor (e.g. the QR code) to the
payment request message in a secure way. This will solve the problem
several apps are comparing address+amount fields as a workaround
instead, preventing some advanced BIP70 usecases. When these apps read a
matching hash, they need not compare any of the other fields.
Thanks to Julian Haight for helping with the standard."

2023-06-07 15:24:50

- reply

📅 Original date posted:2014-08-05
📝 Original message:On 08/05/2014 05:11 PM, Mike Hearn wrote:
> Oh, I forgot to mention something important. Ridiculously, the default
> package repository Maven uses was not protected by SSL up until a few
> days ago. They made it available via SSL now, but you have to tell
> Maven about the new URL. I guess they'll do a new release where SSL is
> the default soon.
FWIW, I filed a wishlist item here:
https://jira.codehaus.org/browse/MNG-5672
and here, for the old Ubuntu versions of Maven:
https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1352418

2023-06-07 15:24:34

- reply

📅 Original date posted:2014-07-30
📝 Original message:Are you aware of bitcoinj?
http://bitcoinj.github.io/
It contains everything to plug together a basic SPV wallet and runs in
the JVM.
On 07/30/2014 09:38 AM, Caleb Roger Davis wrote:
> Yes, I was thinking something on the JVM, I have a big interest in
> Clojure right now (am a long time Java dev, since 1996).
>
> I do not know if I want to tackle writing bitcoin in Clojure, but I want
> to create a tool kit first to learn more about how it works.
>
> Caleb
>
>
> On Tue, Jul 29, 2014 at 5:12 PM, Felipe Micaroni Lalli
> <micaroni at walltime.info <mailto:micaroni at walltime.info>> wrote:
>
> May I ask you which language? I'd love to implement Bitcoin in
> Clojure or Scheme.
>
> Related:
> http://bitcoin.stackexchange.com/questions/5344/has-anyone-ported-the-bitcoin-software-to-pure-clojure
>
>
>
>
> Sincerely,
>
>
> Felipe Micaroni Lalli
>
> Walltime: https://walltime.info
> Bitcoin Paranoid Android developer
> PGP ID: 0x4c0afccfed5cde14
> BTC: 1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N
>
> On 29/07/2014, at 19:32, Caleb Roger Davis <moabtek at gmail.com
> <mailto:moabtek at gmail.com>> wrote:
>
> > I have several Bitcoin contributions I would like to make, mostly
> for learning purposes to get started:
> >
> > • I would like to contribute to unit and/or other types of
> tests (code), not production code.
> > • I would like to understand the Bitcoin code (as much as
> possible from top to bottom)
> > • I would like to write a Bitcoin wallet in another language
> (so would like to know where to get the "Bitcoin - Core Wallet"
> code, but not sure where it resides.
> > I am a seasoned software developer, but I do need direction on
> where to get started. If there is a wiki doc for new developers
> that would reduce my searching and experimentation that would be great.
> >
> > For each of the three items above, I would like to know the tools
> and frameworks I would need to understand and initially work on
> tests ( how to run the existing tests to get code coverage and find
> where coverage is needed, what is the preferred IDE and full
> development stack etc ), and also where to get started looking at
> the bitcoin core code and also the wallet code (where is the initial
> starting point and then I could trace from there ).
> >
> > Is there a separate area (github & mailing list) for core wallet
> development?
> >
> > Sincerely,
> >
> >
> > --
> > Caleb
> >
> >
> ------------------------------------------------------------------------------
> > Infragistics Professional
> > Build stunning WinForms apps today!
> > Reboot your WinForms applications with our WinForms controls.
> > Build a bridge from your legacy apps to the future.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> Caleb
> M: 801.896.3278
> https://plus.google.com/+CalebRogerDavis/about
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:58

- reply

📅 Original date posted:2014-07-15
📝 Original message:Can you provide the rationale for standard practice? For example, why
should whitespace be allowed? I regularly use trim() on any passphrase
(or other input ftm).
So what's the action point? Should we amend the spec to filter control
characters? That would get rid of the \u0000 problem.
On 07/15/2014 05:17 PM, Jeff Garzik wrote:
> Unicode guarantees that null-terminated strings still work. U+0000
> terminates a unicode (or C) string. strlen() gets the string byte
> count. mbstowcs() gets the character count.
>
> Whitespace can be problematic, but should be allowed. Control
> characters should be filtered. Emoticons probably cannot be filtered
> without substandard approaches such as character blacklists, a road
> you do not want to travel.
>
> (all this is simply standard practice)
>
>
> On Tue, Jul 15, 2014 at 9:07 AM, Eric Winer <enwiner at gmail.com> wrote:
>> I don't know for sure if the test vector is correct NFC form. But for what
>> it's worth, the Pile of Poo character is pretty easily accessible on the
>> iPhone and Android keyboards, and in this string it's already in NFC form
>> (f09f92a9 in the test result). I've certainly seen it in usernames around
>> the internet, and wouldn't be surprised to see it in passphrases entered on
>> smartphones, especially if the author of a BIP38-compatible app includes a
>> (possibly ill-advised) suggestion to have your passphrase "include special
>> characters".
>>
>> I haven't seen the NULL character on any smartphone keyboards, though - I
>> assume the iOS and Android developers had the foresight to know how much
>> havoc that would wreak on systems assuming null-terminated strings. It
>> seems unlikely that NULL would be in a real-world passphrase entered by a
>> sane user.
>>
>>
>> On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>> [+cc aaron]
>>>
>>> We recently added an implementation of BIP 38 (password protected private
>>> keys) to bitcoinj. It came to my attention that the third test vector may be
>>> broken. It gives a hex version of what the NFC normalised version of the
>>> input string should be, but this does not match the results of the Java
>>> unicode normaliser, and in fact I can't even get Python to print the names
>>> of the characters past the embedded null. I'm curious where this normalised
>>> version came from.
>>>
>>> Given that "pile of poo" is not a character I think any sane user would
>>> put into a passphrase, I question the value of this test vector. NFC form is
>>> intended to collapse things like umlaut control characters onto their prior
>>> code point, but here we're feeding the algorithm what is basically garbage
>>> so I'm not totally surprised that different implementations appear to
>>> disagree on the outcome.
>>>
>>> Proposed action: we remove this test vector as it does not represent any
>>> real world usage of the spec, or if we desperately need to verify NFC
>>> normalisation I suggest using a different, more realistic test string, like
>>> Zürich, or something written in Thai.
>>>
>>>
>>>
>>> Test 3:
>>>
>>> Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK UPSILON
>>> WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, PILE
>>> OF POO)
>>> Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
>>> Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
>>> Unencrypted private key (WIF):
>>> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
>>> Note: The non-standard UTF-8 characters in this passphrase should be NFC
>>> normalized to result in a passphrase of0xcf9300f0909080f09f92a9 before
>>> further processing
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>

2023-06-07 15:23:57

- reply

📅 Original date posted:2014-07-17
📝 Original message:Here is a good article that helped me with what's going wrong:
http://www.oracle.com/technetwork/articles/javase/supplementary-142654.html
Basically, Java is stuck at 16 bits per char due to legacy reasons. They
admit that for a new language, they would probably use 32 (or 24?) bits
per char.
\u literals express UTF-16 encoding, so you have to use 16 bits. I
learned that for codepoint 0x010400, I could write "\uD801\uDC00", which
is the UTF-16 encoding of that codepoint.
Other languages have literals for codepoints. E.g. Python can use
u"\U00010400" or HTML has 𐐀 Unfortunately, Java is missing such
a construct (at least in Java6).
On 07/17/2014 12:59 PM, Mike Hearn wrote:
> Glad we got to the bottom of that. That's quite a nasty
> compiler/language bug I must say. Not even a warning. Still, python
> crashes when trying to print the name of a null character. It wouldn't
> surprise me if there are other weird issues lurking. Would definitely
> sleep better with a more restricted character set.
>
> On 17 Jul 2014 00:04, "Andreas Schildbach" <andreas at schildbach.de
> <mailto:andreas at schildbach.de>> wrote:
>
> Please excuse me. I had a more thorough look at the original problem and
> found that the only problem with the original test case was that you
> cannot specify codepoints from the SMP using \u in Java. I always tried
> \u010400 but that doesn't work.
>
> Here is a fix for bitcoinj. The test now passes.
>
> https://github.com/bitcoinj/bitcoinj/pull/143
>
> We can (and probably should) still need to filter control chars, I'll
> have a look at that now again.
>
>
> On 07/16/2014 11:06 PM, Aaron Voisine wrote:
> > If I first remove \u0000, so the non-normalized passphrase is
> > "\u03D2\u0301\U00010400\U0001F4A9", and then NFC normalize it, it
> > becomes "\u03D3\U00010400\U0001F4A9"
> >
> > UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what
> > you got, Andreas!)
> >
> > Encoding private key:
> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
> > with this passphrase, I get a BIP38 key of:
> > 6PRW5o9FMb4hAYRQPmgcvVDTyDtr6R17VMXGLmvKjKVpGkYhBJ4uYuR9wZ
> >
> > I recommend rather than simply removing control characters from the
> > password that instead the spec require that passwords containing
> > control characters are invalid. We don't want people trying to be
> > clever and putting them in thinking they are adding to the password
> > entropy.
> >
> > Also for UI compatibility across many platforms, I'm also in favor
> > disallowing any character below U+0020 (space)
> >
> > I can submit a PR once we figure out why Andreas's passphrase was
> > different than what I got.
> >
> > Aaron Voisine
> > breadwallet.com <http://breadwallet.com>
> >
> >
> > On Wed, Jul 16, 2014 at 4:04 AM, Andreas Schildbach
> > <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
> >> Damn, I just realized that I implement only the decoding side of
> BIP38.
> >> So I cannot propose a complete test vector. Here is what I have:
> >>
> >>
> >> Passphrase: ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK
> >> UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL
> LETTER
> >> LONG I, PILE OF POO)
> >>
> >> Passphrase bytes after removing ISO control characters and NFC
> >> normalization: 0xcf933034303066346139
> >>
> >> Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
> >>
> >> Unencrypted private key (WIF):
> >> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
> >>
> >>
> >> Can someone calculate the encrypted key from it (using whatever
> >> implementation) and I will verify it decodes properly in bitcoinj?
> >>
> >>
> >>
> >> On 07/16/2014 12:46 PM, Andreas Schildbach wrote:
> >>> I will change the bitcoinj implementation and propose a new test
> vector.
> >>>
> >>>
> >>>
> >>> On 07/16/2014 11:29 AM, Mike Hearn wrote:
> >>>> Yes sorry, you're right, the issue starts with the null code point.
> >>>> Python seems to have problems starting there too. It might work
> if we
> >>>> took that out.
> >>>>
> >>>>
> >>>> On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach
> >>>> <andreas at schildbach.de <mailto:andreas at schildbach.de>
> <mailto:andreas at schildbach.de <mailto:andreas at schildbach.de>>> wrote:
> >>>>
> >>>> Guys, you are always talking about the Unicode astral
> plane, but in fact
> >>>> its a plain old (ASCII) control character where this
> problem starts and
> >>>> likely ends: \u0000.
> >>>>
> >>>> Let's ban/filter ISO control characters and be done with
> it. Most
> >>>> control characters will never be enterable by any keyboard
> into a
> >>>> password field. Of course I assume that
> Character.isISOControl() works
> >>>> consistently across platforms.
> >>>>
> >>>>
> http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29
> >>>>
> >>>>
> >>>> On 07/16/2014 12:23 AM, Aaron Voisine wrote:
> >>>> > If the user creates a password on an iOS device with an
> astral
> >>>> > character and then can't enter that password on a JVM
> wallet, that
> >>>> > sucks. If JVMs really can't support unicode NFC then
> that's a strong
> >>>> > case to limit the spec to the subset of unicode that all
> popular
> >>>> > platforms can support, but it sounds like it might just
> be a JVM
> >>>> > string library bug that could hopefully be reported and
> fixed. I get
> >>>> > the same result as in the test case using apple's
> >>>> > CFStringNormalize(passphrase, kCFStringNormalizationFormC);
> >>>> >
> >>>> > Aaron Voisine
> >>>> > breadwallet.com <http://breadwallet.com>
> <http://breadwallet.com>
> >>>> >
> >>>> >
> >>>> > On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn
> <mike at plan99.net <mailto:mike at plan99.net>
> >>>> <mailto:mike at plan99.net <mailto:mike at plan99.net>>> wrote:
> >>>> >> Yes, we know, Andreas' code is indeed doing normalisation.
> >>>> >>
> >>>> >> However it appears the output bytes end up being
> different. What
> >>>> I get back
> >>>> >> is:
> >>>> >>
> >>>> >> cf930001303430300166346139
> >>>> >>
> >>>> >> vs
> >>>> >>
> >>>> >> cf9300f0909080f09f92a9
> >>>> >>
> >>>> >> from the spec.
> >>>> >>
> >>>> >> I'm not sure why. It appears this is due to the
> character from
> >>>> the astral
> >>>> >> planes. Java is old and uses 16 bit characters
> internally - it
> >>>> wouldn't
> >>>> >> surprise me if there's some weirdness that means it
> doesn't/won't
> >>>> support
> >>>> >> this kind of thing.
> >>>> >>
> >>>> >> I recommend instead that any implementation that wishes
> to be
> >>>> compatible
> >>>> >> with JVM based wallets (I suspect Android is the same) just
> >>>> refuse any
> >>>> >> passphrase that includes characters outside the BMP. At
> least
> >>>> unless someone
> >>>> >> can find a fix. I somehow doubt this will really hurt
> anyone.
> >>>> >>
> >>>> >>
> >>>>
> ------------------------------------------------------------------------------
> >>>> >> Want fast and easy access to all the code in your
> enterprise?
> >>>> Index and
> >>>> >> search up to 200,000 lines of code with a free copy of
> Black Duck
> >>>> >> Code Sight - the same software that powers the world's
> largest code
> >>>> >> search on Ohloh, the Black Duck Open Hub! Try it now.
> >>>> >> http://p.sf.net/sfu/bds
> >>>> >> _______________________________________________
> >>>> >> Bitcoin-development mailing list
> >>>> >> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> >>>> <mailto:Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>>
> >>>> >>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> ------------------------------------------------------------------------------
> >>>> > Want fast and easy access to all the code in your enterprise?
> >>>> Index and
> >>>> > search up to 200,000 lines of code with a free copy of
> Black Duck
> >>>> > Code Sight - the same software that powers the world's
> largest code
> >>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
> >>>> > http://p.sf.net/sfu/bds
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> Want fast and easy access to all the code in your
> enterprise? Index and
> >>>> search up to 200,000 lines of code with a free copy of
> Black Duck
> >>>> Code Sight - the same software that powers the world's
> largest code
> >>>> search on Ohloh, the Black Duck Open Hub! Try it now.
> >>>> http://p.sf.net/sfu/bds
> >>>> _______________________________________________
> >>>> Bitcoin-development mailing list
> >>>> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> >>>> <mailto:Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>>
> >>>>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> Want fast and easy access to all the code in your enterprise?
> Index and
> >>>> search up to 200,000 lines of code with a free copy of Black Duck
> >>>> Code Sight - the same software that powers the world's largest code
> >>>> search on Ohloh, the Black Duck Open Hub! Try it now.
> >>>> http://p.sf.net/sfu/bds
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Bitcoin-development mailing list
> >>>> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Want fast and easy access to all the code in your enterprise?
> Index and
> >>> search up to 200,000 lines of code with a free copy of Black Duck
> >>> Code Sight - the same software that powers the world's largest code
> >>> search on Ohloh, the Black Duck Open Hub! Try it now.
> >>> http://p.sf.net/sfu/bds
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Want fast and easy access to all the code in your enterprise?
> Index and
> >> search up to 200,000 lines of code with a free copy of Black Duck
> >> Code Sight - the same software that powers the world's largest code
> >> search on Ohloh, the Black Duck Open Hub! Try it now.
> >> http://p.sf.net/sfu/bds
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise?
> Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:55

- reply

📅 Original date posted:2014-07-16
📝 Original message:Ok, I just fixed the String filtering so that it can handle SMP chars
and my implementation behaves exactly like in your modified testcase
quoted below.
Bitcoinj code available on this branch, in case we decide to change the
spec:
https://github.com/schildbach/bitcoinj/commits/bip38-normalize-control-characters
On 07/17/2014 12:02 AM, Andreas Schildbach wrote:
> Please excuse me. I had a more thorough look at the original problem and
> found that the only problem with the original test case was that you
> cannot specify codepoints from the SMP using \u in Java. I always tried
> \u010400 but that doesn't work.
>
> Here is a fix for bitcoinj. The test now passes.
>
> https://github.com/bitcoinj/bitcoinj/pull/143
>
> We can (and probably should) still need to filter control chars, I'll
> have a look at that now again.
>
>
> On 07/16/2014 11:06 PM, Aaron Voisine wrote:
>> If I first remove \u0000, so the non-normalized passphrase is
>> "\u03D2\u0301\U00010400\U0001F4A9", and then NFC normalize it, it
>> becomes "\u03D3\U00010400\U0001F4A9"
>>
>> UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what
>> you got, Andreas!)
>>
>> Encoding private key: 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
>> with this passphrase, I get a BIP38 key of:
>> 6PRW5o9FMb4hAYRQPmgcvVDTyDtr6R17VMXGLmvKjKVpGkYhBJ4uYuR9wZ
>>
>> I recommend rather than simply removing control characters from the
>> password that instead the spec require that passwords containing
>> control characters are invalid. We don't want people trying to be
>> clever and putting them in thinking they are adding to the password
>> entropy.
>>
>> Also for UI compatibility across many platforms, I'm also in favor
>> disallowing any character below U+0020 (space)
>>
>> I can submit a PR once we figure out why Andreas's passphrase was
>> different than what I got.
>>
>> Aaron Voisine
>> breadwallet.com
>>
>>
>> On Wed, Jul 16, 2014 at 4:04 AM, Andreas Schildbach
>> <andreas at schildbach.de> wrote:
>>> Damn, I just realized that I implement only the decoding side of BIP38.
>>> So I cannot propose a complete test vector. Here is what I have:
>>>
>>>
>>> Passphrase: ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK
>>> UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER
>>> LONG I, PILE OF POO)
>>>
>>> Passphrase bytes after removing ISO control characters and NFC
>>> normalization: 0xcf933034303066346139
>>>
>>> Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
>>>
>>> Unencrypted private key (WIF):
>>> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
>>>
>>>
>>> Can someone calculate the encrypted key from it (using whatever
>>> implementation) and I will verify it decodes properly in bitcoinj?
>>>
>>>
>>>
>>> On 07/16/2014 12:46 PM, Andreas Schildbach wrote:
>>>> I will change the bitcoinj implementation and propose a new test vector.
>>>>
>>>>
>>>>
>>>> On 07/16/2014 11:29 AM, Mike Hearn wrote:
>>>>> Yes sorry, you're right, the issue starts with the null code point.
>>>>> Python seems to have problems starting there too. It might work if we
>>>>> took that out.
>>>>>
>>>>>
>>>>> On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach
>>>>> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>>>>>
>>>>> Guys, you are always talking about the Unicode astral plane, but in fact
>>>>> its a plain old (ASCII) control character where this problem starts and
>>>>> likely ends: \u0000.
>>>>>
>>>>> Let's ban/filter ISO control characters and be done with it. Most
>>>>> control characters will never be enterable by any keyboard into a
>>>>> password field. Of course I assume that Character.isISOControl() works
>>>>> consistently across platforms.
>>>>>
>>>>> http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29
>>>>>
>>>>>
>>>>> On 07/16/2014 12:23 AM, Aaron Voisine wrote:
>>>>> > If the user creates a password on an iOS device with an astral
>>>>> > character and then can't enter that password on a JVM wallet, that
>>>>> > sucks. If JVMs really can't support unicode NFC then that's a strong
>>>>> > case to limit the spec to the subset of unicode that all popular
>>>>> > platforms can support, but it sounds like it might just be a JVM
>>>>> > string library bug that could hopefully be reported and fixed. I get
>>>>> > the same result as in the test case using apple's
>>>>> > CFStringNormalize(passphrase, kCFStringNormalizationFormC);
>>>>> >
>>>>> > Aaron Voisine
>>>>> > breadwallet.com <http://breadwallet.com>
>>>>> >
>>>>> >
>>>>> > On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net
>>>>> <mailto:mike at plan99.net>> wrote:
>>>>> >> Yes, we know, Andreas' code is indeed doing normalisation.
>>>>> >>
>>>>> >> However it appears the output bytes end up being different. What
>>>>> I get back
>>>>> >> is:
>>>>> >>
>>>>> >> cf930001303430300166346139
>>>>> >>
>>>>> >> vs
>>>>> >>
>>>>> >> cf9300f0909080f09f92a9
>>>>> >>
>>>>> >> from the spec.
>>>>> >>
>>>>> >> I'm not sure why. It appears this is due to the character from
>>>>> the astral
>>>>> >> planes. Java is old and uses 16 bit characters internally - it
>>>>> wouldn't
>>>>> >> surprise me if there's some weirdness that means it doesn't/won't
>>>>> support
>>>>> >> this kind of thing.
>>>>> >>
>>>>> >> I recommend instead that any implementation that wishes to be
>>>>> compatible
>>>>> >> with JVM based wallets (I suspect Android is the same) just
>>>>> refuse any
>>>>> >> passphrase that includes characters outside the BMP. At least
>>>>> unless someone
>>>>> >> can find a fix. I somehow doubt this will really hurt anyone.
>>>>> >>
>>>>> >>
>>>>> ------------------------------------------------------------------------------
>>>>> >> Want fast and easy access to all the code in your enterprise?
>>>>> Index and
>>>>> >> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> >> Code Sight - the same software that powers the world's largest code
>>>>> >> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> >> http://p.sf.net/sfu/bds
>>>>> >> _______________________________________________
>>>>> >> Bitcoin-development mailing list
>>>>> >> Bitcoin-development at lists.sourceforge.net
>>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>> >>
>>>>> >
>>>>> >
>>>>> ------------------------------------------------------------------------------
>>>>> > Want fast and easy access to all the code in your enterprise?
>>>>> Index and
>>>>> > search up to 200,000 lines of code with a free copy of Black Duck
>>>>> > Code Sight - the same software that powers the world's largest code
>>>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> > http://p.sf.net/sfu/bds
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:54

- reply

📅 Original date posted:2014-07-16
📝 Original message:Please excuse me. I had a more thorough look at the original problem and
found that the only problem with the original test case was that you
cannot specify codepoints from the SMP using \u in Java. I always tried
\u010400 but that doesn't work.
Here is a fix for bitcoinj. The test now passes.
https://github.com/bitcoinj/bitcoinj/pull/143
We can (and probably should) still need to filter control chars, I'll
have a look at that now again.
On 07/16/2014 11:06 PM, Aaron Voisine wrote:
> If I first remove \u0000, so the non-normalized passphrase is
> "\u03D2\u0301\U00010400\U0001F4A9", and then NFC normalize it, it
> becomes "\u03D3\U00010400\U0001F4A9"
>
> UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what
> you got, Andreas!)
>
> Encoding private key: 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
> with this passphrase, I get a BIP38 key of:
> 6PRW5o9FMb4hAYRQPmgcvVDTyDtr6R17VMXGLmvKjKVpGkYhBJ4uYuR9wZ
>
> I recommend rather than simply removing control characters from the
> password that instead the spec require that passwords containing
> control characters are invalid. We don't want people trying to be
> clever and putting them in thinking they are adding to the password
> entropy.
>
> Also for UI compatibility across many platforms, I'm also in favor
> disallowing any character below U+0020 (space)
>
> I can submit a PR once we figure out why Andreas's passphrase was
> different than what I got.
>
> Aaron Voisine
> breadwallet.com
>
>
> On Wed, Jul 16, 2014 at 4:04 AM, Andreas Schildbach
> <andreas at schildbach.de> wrote:
>> Damn, I just realized that I implement only the decoding side of BIP38.
>> So I cannot propose a complete test vector. Here is what I have:
>>
>>
>> Passphrase: ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK
>> UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER
>> LONG I, PILE OF POO)
>>
>> Passphrase bytes after removing ISO control characters and NFC
>> normalization: 0xcf933034303066346139
>>
>> Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
>>
>> Unencrypted private key (WIF):
>> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
>>
>>
>> Can someone calculate the encrypted key from it (using whatever
>> implementation) and I will verify it decodes properly in bitcoinj?
>>
>>
>>
>> On 07/16/2014 12:46 PM, Andreas Schildbach wrote:
>>> I will change the bitcoinj implementation and propose a new test vector.
>>>
>>>
>>>
>>> On 07/16/2014 11:29 AM, Mike Hearn wrote:
>>>> Yes sorry, you're right, the issue starts with the null code point.
>>>> Python seems to have problems starting there too. It might work if we
>>>> took that out.
>>>>
>>>>
>>>> On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach
>>>> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>>>>
>>>> Guys, you are always talking about the Unicode astral plane, but in fact
>>>> its a plain old (ASCII) control character where this problem starts and
>>>> likely ends: \u0000.
>>>>
>>>> Let's ban/filter ISO control characters and be done with it. Most
>>>> control characters will never be enterable by any keyboard into a
>>>> password field. Of course I assume that Character.isISOControl() works
>>>> consistently across platforms.
>>>>
>>>> http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29
>>>>
>>>>
>>>> On 07/16/2014 12:23 AM, Aaron Voisine wrote:
>>>> > If the user creates a password on an iOS device with an astral
>>>> > character and then can't enter that password on a JVM wallet, that
>>>> > sucks. If JVMs really can't support unicode NFC then that's a strong
>>>> > case to limit the spec to the subset of unicode that all popular
>>>> > platforms can support, but it sounds like it might just be a JVM
>>>> > string library bug that could hopefully be reported and fixed. I get
>>>> > the same result as in the test case using apple's
>>>> > CFStringNormalize(passphrase, kCFStringNormalizationFormC);
>>>> >
>>>> > Aaron Voisine
>>>> > breadwallet.com <http://breadwallet.com>
>>>> >
>>>> >
>>>> > On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net
>>>> <mailto:mike at plan99.net>> wrote:
>>>> >> Yes, we know, Andreas' code is indeed doing normalisation.
>>>> >>
>>>> >> However it appears the output bytes end up being different. What
>>>> I get back
>>>> >> is:
>>>> >>
>>>> >> cf930001303430300166346139
>>>> >>
>>>> >> vs
>>>> >>
>>>> >> cf9300f0909080f09f92a9
>>>> >>
>>>> >> from the spec.
>>>> >>
>>>> >> I'm not sure why. It appears this is due to the character from
>>>> the astral
>>>> >> planes. Java is old and uses 16 bit characters internally - it
>>>> wouldn't
>>>> >> surprise me if there's some weirdness that means it doesn't/won't
>>>> support
>>>> >> this kind of thing.
>>>> >>
>>>> >> I recommend instead that any implementation that wishes to be
>>>> compatible
>>>> >> with JVM based wallets (I suspect Android is the same) just
>>>> refuse any
>>>> >> passphrase that includes characters outside the BMP. At least
>>>> unless someone
>>>> >> can find a fix. I somehow doubt this will really hurt anyone.
>>>> >>
>>>> >>
>>>> ------------------------------------------------------------------------------
>>>> >> Want fast and easy access to all the code in your enterprise?
>>>> Index and
>>>> >> search up to 200,000 lines of code with a free copy of Black Duck
>>>> >> Code Sight - the same software that powers the world's largest code
>>>> >> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> >> http://p.sf.net/sfu/bds
>>>> >> _______________________________________________
>>>> >> Bitcoin-development mailing list
>>>> >> Bitcoin-development at lists.sourceforge.net
>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>> >>
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > Want fast and easy access to all the code in your enterprise?
>>>> Index and
>>>> > search up to 200,000 lines of code with a free copy of Black Duck
>>>> > Code Sight - the same software that powers the world's largest code
>>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> > http://p.sf.net/sfu/bds
>>>> >
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>> Code Sight - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:53

- reply

📅 Original date posted:2014-07-16
📝 Original message:Damn, I just realized that I implement only the decoding side of BIP38.
So I cannot propose a complete test vector. Here is what I have:
Passphrase: ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK
UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER
LONG I, PILE OF POO)
Passphrase bytes after removing ISO control characters and NFC
normalization: 0xcf933034303066346139
Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
Unencrypted private key (WIF):
5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
Can someone calculate the encrypted key from it (using whatever
implementation) and I will verify it decodes properly in bitcoinj?
On 07/16/2014 12:46 PM, Andreas Schildbach wrote:
> I will change the bitcoinj implementation and propose a new test vector.
>
>
>
> On 07/16/2014 11:29 AM, Mike Hearn wrote:
>> Yes sorry, you're right, the issue starts with the null code point.
>> Python seems to have problems starting there too. It might work if we
>> took that out.
>>
>>
>> On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach
>> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>>
>> Guys, you are always talking about the Unicode astral plane, but in fact
>> its a plain old (ASCII) control character where this problem starts and
>> likely ends: \u0000.
>>
>> Let's ban/filter ISO control characters and be done with it. Most
>> control characters will never be enterable by any keyboard into a
>> password field. Of course I assume that Character.isISOControl() works
>> consistently across platforms.
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29
>>
>>
>> On 07/16/2014 12:23 AM, Aaron Voisine wrote:
>> > If the user creates a password on an iOS device with an astral
>> > character and then can't enter that password on a JVM wallet, that
>> > sucks. If JVMs really can't support unicode NFC then that's a strong
>> > case to limit the spec to the subset of unicode that all popular
>> > platforms can support, but it sounds like it might just be a JVM
>> > string library bug that could hopefully be reported and fixed. I get
>> > the same result as in the test case using apple's
>> > CFStringNormalize(passphrase, kCFStringNormalizationFormC);
>> >
>> > Aaron Voisine
>> > breadwallet.com <http://breadwallet.com>
>> >
>> >
>> > On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net
>> <mailto:mike at plan99.net>> wrote:
>> >> Yes, we know, Andreas' code is indeed doing normalisation.
>> >>
>> >> However it appears the output bytes end up being different. What
>> I get back
>> >> is:
>> >>
>> >> cf930001303430300166346139
>> >>
>> >> vs
>> >>
>> >> cf9300f0909080f09f92a9
>> >>
>> >> from the spec.
>> >>
>> >> I'm not sure why. It appears this is due to the character from
>> the astral
>> >> planes. Java is old and uses 16 bit characters internally - it
>> wouldn't
>> >> surprise me if there's some weirdness that means it doesn't/won't
>> support
>> >> this kind of thing.
>> >>
>> >> I recommend instead that any implementation that wishes to be
>> compatible
>> >> with JVM based wallets (I suspect Android is the same) just
>> refuse any
>> >> passphrase that includes characters outside the BMP. At least
>> unless someone
>> >> can find a fix. I somehow doubt this will really hurt anyone.
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Want fast and easy access to all the code in your enterprise?
>> Index and
>> >> search up to 200,000 lines of code with a free copy of Black Duck
>> >> Code Sight - the same software that powers the world's largest code
>> >> search on Ohloh, the Black Duck Open Hub! Try it now.
>> >> http://p.sf.net/sfu/bds
>> >> _______________________________________________
>> >> Bitcoin-development mailing list
>> >> Bitcoin-development at lists.sourceforge.net
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Want fast and easy access to all the code in your enterprise?
>> Index and
>> > search up to 200,000 lines of code with a free copy of Black Duck
>> > Code Sight - the same software that powers the world's largest code
>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>> > http://p.sf.net/sfu/bds
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>

2023-06-07 15:23:52

- reply

📅 Original date posted:2014-07-16
📝 Original message:Guys, you are always talking about the Unicode astral plane, but in fact
its a plain old (ASCII) control character where this problem starts and
likely ends: \u0000.
Let's ban/filter ISO control characters and be done with it. Most
control characters will never be enterable by any keyboard into a
password field. Of course I assume that Character.isISOControl() works
consistently across platforms.
http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29
On 07/16/2014 12:23 AM, Aaron Voisine wrote:
> If the user creates a password on an iOS device with an astral
> character and then can't enter that password on a JVM wallet, that
> sucks. If JVMs really can't support unicode NFC then that's a strong
> case to limit the spec to the subset of unicode that all popular
> platforms can support, but it sounds like it might just be a JVM
> string library bug that could hopefully be reported and fixed. I get
> the same result as in the test case using apple's
> CFStringNormalize(passphrase, kCFStringNormalizationFormC);
>
> Aaron Voisine
> breadwallet.com
>
>
> On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net> wrote:
>> Yes, we know, Andreas' code is indeed doing normalisation.
>>
>> However it appears the output bytes end up being different. What I get back
>> is:
>>
>> cf930001303430300166346139
>>
>> vs
>>
>> cf9300f0909080f09f92a9
>>
>> from the spec.
>>
>> I'm not sure why. It appears this is due to the character from the astral
>> planes. Java is old and uses 16 bit characters internally - it wouldn't
>> surprise me if there's some weirdness that means it doesn't/won't support
>> this kind of thing.
>>
>> I recommend instead that any implementation that wishes to be compatible
>> with JVM based wallets (I suspect Android is the same) just refuse any
>> passphrase that includes characters outside the BMP. At least unless someone
>> can find a fix. I somehow doubt this will really hurt anyone.
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>

2023-06-07 15:23:52

- reply

📅 Original date posted:2014-07-16
📝 Original message:I will change the bitcoinj implementation and propose a new test vector.
On 07/16/2014 11:29 AM, Mike Hearn wrote:
> Yes sorry, you're right, the issue starts with the null code point.
> Python seems to have problems starting there too. It might work if we
> took that out.
>
>
> On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach
> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>
> Guys, you are always talking about the Unicode astral plane, but in fact
> its a plain old (ASCII) control character where this problem starts and
> likely ends: \u0000.
>
> Let's ban/filter ISO control characters and be done with it. Most
> control characters will never be enterable by any keyboard into a
> password field. Of course I assume that Character.isISOControl() works
> consistently across platforms.
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29
>
>
> On 07/16/2014 12:23 AM, Aaron Voisine wrote:
> > If the user creates a password on an iOS device with an astral
> > character and then can't enter that password on a JVM wallet, that
> > sucks. If JVMs really can't support unicode NFC then that's a strong
> > case to limit the spec to the subset of unicode that all popular
> > platforms can support, but it sounds like it might just be a JVM
> > string library bug that could hopefully be reported and fixed. I get
> > the same result as in the test case using apple's
> > CFStringNormalize(passphrase, kCFStringNormalizationFormC);
> >
> > Aaron Voisine
> > breadwallet.com <http://breadwallet.com>
> >
> >
> > On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net
> <mailto:mike at plan99.net>> wrote:
> >> Yes, we know, Andreas' code is indeed doing normalisation.
> >>
> >> However it appears the output bytes end up being different. What
> I get back
> >> is:
> >>
> >> cf930001303430300166346139
> >>
> >> vs
> >>
> >> cf9300f0909080f09f92a9
> >>
> >> from the spec.
> >>
> >> I'm not sure why. It appears this is due to the character from
> the astral
> >> planes. Java is old and uses 16 bit characters internally - it
> wouldn't
> >> surprise me if there's some weirdness that means it doesn't/won't
> support
> >> this kind of thing.
> >>
> >> I recommend instead that any implementation that wishes to be
> compatible
> >> with JVM based wallets (I suspect Android is the same) just
> refuse any
> >> passphrase that includes characters outside the BMP. At least
> unless someone
> >> can find a fix. I somehow doubt this will really hurt anyone.
> >>
> >>
> ------------------------------------------------------------------------------
> >> Want fast and easy access to all the code in your enterprise?
> Index and
> >> search up to 200,000 lines of code with a free copy of Black Duck
> >> Code Sight - the same software that powers the world's largest code
> >> search on Ohloh, the Black Duck Open Hub! Try it now.
> >> http://p.sf.net/sfu/bds
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise?
> Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> >
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:49

- reply

📅 Original date posted:2014-07-15
📝 Original message:I think generally control-characters (such as \u0000) should be
disallowed in passphrases. (Even the use of whitespaces is very
questionable.)
I'm ok with allowing pile-of-poo's. On mobile phones there is keyboards
just containing emoticons -- why not allow those? Assuming NFC works of
course.
On 07/15/2014 03:07 PM, Eric Winer wrote:
> I don't know for sure if the test vector is correct NFC form. But for
> what it's worth, the Pile of Poo character is pretty easily accessible
> on the iPhone and Android keyboards, and in this string it's already in
> NFC form (f09f92a9 in the test result). I've certainly seen it in
> usernames around the internet, and wouldn't be surprised to see it in
> passphrases entered on smartphones, especially if the author of a
> BIP38-compatible app includes a (possibly ill-advised) suggestion to
> have your passphrase "include special characters".
>
> I haven't seen the NULL character on any smartphone keyboards, though -
> I assume the iOS and Android developers had the foresight to know how
> much havoc that would wreak on systems assuming null-terminated strings.
> It seems unlikely that NULL would be in a real-world passphrase entered
> by a sane user.
>
>
> On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn <mike at plan99.net
> <mailto:mike at plan99.net>> wrote:
>
> [+cc aaron]
>
> We recently added an implementation of BIP 38 (password protected
> private keys) to bitcoinj. It came to my attention that the third
> test vector may be broken. It gives a hex version of what the NFC
> normalised version of the input string should be, but this does not
> match the results of the Java unicode normaliser, and in fact I
> can't even get Python to print the names of the characters past the
> embedded null. I'm curious where this normalised version came from.
>
> Given that "pile of poo" is not a character I think any sane user
> would put into a passphrase, I question the value of this test
> vector. NFC form is intended to collapse things like umlaut control
> characters onto their prior code point, but here we're feeding the
> algorithm what is basically garbage so I'm not totally surprised
> that different implementations appear to disagree on the outcome.
>
> Proposed action: we remove this test vector as it does not represent
> any real world usage of the spec, or if we desperately need to
> verify NFC normalisation I suggest using a different, more realistic
> test string, like Zürich, or something written in Thai.
>
>
>
> Test 3:
>
> * Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK
> UPSILON WITH HOOK <http://codepoints.net/U+03D2>, COMBINING
> ACUTE ACCENT <http://codepoints.net/U+0301>, NULL
> <http://codepoints.net/U+0000>, DESERET CAPITAL LETTER LONG I
> <http://codepoints.net/U+10400>, PILE OF POO
> <http://codepoints.net/U+1F4A9>)
> * Encrypted key:
> 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
> * Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
> * Unencrypted private key (WIF):
> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
> * /Note:/ The non-standard UTF-8 characters in this passphrase
> should be NFC normalized to result in a passphrase
> of0xcf9300f0909080f09f92a9 before further processing
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:25

- reply

📅 Original date posted:2014-07-01
📝 Original message:Ok, one more idea:
r= is used for the first URL, and we *think* of it as r0=
additional URLs are appended as
r1=
r2=
and so on. This would also define an ordering in case we need it.
On 07/01/2014 05:07 PM, Michael Wozniak wrote:
> Multiple parameters is currently undefined as far as I can tell. Should the client take the first, last, or ignore it completely if there are multiple of any parameter? I think that’s the point of the parameter pollution discussion, which will define it one way or the other.
>
> I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions).
>
> -
> Michael Wozniak
>
> On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas at schildbach.de> wrote:
>
>> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
>> advocate for a simple array parameter name, like rs= ("plural" of r).
>> Length really does matter for QR codes.
>>
>> I'm fine with either multiple r= params or exactly one r= plus zero to
>> many r[]= params. Although I think it is a violation of the (current)
>> spec to choke on more than one r= parameters, I admit that bitcoinj is
>> currently implemented that way. (We could however fix this in a
>> maintenance release.)
>>
>> However, r= should also allow all other protocols, exactly like any of
>> the r[]= params. I don't think we should do a distinction here. Also
>> because of backwards compatibility to the status quo.
>>
>>
>> On 07/01/2014 03:03 PM, Alex Kotenko wrote:
>>> In my mind it's not like the client's phone is going all directions at
>>> the same time. There should be a priority method and fallback method(s).
>>> And I see p2p radio as priority, and web as fallback, and BIP21 in the
>>> end as always-working-default.
>>>
>>> So I'm keeping support for it all while want to be able to provide best
>>> user experience.
>>> Mike, a while ago in this thread you've described contactless cards
>>> user experience. I'm also using contactless cards often, and what I'm
>>> aiming at is creating same level of user experience for Bitcoin users.
>>>
>>> Encryption over bluetooth is a matter to worry about, and we will
>>> introduce that, but we need to sort out more low level problems first
>>> before coming into that stage.
>>>
>>>
>>> So, the backwards compatibility is a good issue Michael pointed out.
>>> While processing of multiple "r" parameters is indeed uncertain (since
>>> there is no RFC for that various implementations may behave
>>> differently), the array solution is somewhat better. The array parameter
>>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
>>> alongside. And if particular implementation understands the array
>>> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
>>> use only usual "r=".
>>>
>>> This doens't work though for cases where particular implementation
>>> understands array construct but doesn't work well with repeating
>>> parameters, since it will see two repeating "r" - an array and a string.
>>> I don't have a solution for that atm.
>>>
>>>
>>> If add completely new parameter to solve this we will need to make it an
>>> array straight away to address upcoming issues with accommodating other
>>> protocols.
>>> And then I would also modify existing BIP72 to strictly define "r=" as
>>> "http(s)" only parameter, while all other protocols (bluetooth, WiFi
>>> Direct, ultrasound, chirp etc) should go to the new array parameter.
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:24

- reply

📅 Original date posted:2014-07-01
📝 Original message:On 07/01/2014 10:18 AM, Mike Hearn wrote:
> However it's not ideal at the moment. Basically the main problem is
> that in the BIP72 there is no way to provide a fallback alternative
> URI for payment request fetch if client wallet supports BIP70 but
> doesn't not support fetching over bluetooth or bluetooth connection
> fails for any reason.
I think the way to go here is using multiple r= parameters.
> So the idea here is that the recipient wallet both uploads to the
> internet and exposes the payment request over Bluetooth simultaneously,
> then let's the sending wallet pick whatever radio layer works best in
> its current conditions?
Either that, or just use the other ones as a fallback. Currently,
Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=
URL fails.
> I think having multiple r= params is reasonable, but the Bluetooth
> support is not specced in any BIP anyway. And if it were to be, people
> would point out the lack of link-layer encryption.
Its "specced" in code and implemented by several parties. I think its
clear that link-layer encryption has to be an add-on to the current
unencrypted connection, just like HTTPS is on top of HTTP. Anyway,
that's unrelated to the question of how to provide fallback URLs.
One more thought: We have a similar problem with the BIP70 payment URL.
It doesn't allow for fallbacks either. I brought this issue up in the
discussion phase of BIP70, but it was dismissed I think because of
"let's not get too complex for the first version". The fallback here is
to send the transaction via the P2P network.
(I think BIP70 via P2P radio will get used more often in future. I plan
to look into Bluetooth 4 LE as soon as I have devices and wanted to try
WIFI Direct again also. I hope we can skip BIP72 for both of those, but
lets see.)

2023-06-07 15:23:24

- reply

📅 Original date posted:2014-07-01
📝 Original message:Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
advocate for a simple array parameter name, like rs= ("plural" of r).
Length really does matter for QR codes.
I'm fine with either multiple r= params or exactly one r= plus zero to
many r[]= params. Although I think it is a violation of the (current)
spec to choke on more than one r= parameters, I admit that bitcoinj is
currently implemented that way. (We could however fix this in a
maintenance release.)
However, r= should also allow all other protocols, exactly like any of
the r[]= params. I don't think we should do a distinction here. Also
because of backwards compatibility to the status quo.
On 07/01/2014 03:03 PM, Alex Kotenko wrote:
> In my mind it's not like the client's phone is going all directions at
> the same time. There should be a priority method and fallback method(s).
> And I see p2p radio as priority, and web as fallback, and BIP21 in the
> end as always-working-default.
>
> So I'm keeping support for it all while want to be able to provide best
> user experience.
> Mike, a while ago in this thread you've described contactless cards
> user experience. I'm also using contactless cards often, and what I'm
> aiming at is creating same level of user experience for Bitcoin users.
>
> Encryption over bluetooth is a matter to worry about, and we will
> introduce that, but we need to sort out more low level problems first
> before coming into that stage.
>
>
> So, the backwards compatibility is a good issue Michael pointed out.
> While processing of multiple "r" parameters is indeed uncertain (since
> there is no RFC for that various implementations may behave
> differently), the array solution is somewhat better. The array parameter
> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> alongside. And if particular implementation understands the array
> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
> use only usual "r=".
>
> This doens't work though for cases where particular implementation
> understands array construct but doesn't work well with repeating
> parameters, since it will see two repeating "r" - an array and a string.
> I don't have a solution for that atm.
>
>
> If add completely new parameter to solve this we will need to make it an
> array straight away to address upcoming issues with accommodating other
> protocols.
> And then I would also modify existing BIP72 to strictly define "r=" as
> "http(s)" only parameter, while all other protocols (bluetooth, WiFi
> Direct, ultrasound, chirp etc) should go to the new array parameter.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:23:20

- reply

📅 Original date posted:2014-06-24
📝 Original message:I think it should be made more clear what's the reference price for the
discount. In Germany, we generally don't use credit cards but rather
"EC-Cards", which is already much cheaper. Or maybe for some merchants
the only alternative is cash, and they would still offer a Bitcoin discount.
Also, currently PR are created by the payment processors afaik. How can
they know what other payment option the merchant provides and what's the
conditions? Maybe we should first solve the signature delegation problem
so that the merchant can create the request.
Although I'm sure this feature will get abused, I (as a wallet author)
would be willing to give it a try. I agree with Jeff that the name of
the field should start with something like "marketing".
On 06/24/2014 03:27 PM, Mike Hearn wrote:
> Coinbase have started allowing merchants to set discounts for purchasing
> with Bitcoin. Seeing an individual discount is not very motivating as
> they tend to be small. Seeing them stack up over time can be more
> motivating because it feels like free money. Many businesses exploit
> this effect with loyalty points, etc. Bitcoin should do this too - show
> the user how much they're saving by using Bitcoin instead of credit cards.
>
> I suggested to Charlie Lee (who pushed this through at Coinbase) and
> Stephen Pair the following minor BIP 70 extension:
>
>
> message PaymentDetails {
> // Size in satoshis of any discount provided by the merchant ONLY
> // because the user chose to pay using Bitcoin or other similar
> // digital currency. Other kinds of discounts, loyalty bonuses and
> // so on should not be recorded here, rather they could be mentioned
> // in the memo field. This field exists so wallets can show the user
> // a running total of how much money they have saved by avoiding
> // credit cards and bank payments; the goal is to encourage people to
> // use Bitcoin. Putting other kinds of discounts here would make the
> // running total calculated meaningless; so don't do it!
> optional uint64 currency_usage_discount_size = 8;
> }
>
> Wallets would then be able to persist this data to disk and compete on
> cool visualisations for how much money you saved over time.
>
> We haven't formalised how to extend BIP 70 yet, that's my fault. We
> should do that. In the meantime, what do people think of this proposal?
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:22:40

- reply

📅 Original date posted:2014-06-15
📝 Original message:Yes I meant only the "supports_instant" is not needed.
"trusted_instant_providers" makes sense to me.
Generally I like the simplicity of this BIP. Still, I have more questions:
What is the use of the Transactions message? Note the Payment message
already contains a transactions field that could be signed. Can you
briefly describe the whole flow of messages on an example, including the
BIP70 messages?
Should we allow adding multiple signatures (from different instant
providers or maybe while transitioning to another PKI)?
On 06/15/2014 11:22 AM, Lawrence Nahum wrote:
> Andreas Schildbach <andreas <at> schildbach.de> writes:
>
>> Just a quick comment:
>>
>> The supports_instant field seems redundant to me. First, as per your
>> spec, you can derive it from trusted_instant_providers. And second, why
>> do you need it at all? Protobuf is designed so it will simply ignore
>> fields you don't know. So you can just send the instant_* fields in the
>> Payment message without harm.
>
>
>
> Agreed, supports_instant is redundant and can/should/will go.
>
> trusted_instant_providers on the other hand I think is needed.
>
> Sometimes the providers will charge fees for instant.
>
> While the software can ignore the fields,
> users may not want to pay for instant when the merchant may not accept it or
> care (even if it would not break the protocol it would still be a waste of
> fees)
>
> Does it make sense?
>
> Not all transactions from GreenAddress provide double spend protection, there
> are additional checks on prevout that are normally not done when spending
> normally, etc
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
>

2023-06-07 15:22:40

- reply

📅 Original date posted:2014-06-14
📝 Original message:Just a quick comment:
The supports_instant field seems redundant to me. First, as per your
spec, you can derive it from trusted_instant_providers. And second, why
do you need it at all? Protobuf is designed so it will simply ignore
fields you don't know. So you can just send the instant_* fields in the
Payment message without harm.
On 06/14/2014 02:00 PM, Lawrence Nahum wrote:
> Hello,
>
> I had the pleasure to meet some of you in Amsterdam and/or to speak on
> #bitcoin-dev but this is actually my first message to the mailing list -
> I feel a bit clumsy so apologies in advance if I make any mistake :)
>
> Quick introduction/background: my name is Lawrence Nahum and I'm the
> founder of GreenAddress, a BIP32 multisignature service and instant
> confirmation platform available in form of web socket APIs and Wallet
> for mobile, desktop and web. My background is in CS with distributed
> systems and I've worked most of my career in the City on OTC financial
> services like confirmation and clearing platforms.
>
> This post is to gather feedback, comments and reviews about a BIP70
> payment protocol proto buffer extension proposal.
>
> https://github.com/greenaddress/bips/blob/bip-payment-request-instant-confirmations/bip-payment-request-instant-confirmations.mediawiki
>
> If you are interested in GreenAddress design or for more information on
> GreenAddress you can find the white paper
> here http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf
> and our homepage on https://greenaddress.it
>
> Cheers,
> Lawrence
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>