<unnamed>

Public Key

npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7

Profile Code

nprofile1qqsry9dn6a7l78uya66663hmzgr235t90vl2wedgpd2gnm8r5upd90qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds08gh2c

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:16:37 UTC

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

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

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

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

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

- 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:06:24 UTC

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

- 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:22 UTC

- 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 17:53:02 UTC

- 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:16 UTC

- 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:39:43 UTC

- 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:37:39 UTC

- 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:42:38 UTC

- 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:31:35 UTC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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:25:43 UTC

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

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

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

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

- 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:23:55 UTC

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

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

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

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

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

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

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

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

- 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:22:40 UTC

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

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

2023-06-07 15:21:59 UTC

- reply

📅 Original date posted:2014-05-26
📝 Original message:On 05/27/2014 12:39 AM, Peter Todd wrote:
> On 27 May 2014 01:12:05 GMT+03:00, Andreas Schildbach
> <andreas at schildbach.de> wrote:
>> You're very quick to point at others. Especially since they run
>> software that had the time to mature for about 30 years, and the
>> protocol didn't really change since then...
>
>> The last time it didn't work, the bug -- non RFC-conformance --
>> was on the bitcoin seeders side. ISPs do weird things with DNS,
>> but usually they stay within the RFC.
>
>> Anyway, without logs we don't have a chance to debug this issue.
>> Any chance you could add simple logging to the seeder?
>
>> DNS via HTTP? Never heard of that, at least it sounds weird as
>> well.
>
> Hey, really sorry I don't have the time to fix this issue, been
> travelling for a few weeks for my consulting job. If you want to
> step up and volunteer please feel free.
I'm already volunteering. At least I don't get paid for my efforts in
debugging the seed infrastructure.
Can you verify if your copy of the seeder contains the commit
8dcc006e6256cb746c2b025daf3df41baa26353e ?
It fixed a bug that has exactly the symptoms we currently see.
I wonder if the restart of your server actually changed/fixed
anything. If you got a SERVFAIL this may be because you were traveling
through parts of the world that can't reach your server. Did you
actually try at home, before the restart?

2023-06-07 15:21:58 UTC

- reply

📅 Original date posted:2014-05-26
📝 Original message:You're very quick to point at others. Especially since they run software
that had the time to mature for about 30 years, and the protocol didn't
really change since then...
The last time it didn't work, the bug -- non RFC-conformance -- was on
the bitcoin seeders side. ISPs do weird things with DNS, but usually
they stay within the RFC.
Anyway, without logs we don't have a chance to debug this issue. Any
chance you could add simple logging to the seeder?
DNS via HTTP? Never heard of that, at least it sounds weird as well.
On 05/26/2014 06:37 PM, Peter Todd wrote:
> On Sun, May 25, 2014 at 09:12:10PM +0200, Andreas Schildbach wrote:
>> Thanks for looking at the issue.
>>
>> Unfortunately, it still fails for me:
>>
>> $ nslookup testnet-seed.bitcoin.petertodd.org
>> Server: 127.0.1.1
>> Address: 127.0.1.1#53
>>
>> ** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL
>>
>> Like I said, can you look at the logfiles how the requests arrive?
>
> There are no logfiles for DNS requests.
>
> I just checked on EC2 and my cellphone internet connection here in Tel
> Aviv; both work fine. My best guess is that your DNS resolver locally or
> at your ISP is unable to deal with the fact that the second DNS seed
> serving the domain testnet-seed.bitcoin.petertodd.org happens to be down
> right now. Note that some ISP's appear to both run buggy DNS servers,
> and redirect traffic meant to go to Google's 8.8.8 and 8.8.4.4 DNS
> servers to their own servers.
>
> I'd suggest that someone setup an alternate HTTP(S) based DNS seed for
> protocol redundency.
>
>> What particular thing did you fix? It would be good to know for future
>> outages.
>
> Dunno exactly. It appeared to be running fine when I logged into the
> machine, but for whatever reason DNS requests just weren't getting
> resolved. Restarted and it was ok again.
>
>
>
> ------------------------------------------------------------------------------
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&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:21:57 UTC

- reply

📅 Original date posted:2014-05-25
📝 Original message:Thanks for looking at the issue.
Unfortunately, it still fails for me:
$ nslookup testnet-seed.bitcoin.petertodd.org
Server: 127.0.1.1
Address: 127.0.1.1#53
** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL
Like I said, can you look at the logfiles how the requests arrive?
What particular thing did you fix? It would be good to know for future
outages.
On 05/24/2014 12:17 AM, Peter Todd wrote:
> FWIW
>
> That said, keep in mind the github discussion(1) that was had: if all
> the DNS seeds being down breaks your application, your application is
> broken and insecure. The only exception is initial startup, and even
> then you should have fallbacks such as hardcoded node lists and manual
> peer entry. If for some reason you really do need instant startup, run
> your own centralized high-availability/low-latency nodes; either way
> you're depending on a centralized resource.
>
> 1) https://github.com/bitcoin/bitcoin/pull/4203

2023-06-07 15:21:27 UTC

- reply

📅 Original date posted:2014-05-21
📝 Original message:Great, thanks for this contribution!
Do you plan to have your seeds reachable on port 53 eventually?
Currently bitcoinj cannot deal with nonstandard ports I think.
On 05/21/2014 11:23 AM, Alex Kotenko wrote:
> okay, I've set it up with bind forwarding requests to two dnsseeds
> running on separate ports. Though I see a problem with testnet DNS seed
> itself. It runs, but somehow it only returns one IP address. Exactly
> same DNS seeder looking for mainnet nodes is working fine.
>
> You can reach seeds through
> mainnet seed:
> dig @node.alexykot.me <http://node.alexykot.me> bitcoin-seed.alexykot.me
> <http://bitcoin-seed.alexykot.me> A
> or directly
> dig -p 8353 @node.alexykot.me <http://node.alexykot.me>
> bitcoin-seed.alexykot.me <http://bitcoin-seed.alexykot.me> A
>
> testnet seed
> dig @node.alexykot.me <http://node.alexykot.me> testnet-seed.alexykot.me
> <http://testnet-seed.alexykot.me> A
> or directly
> dig -p 18353 @node.alexykot.me <http://node.alexykot.me>
> testnet-seed.alexykot.me <http://testnet-seed.alexykot.me> A
>
> So what can be the problem with testnet DNS seeder?
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-20 1:50 GMT+01:00 Robert McKay <robert at mckay.com
> <mailto:robert at mckay.com>>:
>
> On Tue, 20 May 2014 01:44:29 +0100, Robert McKay wrote:
> > On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote:
> >> On Mon, May 19, 2014 at 4:36 PM, Robert McKay <robert at mckay.com
> <mailto:robert at mckay.com>>
> >> wrote:
> >>> It should be possible to configure bind as a DNS forwarder.. this
> >>> can
> >>> be done in a zone context.. then you can forward the different
> >>> zones
> >>> to
> >>> different dnsseed daemons running on different non-public IPs or
> >>> two
> >>> different ports on the same IP (or on one single non-public IP
> >>> since
> >>> there's really no reason to expose the dnsseed directly daemon at
> >>> all).
> >>
> >> Quite the opposite. dnsseed data rotates through a lot of addresses
> >> if available. Using the bind/zone-xfer system would result in fewer
> >> total addresses going through to the clients, thanks to the addition
> >> of caching levels that the bind/zone-xfer system brings.
> >>
> >> That said, if the choice is between no-service and bind, bind it is
> >> ;p
> >
> > Setting it up as a zone forwarder causes each request to go through
> > to
> > the dnsseed backend for each request.
>
> This stackoverflow describes a similar situation;
>
> http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone
>
> you can additionally specify the port to forward too;
>
> http://www.zytrax.com/books/dns/ch7/queries.html#forwarders
>
> it should be possible to forward to different ports on 127.0.0.1 for
> each dnsseed instance.
>
> Rob
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:21:25 UTC

- reply

📅 Original date posted:2014-05-17
📝 Original message:On 05/17/2014 02:02 PM, Alex Kotenko wrote:
> So, my understanding is that atm we have no working DNS seeds at the
> testnet3, right? There are two DNS seeds known, of which one is
> unreachable atm, and another one is giving just one IP address, which is
> also a dead node.
Yes, that's my understanding too.
> If I'll start a DNS seed of my own and make sure it works well, will
> this help?
Yes, definately.
> I've found this DNS seeder daemon
> <https://github.com/sipa/bitcoin-seeder>, and it seems to be exactly
> what I need to run a DNS seeder myself.
Afaik this is what most of the other seeds are using, yes.
> So if my understanding is correct, I'll setup a DNS seeds for mainnet
> and for testnet at bitcoin-seed.alexykot.me
> <http://bitcoin-seed.alexykot.me> and testnet-seed.alexykot.me
> <http://testnet-seed.alexykot.me>, and also a well connected nodes for
> mainnet and testnet on the same server.
> Is this a good plan? Will this all help?
Sound great! Let me know if you've got something to test.

2023-06-07 15:21:24 UTC

- reply

📅 Original date posted:2014-05-17
📝 Original message:I think the best way to contribute to the infrastructure is actually
what we're doing: Test the current infrastructure and point out where it
is not working. Trying to find solutions for problems.
There is nothing gained by throwing additional hardware at a problem if
the problem itself isn't understood well.
On 05/17/2014 02:58 AM, Alex Kotenko wrote:
> Ok, what do I need to do? How do I host a testnet seed myself?
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-16 23:02 GMT+01:00 Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>>:
>
> There are only two testnet seeds listed in bitcoind, and one of them
> returns SERVFAIL (testnet-seed.bitcoin.petertodd.org
> <http://testnet-seed.bitcoin.petertodd.org>) and the other
> just returns one A record (testnet-seed.bluematt.me
> <http://testnet-seed.bluematt.me>). No idea what
> seeds bitcoinj uses.
>
> If you are going to depend on testnet, especially for an important
> demo... contribute to the infrastructure! This stuff doesn't just fix
> itself for free.

2023-06-07 15:21:22 UTC

- reply

📅 Original date posted:2014-05-16
📝 Original message:Apparently British Telecom also cannot speak to Peter Todd's server.
That another very large ISP in Europe.
On 05/15/2014 01:50 PM, Andreas Schildbach wrote:
> I'm bringing this issue up again. The current Bitcoin DNS seed
> infrastructure is unstable. I assume this is because of we're using a
> custom DNS implementation which is not 100% compatible. There have been
> bugs in the past, like a case sensitive match for the domain name.
>
> Current state (seeds taken from bitcoinj):
>
> mainnet:
>
> seed.bitcoin.sipa.be OK
> dnsseed.bluematt.me OK
> dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs
> seed.bitcoinstats.com OK
>
> testnet:
>
> testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica
> testnet-seed.bluematt.me OK (but only returns one node)
>
> Note: Telefonica is one of Europe's largest ISPs.
>
> I would try to improve DNS myself, but I'm not capable of writing C. My
> "fix" would be to reimplement everything in Java -- I doubt you guys
> would be happy with that.
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>

2023-06-07 15:21:21 UTC

- reply

📅 Original date posted:2014-05-16
📝 Original message:On 05/15/2014 07:48 PM, Gregory Maxwell wrote:
> On Thu, May 15, 2014 at 4:50 AM, Andreas Schildbach
> <andreas at schildbach.de> wrote:
>> I'm bringing this issue up again. The current Bitcoin DNS seed
>> infrastructure is unstable. I assume this is because of we're using a
>> custom DNS implementation which is not 100% compatible. There have been
>> bugs in the past, like a case sensitive match for the domain name.
>
> If software is using the DNS seeds in a way where one or two being
> unavailable is problematic, then the software may be using them
> poorly.
>
> Generally DNS seeds should only be used as fast connectivity hints,
> primarily for initial connectivity. Relying on them exclusively
> increases isolation vulnerabilities (e.g. because the dns seed
> operators or any ISP or network attacker on the path between you and
> the seeds can replace the results with ones that isolate you on a
> bogus network).
I just used "nslookup", after seeing the issues in bitcoinj.
I agree that clients should be robust regarding DNS lookups (and
bitcoinj isn't), but still I think the first step needs to be
maintaining a quality infrastructure.

2023-06-07 15:21:20 UTC

- reply

📅 Original date posted:2014-05-15
📝 Original message:I'm bringing this issue up again. The current Bitcoin DNS seed
infrastructure is unstable. I assume this is because of we're using a
custom DNS implementation which is not 100% compatible. There have been
bugs in the past, like a case sensitive match for the domain name.
Current state (seeds taken from bitcoinj):
mainnet:
seed.bitcoin.sipa.be OK
dnsseed.bluematt.me OK
dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs
seed.bitcoinstats.com OK
testnet:
testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica
testnet-seed.bluematt.me OK (but only returns one node)
Note: Telefonica is one of Europe's largest ISPs.
I would try to improve DNS myself, but I'm not capable of writing C. My
"fix" would be to reimplement everything in Java -- I doubt you guys
would be happy with that.

2023-06-07 15:18:05 UTC

- reply

📅 Original date posted:2014-04-08
📝 Original message:On 04/08/2014 02:43 PM, slush wrote:
> After some off-list discussion about details with wallet developers, it
> seems that structure
>
> m/<cointype>'/<account>'/<change>/<n>
>
> fulfill requirements of all wallet developers around, including
> myTrezor, Electrum, Multibit, Wallet32 and other software is willing to
> adapt once anything will be standardized (i.e. they don't care).
>
> Because I think that everybody told their comments to the topic already
> and because it seems that there's quite wide agreement on that, I would
> like to close the discussion and finally implement these paths into our
> software.
While there is an agreement that a standard would be useful for sharing
wallets, we certainly didn't agree on every aspect of a standard. At
least not on this thread, and also not at the Berlin meeting.
I understand each client will implement things a little bit different,
for example the current plan is bitcoinj will hold all keys in memory
and start reusing keys on low resources. Electrum uses a chain for their
private purpose. Etc.
If we cannot 100% agree on a standard and also agree it will not be
extended in future, I think we should not even try. It's dangerous for
the money of users.
I propose we keep our chains deliberately separate and only try
standardizing after each of us has a feel for the specific requirements.

2023-06-07 15:17:32 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:They're _not_ phasing out into SPV wallets from what I can say. At
around the 24th of February, there has been a sharp change of the
"current installs" graph of Bitcoin Wallet. That number used to grow at
about 20.000 per month. After that date until now, it just barely moves
horizontal.
My guess is that a large number of users have lost interest after they
lost their money in MtGox. The 24th of February coincides with the
"final" shutdown, according to
http://en.wikipedia.org/wiki/Mt._Gox#February_2014_shutdown_and_bankruptcy
On 04/07/2014 02:17 PM, Ricardo Filipe wrote:
> phasing out of bitcoinqt into spv wallets?
>
> 2014-04-07 12:34 GMT+01:00 Mike Hearn <mike at plan99.net>:
>> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
>> still falling:
>>
>> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>>
>> I know all the reasons why people might stop running a node (uses too much
>> disk space, bandwidth, lost interest etc). But does anyone have any idea how
>> we might get more insight into what's really going on? It'd be convenient if
>> the subVer contained the operating system, as then we could tell if the
>> bleed was mostly from desktops/laptops (Windows/Mac), which would be
>> expected, or from virtual servers (Linux), which would be more concerning.
>>
>> When you set up a Tor node, you can add your email address to the config
>> file and the Tor project sends you emails from time to time about things you
>> should know about. If we did the same, we could have a little exit survey:
>> if your node disappears for long enough, we could email the operator and ask
>> why they stopped.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees_APR
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
>

2023-06-07 15:16:26 UTC

- reply

📅 Original date posted:2014-03-28
📝 Original message:Ok, why don't fix this in the spec for now, by defining a fixed expiry
time. In the EU, most products are covered by a 2 years warranty, so it
seems appropriate to pick 2.5 years (30 months) -- allowing for some
time to ship the product back and forth.
On 03/28/2014 12:31 PM, Mike Hearn wrote:
> On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach
> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>
> However, I don't see how PaymentDetails can be an answer. None of the
> fields (other than outputs and network) can be known in advance (at the
> time of the initial payment).
>
>
> You don't need all the fields indeed, but they're mostly optional
> (except time). So for the refund you'd fill out:
>
> outputs (same as today)
> time
> expiry_time
>
> You're probably aiming for an expires field? How would you refund a
> payment after expiry?
>
>
> It'd have to be ad-hoc at that point. OK, you don't get the nice UI that
> the refund field provides. Oh well. It should be rare to get refunds
> very very late after the purchase.
>
>
> Btw. another problem is that the refund address is currently
> unprotected.
>
>
> Yes indeed as is the rest of the Payment structure. We talked about
> signing it with one of the keys that's signing the Bitcoin transaction
> as well. But it seems like a bit overkill. Usually it'll be submitted
> over HTTPS or a (secured!) Bluetooth channel though so tampering with it
> should not be possible.
>
> However this does raise the question of whether a refund should be a
> full blown PaymentRequest with optional PKI signing. Normally, I think,
> a seller does not know or care about the identity of a buyer for
> refunds, outside of their own tracking system.
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:16:25 UTC

- reply

📅 Original date posted:2014-03-28
📝 Original message:I see the problem.
However, I don't see how PaymentDetails can be an answer. None of the
fields (other than outputs and network) can be known in advance (at the
time of the initial payment).
You're probably aiming for an expires field? How would you refund a
payment after expiry? Note its not your choice wether to refund a
payment -- it can be ordered by a court years after the payment happened.
Btw. another problem is that the refund address is currently unprotected.
On 03/28/2014 12:07 PM, Mike Hearn wrote:
> Modern devices like smartphones and tablets do not have swap files. This
> design is chosen to ensure responsive, fluid UI that can avoid blocking
> on disk regardless of how much multi-tasking is done, but it creates
> ripples that impact everything else.
>
> One implication of this is that on these devices, we cannot store all
> keys or transactions in memory forever. BIP 70 has an expiry field for
> PaymentRequests that we can use to allow us to eventually stop loading
> those keys into RAM - at that point payments to those keys would no
> longer be recognised. But there's no equivalent for refund addresses.
>
> More generally, though we re-used the output structure to define the
> refund, we didn't (for some reason that I forgot) reuse PaymentDetails,
> even though the payment details for a refund are indeed PaymentDetails.
>
> Though I am loathe to go back and redesign this part of BIP 70 so soon
> after we shipped v1, it seems to me like the refund feature may be hard
> to implement on phones if there's no time limit for when you can receive
> a refund. Otherwise a wallet has to be looking out for refunds for
> payments you may have made years ago. So perhaps we should add a new
> refund field that embeds a PaymentDetails structure instead of being
> just a list of outputs.
>
> We could try and solve this problem some other way purely internally, by
> doing a kind of wallet-specific swapping process in which things like
> Bloom filters are calculated without all keys in them being held in
> memory at once (perhaps caching filters for old parts of the key chain
> on disk), so you can have "infinite" wallets, but eventually the huge
> Bloom filters that would result would hurt efficiency in other ways. So
> key expiry seems pretty fundamental to scalability.
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:16:12 UTC

- reply

📅 Original date posted:2014-03-26
📝 Original message:Thanks for starting the discussion on finding a better structure.
For me, the most important thing is either we're 100% interoperable or
0%. There should not be anything inbetween, as users will delete seeds
without knowing there is still money in them on another implementation.
I heard from multiple sources that using this standard some wallets will
only see a subset of the addresses/keys of some other wallets.
Implementation differences can always happen (and should addresses as
bugs), but I think its unacceptable that this source of issues is by design.
I suggest we agree on an even simpler least common denominator and
wallets that want to implement some feature on top of that can do but
are encouraged to pick a totally different "cointype". I guess that
would mean removing reserved and account.
I'm still thinking it might be a good idea to have a separate chain for
"refunds". Refunds will be rarely used and thus need a much slower
moving window than receiving addresses or change.
On 03/26/2014 09:49 PM, Mike Hearn wrote:
> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we
> brainstormed to find a structure acceptable to everyone and ended up with:
>
> /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
> * cointype: This is zero for Bitcoin. This is here to support two
> things, one is supporting alt coins based off the same root seed.
> Right now nobody seemed very bothered about alt coins but sometimes
> feature requests do come in for this. Arguably there is no need and
> alt coins could just use the same keys as Bitcoin, but it may help
> avoid confusion if they don't.
>
> More usefully, cointype can distinguish between keys intended for
> things like multisig outputs, e.g. for watchdog services. This means
> if your wallet does not know about the extra protocol layers
> involved in this, it can still import the "raw" money and it will
> just ignore/not see the keys used in more complex transactions.
>
> * reserved is for "other stuff". I actually don't recall why we ended
> up with this. It may have been intended to split out multisig
> outputs etc from cointype. Marek, Thomas?
>
> * account is for keeping essentially wallets-within-a-wallet to avoid
> mixing of coins. If you want that.
>
> * change is 0 for receiving addresses, 1 for change addresses.
>
> * n is the actual key index
>
> For bitcoinj we're targeting a deliberately limited feature set for hdw
> v1 so I would just set the first three values all to zero and that is a
> perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet
> all the users needs, whilst still allowing some drift between what
> wallets support.
>
> Pieter made the I think valid point that you can't really encode how
> keys are meant to be used into just an HDW hierarchy and normally you'd
> need some metadata as well. However, I feel interop between wallets is
> more important than arriving at the most perfect possible arrangement,
> which feels a little like bikeshedding, so I'm happy to just go with the
> flow on this one.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:27 UTC

- reply

📅 Original date posted:2014-03-14
📝 Original message:Indeed, rounding is the obvious easy fix. Bitcoin Wallet rounds all
amounts except if you type amounts with a higher precision.
On 03/14/2014 04:32 PM, Mike Hearn wrote:
> The issue here is that most people are producing prices in BTC by just
> multiplying through the spot rate with full precision. Obviously if you
> converted dollar prices to Euro prices with the same technique, you'd
> also end up with lots of numbers after the decimal point, but in the
> real world nobody actually does this. They always "prettify" the price.
>
> This practice often annoys people because they feel like they get short
> changed. The most notorious example is Apple which likes (liked?) to
> charge 99 cents per iTunes song in the USA, and 99 pennies per song in
> the UK, despite that the British pound is worth a lot more than the
> dollar. It should be more like 60 pence.
>
> Nothing stops BitPay rounding the mBTC price to look more natural, but
> right now it's not common practice.
>
>
> On Fri, Mar 14, 2014 at 4:02 PM, Andreas Schildbach
> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>
> By that definition 3.56 is a price. Maybe I misunderstood you and you're
> lobbying for mBTC?
>
>
> On 03/14/2014 03:57 PM, Tamas Blummer wrote:
> > you miss the point Andreas. It is not about the magnitude but about
> > the form of a price.
> >
> > A number with no decimals or with two decimals is percieved as a
> > price in some currency.
> >
> > A number with more than two decimals is just not percieved as a price
> > but as a geeky something that you rather convert to local currency.
> >
> > Tamas Blummer
> > Bits of Proof
> >
> > On 14.03.2014, at 15:49, Andreas Schildbach <andreas at schildbach.de
> <mailto:andreas at schildbach.de>
> > <mailto:andreas at schildbach.de <mailto:andreas at schildbach.de>>> wrote:
> >
> >> How much do you pay for an Espresso in your local currency?
> >>
> >> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> >> people would expect. Certainly more familiar than µBTC 3558 or BTC
> >> 0.003578.
> >>
> >> Anyway, I was just sharing real-world experience: nobody is confused.
> >>
> >>
> >> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> >>> You give them a hard to interpret thing like mBTC and then wonder
> >>> why they rather look at local currency. Because the choices you
> >>> gave them are bad.
> >>>
> >>> I think Bitcoin would have a better chance to be percieved as a
> >>> currency of its own if it had prices and fractions like currencies
> >>> do.
> >>>
> >>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> >>> would be.
> >>>
> >>>
> >>> Tamas Blummer Bits of Proof
> >>>
> >>> On 14.03.2014, at 15:05, Andreas Schildbach
> <andreas at schildbach.de <mailto:andreas at schildbach.de>
> >>> <mailto:andreas at schildbach.de <mailto:andreas at schildbach.de>>>
> >>> wrote:
> >>>
> >>>> btw. None of Bitcoin Wallet's users complained about confusion
> >>>> because of the mBTC switch. In contrast, I get many mails and
> >>>> questions if exchange rates happen to differ by >10%.
> >>>>
> >>>> I suspect nobody looks at the Bitcoin price. It's the amount in
> >>>> local currency that matters to the users.
> >>>>
> >>>>
> >>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >>>>> Indeed. And users were crying for mBTC. Nobody was asking for
> >>>>> µBTC.
> >>>>>
> >>>>> I must admit I was not aware if this thread. I just watched
> >>>>> other wallets and at some point decided its time to switch to
> >>>>> mBTC.
> >>>>>
> >>>>>
> >>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >>>>>> The standard has become mBTC and that's what was adopted.
> >>>>>> It's too late to try and sway this on a mailing list thread
> >>>>>> now.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> >>>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>
> <mailto:g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>>
> >>>>>> <mailto:g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>>> wrote:
> >>>>>>
> >>>>>> The MultiBit HD view is that this is a locale-sensitive
> >>>>>> presentation issue. As a result we offer a simple
> >>>>>> configuration panel giving pretty much every possible
> >>>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
> >>>>>> mXBT, μXBT, sat along with settings for leading/trailing
> >>>>>> symbol, commas, spaces and points. This allows anyone to
> >>>>>> customise to meet their own needs beyond the offered default.
> >>>>>>
> >>>>>>
> >>>>>> We apply the NIST guidelines for representation of SI unit
> >>>>>> symbols (i.e no conversion to native language, no RTL giving
> >>>>>> icon+m etc).
> >>>>>>
> >>>>>> Right now MultiBit HD is configured to use m+icon taken from
> >>>>>> the Font Awesome icon set. However reading earlier posts it
> >>>>>> seems that μ+icon is more sensible.
> >>>>>>
> >>>>>> Let us know what you'd like.
> >>>>>>
> >>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> >>>>>> Awesome icon:
> >>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> >>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >>>>>>
> >>>>>>
> >>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>
> >>>>>> <mailto:jgarzik at bitpay.com <mailto:jgarzik at bitpay.com>>
> >>>>>> <mailto:jgarzik at bitpay.com <mailto:jgarzik at bitpay.com>>> wrote:
> >>>>>>
> >>>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
> >>>>>> several weeks ago, which was disappointing -- it sounded like
> >>>>>> the consensus was uBTC, and moving to uBTC later --which will
> >>>>>> happen-- may result in additional user confusion, thanks to
> >>>>>> yet another decimal place transition.
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:25 UTC

- reply

📅 Original date posted:2014-03-14
📝 Original message:I don't know about financial software.
I really don't get what you mean by weird notation? Bitcoin Wallet is
made for ordinary users. They are used to real-world prices like EUR
1.63 / USD 2.26 (that would be the Espresso example). How can mBTC 3.56
be weird to these people?
Granted, there are exceptions, like in Japan. Maybe those would be
better served with µBTC as default. Maybe. Up to now, outside of this
mailing list nobody requested µBTC. Then again, Japanese userbase is
tiny compared to US.
On 03/14/2014 04:12 PM, Tamas Blummer wrote:
> I think you want to misunderstand me Andreas.
>
> It is astonishing arrogance to define the units because we in Bitcoin
> are used to
> some wierd notation and ignore that the vast majority of population and
> financial software in existence does not have a notion of prices
> with more than two decimals.
>
> With 1 bit = 100 satoshi, we would solve this problem for good.
> Instead mBTC is a confusing step in-between.
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 14.03.2014, at 16:02, Andreas Schildbach <andreas at schildbach.de
> <mailto:andreas at schildbach.de>> wrote:
>
>> By that definition 3.56 is a price. Maybe I misunderstood you and you're
>> lobbying for mBTC?
>>
>>
>> On 03/14/2014 03:57 PM, Tamas Blummer wrote:
>>> you miss the point Andreas. It is not about the magnitude but about
>>> the form of a price.
>>>
>>> A number with no decimals or with two decimals is percieved as a
>>> price in some currency.
>>>
>>> A number with more than two decimals is just not percieved as a price
>>> but as a geeky something that you rather convert to local currency.
>>>
>>> Tamas Blummer
>>> Bits of Proof
>>>
>>> On 14.03.2014, at 15:49, Andreas Schildbach <andreas at schildbach.de
>>> <mailto:andreas at schildbach.de>
>>> <mailto:andreas at schildbach.de>> wrote:
>>>
>>>> How much do you pay for an Espresso in your local currency?
>>>>
>>>> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>>>> people would expect. Certainly more familiar than µBTC 3558 or BTC
>>>> 0.003578.
>>>>
>>>> Anyway, I was just sharing real-world experience: nobody is confused.
>>>>
>>>>
>>>> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>>>>> You give them a hard to interpret thing like mBTC and then wonder
>>>>> why they rather look at local currency. Because the choices you
>>>>> gave them are bad.
>>>>>
>>>>> I think Bitcoin would have a better chance to be percieved as a
>>>>> currency of its own if it had prices and fractions like currencies
>>>>> do.
>>>>>
>>>>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>>>>> would be.
>>>>>
>>>>>
>>>>> Tamas Blummer Bits of Proof
>>>>>
>>>>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas at schildbach.de
>>>>> <mailto:andreas at schildbach.de>
>>>>> <mailto:andreas at schildbach.de>>
>>>>> wrote:
>>>>>
>>>>>> btw. None of Bitcoin Wallet's users complained about confusion
>>>>>> because of the mBTC switch. In contrast, I get many mails and
>>>>>> questions if exchange rates happen to differ by >10%.
>>>>>>
>>>>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>>>>> local currency that matters to the users.
>>>>>>
>>>>>>
>>>>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>>>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>>>>>> µBTC.
>>>>>>>
>>>>>>> I must admit I was not aware if this thread. I just watched
>>>>>>> other wallets and at some point decided its time to switch to
>>>>>>> mBTC.
>>>>>>>
>>>>>>>
>>>>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>>>>>> The standard has become mBTC and that's what was adopted.
>>>>>>>> It's too late to try and sway this on a mailing list thread
>>>>>>>> now.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>>>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>
>>>>>>>> <mailto:g.rowe at froot.co.uk>
>>>>>>>> <mailto:g.rowe at froot.co.uk>> wrote:
>>>>>>>>
>>>>>>>> The MultiBit HD view is that this is a locale-sensitive
>>>>>>>> presentation issue. As a result we offer a simple
>>>>>>>> configuration panel giving pretty much every possible
>>>>>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
>>>>>>>> mXBT, μXBT, sat along with settings for leading/trailing
>>>>>>>> symbol, commas, spaces and points. This allows anyone to
>>>>>>>> customise to meet their own needs beyond the offered default.
>>>>>>>>
>>>>>>>>
>>>>>>>> We apply the NIST guidelines for representation of SI unit
>>>>>>>> symbols (i.e no conversion to native language, no RTL giving
>>>>>>>> icon+m etc).
>>>>>>>>
>>>>>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>>>>>> the Font Awesome icon set. However reading earlier posts it
>>>>>>>> seems that μ+icon is more sensible.
>>>>>>>>
>>>>>>>> Let us know what you'd like.
>>>>>>>>
>>>>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>>>>>> Awesome icon:
>>>>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
>>>>>>>> <mailto:jgarzik at bitpay.com>
>>>>>>>> <mailto:jgarzik at bitpay.com>
>>>>>>>> <mailto:jgarzik at bitpay.com>> wrote:
>>>>>>>>
>>>>>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
>>>>>>>> several weeks ago, which was disappointing -- it sounded like
>>>>>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>>>>>> happen-- may result in additional user confusion, thanks to
>>>>>>>> yet another decimal place transition.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:24 UTC

- reply

📅 Original date posted:2014-03-14
📝 Original message:By that definition 3.56 is a price. Maybe I misunderstood you and you're
lobbying for mBTC?
On 03/14/2014 03:57 PM, Tamas Blummer wrote:
> you miss the point Andreas. It is not about the magnitude but about
> the form of a price.
>
> A number with no decimals or with two decimals is percieved as a
> price in some currency.
>
> A number with more than two decimals is just not percieved as a price
> but as a geeky something that you rather convert to local currency.
>
> Tamas Blummer
> Bits of Proof
>
> On 14.03.2014, at 15:49, Andreas Schildbach <andreas at schildbach.de
> <mailto:andreas at schildbach.de>> wrote:
>
>> How much do you pay for an Espresso in your local currency?
>>
>> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>> people would expect. Certainly more familiar than µBTC 3558 or BTC
>> 0.003578.
>>
>> Anyway, I was just sharing real-world experience: nobody is confused.
>>
>>
>> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>>> You give them a hard to interpret thing like mBTC and then wonder
>>> why they rather look at local currency. Because the choices you
>>> gave them are bad.
>>>
>>> I think Bitcoin would have a better chance to be percieved as a
>>> currency of its own if it had prices and fractions like currencies
>>> do.
>>>
>>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>>> would be.
>>>
>>>
>>> Tamas Blummer Bits of Proof
>>>
>>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas at schildbach.de
>>> <mailto:andreas at schildbach.de>>
>>> wrote:
>>>
>>>> btw. None of Bitcoin Wallet's users complained about confusion
>>>> because of the mBTC switch. In contrast, I get many mails and
>>>> questions if exchange rates happen to differ by >10%.
>>>>
>>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>>> local currency that matters to the users.
>>>>
>>>>
>>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>>>> µBTC.
>>>>>
>>>>> I must admit I was not aware if this thread. I just watched
>>>>> other wallets and at some point decided its time to switch to
>>>>> mBTC.
>>>>>
>>>>>
>>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>>>> The standard has become mBTC and that's what was adopted.
>>>>>> It's too late to try and sway this on a mailing list thread
>>>>>> now.
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>
>>>>>> <mailto:g.rowe at froot.co.uk>> wrote:
>>>>>>
>>>>>> The MultiBit HD view is that this is a locale-sensitive
>>>>>> presentation issue. As a result we offer a simple
>>>>>> configuration panel giving pretty much every possible
>>>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
>>>>>> mXBT, μXBT, sat along with settings for leading/trailing
>>>>>> symbol, commas, spaces and points. This allows anyone to
>>>>>> customise to meet their own needs beyond the offered default.
>>>>>>
>>>>>>
>>>>>> We apply the NIST guidelines for representation of SI unit
>>>>>> symbols (i.e no conversion to native language, no RTL giving
>>>>>> icon+m etc).
>>>>>>
>>>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>>>> the Font Awesome icon set. However reading earlier posts it
>>>>>> seems that μ+icon is more sensible.
>>>>>>
>>>>>> Let us know what you'd like.
>>>>>>
>>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>>>> Awesome icon:
>>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>>>
>>>>>>
>>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
>>>>>> <mailto:jgarzik at bitpay.com>
>>>>>> <mailto:jgarzik at bitpay.com>> wrote:
>>>>>>
>>>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
>>>>>> several weeks ago, which was disappointing -- it sounded like
>>>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>>>> happen-- may result in additional user confusion, thanks to
>>>>>> yet another decimal place transition.

2023-06-07 15:15:22 UTC

- reply

📅 Original date posted:2014-03-14
📝 Original message:How much do you pay for an Espresso in your local currency?
At least for the Euro and the Dollar, mBTC 3.56 is very close to what
people would expect. Certainly more familiar than µBTC 3558 or BTC
0.003578.
Anyway, I was just sharing real-world experience: nobody is confused.
On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> You give them a hard to interpret thing like mBTC and then wonder
> why they rather look at local currency. Because the choices you
> gave them are bad.
>
> I think Bitcoin would have a better chance to be percieved as a
> currency of its own if it had prices and fractions like currencies
> do.
>
> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> would be.
>
>
> Tamas Blummer Bits of Proof
>
> On 14.03.2014, at 15:05, Andreas Schildbach <andreas at schildbach.de>
> wrote:
>
>> btw. None of Bitcoin Wallet's users complained about confusion
>> because of the mBTC switch. In contrast, I get many mails and
>> questions if exchange rates happen to differ by >10%.
>>
>> I suspect nobody looks at the Bitcoin price. It's the amount in
>> local currency that matters to the users.
>>
>>
>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>> µBTC.
>>>
>>> I must admit I was not aware if this thread. I just watched
>>> other wallets and at some point decided its time to switch to
>>> mBTC.
>>>
>>>
>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>> The standard has become mBTC and that's what was adopted.
>>>> It's too late to try and sway this on a mailing list thread
>>>> now.
>>>>
>>>>
>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>> wrote:
>>>>
>>>> The MultiBit HD view is that this is a locale-sensitive
>>>> presentation issue. As a result we offer a simple
>>>> configuration panel giving pretty much every possible
>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
>>>> mXBT, μXBT, sat along with settings for leading/trailing
>>>> symbol, commas, spaces and points. This allows anyone to
>>>> customise to meet their own needs beyond the offered default.
>>>>
>>>>
>>>> We apply the NIST guidelines for representation of SI unit
>>>> symbols (i.e no conversion to native language, no RTL giving
>>>> icon+m etc).
>>>>
>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>> the Font Awesome icon set. However reading earlier posts it
>>>> seems that μ+icon is more sensible.
>>>>
>>>> Let us know what you'd like.
>>>>
>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>> Awesome icon:
>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>
>>>>
>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
>>>> <mailto:jgarzik at bitpay.com>> wrote:
>>>>
>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
>>>> several weeks ago, which was disappointing -- it sounded like
>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>> happen-- may result in additional user confusion, thanks to
>>>> yet another decimal place transition.
>>>>
>>>>
>>>>
>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com
>>>> <mailto:w at grabhive.com>> wrote:
>>>>> We're with uBTC too. Been waiting for the signal to do
>>>>> this,
>>>> let's do it right after the fee system is improved.
>>>>>
>>>>> -wendell
>>>>>
>>>>> grabhive.com <http://grabhive.com> |
>>>>> twitter.com/hivewallet
>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
>>>>>
>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>>>>
>>>>>> Go straight to uBTC. Humans and existing computer
>>>>>> systems
>>>> handle numbers to
>>>>>> the left of the decimals just fine (HK Dollars, Yen).
>>>>>> The
>>>> opposite is
>>>>>> untrue (QuickBooks really does not like 3+ decimal
>>>>>> places).
>>>>>
>>>>
>>>>
>>>>
>>>> -- Jeff Garzik Bitcoin core developer and open source
>>>> evangelist BitPay, Inc. https://bitpay.com/
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph
>>>> databases and their applications. Written by three acclaimed
>>>> leaders in the field, this first edition is now available.
>>>> Download your free book today!
>>>> http://p.sf.net/sfu/13534_NeoTech
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
>>>> Databases" is the definitive new guide to graph databases
>>>> and their applications. Written by three acclaimed leaders in
>>>> the field, this first edition is now available. Download your
>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
>>>> Databases" is the definitive new guide to graph databases and
>>>> their applications. Written by three acclaimed leaders in the
>>>> field, this first edition is now available. Download your
>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>>
>>>
>>>>
------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
>>> Databases" is the definitive new guide to graph databases and
>>> their applications. Written by three acclaimed leaders in the
>>> field, this first edition is now available. Download your free
>>> book today! http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>>
>>>
------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
>> Databases" is the definitive new guide to graph databases and
>> their applications. Written by three acclaimed leaders in the
>> field, this first edition is now available. Download your free
>> book today! http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
>
Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases
> and their applications. Written by three acclaimed leaders in the
> field, this first edition is now available. Download your free book
> today! http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:21 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:Indeed. And users were crying for mBTC. Nobody was asking for µBTC.
I must admit I was not aware if this thread. I just watched other
wallets and at some point decided its time to switch to mBTC.
On 03/13/2014 02:31 PM, Mike Hearn wrote:
> The standard has become mBTC and that's what was adopted. It's too late
> to try and sway this on a mailing list thread now.
>
>
> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe <g.rowe at froot.co.uk
> <mailto:g.rowe at froot.co.uk>> wrote:
>
> The MultiBit HD view is that this is a locale-sensitive presentation
> issue. As a result we offer a simple configuration panel giving
> pretty much every possible combination: icon, m+icon, μ+icon, BTC,
> mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for
> leading/trailing symbol, commas, spaces and points. This allows
> anyone to customise to meet their own needs beyond the offered default.
>
> We apply the NIST guidelines for representation of SI unit symbols
> (i.e no conversion to native language, no RTL giving icon+m etc).
>
> Right now MultiBit HD is configured to use m+icon taken from the
> Font Awesome icon set. However reading earlier posts it seems
> that μ+icon is more sensible.
>
> Let us know what you'd like.
>
> Links:
> m+icon screenshot: http://imgur.com/a/WCDoG
> Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
> NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>
>
> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
> Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks
> ago, which was disappointing -- it sounded like the consensus was
> uBTC, and moving to uBTC later --which will happen-- may result in
> additional user confusion, thanks to yet another decimal place
> transition.
>
>
>
> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com
> <mailto:w at grabhive.com>> wrote:
> > We're with uBTC too. Been waiting for the signal to do this,
> let's do it right after the fee system is improved.
> >
> > -wendell
> >
> > grabhive.com <http://grabhive.com> | twitter.com/hivewallet
> <http://twitter.com/hivewallet> | gpg: 6C0C9411
> >
> > On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >
> >> Go straight to uBTC. Humans and existing computer systems
> handle numbers to
> >> the left of the decimals just fine (HK Dollars, Yen). The
> opposite is
> >> untrue (QuickBooks really does not like 3+ decimal places).
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases
> and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> 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
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:21 UTC

- reply

📅 Original date posted:2014-03-14
📝 Original message:btw. None of Bitcoin Wallet's users complained about confusion because
of the mBTC switch. In contrast, I get many mails and questions if
exchange rates happen to differ by >10%.
I suspect nobody looks at the Bitcoin price. It's the amount in local
currency that matters to the users.
On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> Indeed. And users were crying for mBTC. Nobody was asking for µBTC.
>
> I must admit I was not aware if this thread. I just watched other
> wallets and at some point decided its time to switch to mBTC.
>
>
> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>> The standard has become mBTC and that's what was adopted. It's too late
>> to try and sway this on a mailing list thread now.
>>
>>
>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe <g.rowe at froot.co.uk
>> <mailto:g.rowe at froot.co.uk>> wrote:
>>
>> The MultiBit HD view is that this is a locale-sensitive presentation
>> issue. As a result we offer a simple configuration panel giving
>> pretty much every possible combination: icon, m+icon, μ+icon, BTC,
>> mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for
>> leading/trailing symbol, commas, spaces and points. This allows
>> anyone to customise to meet their own needs beyond the offered default.
>>
>> We apply the NIST guidelines for representation of SI unit symbols
>> (i.e no conversion to native language, no RTL giving icon+m etc).
>>
>> Right now MultiBit HD is configured to use m+icon taken from the
>> Font Awesome icon set. However reading earlier posts it seems
>> that μ+icon is more sensible.
>>
>> Let us know what you'd like.
>>
>> Links:
>> m+icon screenshot: http://imgur.com/a/WCDoG
>> Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
>> NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>
>>
>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
>> <mailto:jgarzik at bitpay.com>> wrote:
>>
>> Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks
>> ago, which was disappointing -- it sounded like the consensus was
>> uBTC, and moving to uBTC later --which will happen-- may result in
>> additional user confusion, thanks to yet another decimal place
>> transition.
>>
>>
>>
>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com
>> <mailto:w at grabhive.com>> wrote:
>> > We're with uBTC too. Been waiting for the signal to do this,
>> let's do it right after the fee system is improved.
>> >
>> > -wendell
>> >
>> > grabhive.com <http://grabhive.com> | twitter.com/hivewallet
>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
>> >
>> > On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>> >
>> >> Go straight to uBTC. Humans and existing computer systems
>> handle numbers to
>> >> the left of the decimals just fine (HK Dollars, Yen). The
>> opposite is
>> >> untrue (QuickBooks really does not like 3+ decimal places).
>> >
>>
>>
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases
>> and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> 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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:14:54 UTC

- reply

📅 Original date posted:2014-03-07
📝 Original message:On 03/06/2014 07:03 PM, Alex Kotenko wrote:
> Supporting Bluetooth is optional in the sense that if a wallet should
> not support it, you will still receive the transaction via the P2P
> network. So I'd say definately go for Bluetooth.
>
> Yes, it's part of the plan. Just again - I need to make sure we
> support all major wallets. And no other wallets actually support NFC by
> now, not talking about bluetooth. So I imagine we will decide and
> implement together some solution here, both on the wallet and POS sides,
> but I will have to keep URI method and even QR codes for backwards
> compatibility, and wait for other main wallets to accept innovations
> before we will be able to completely switch to it.
> As I said earlier - bluetooth support for my POS is not a problem, we
> can plug it in easily and make it work. Support among all
> hardware/software and polished user experience - this is a main thing
> here really.
Sure, take all the time you need.
All I wanted to say is you don't need to break Bitcoin URI compatibility
in order to support direct payments via Bluetooth. It's simply an
add-on, both in the BIP21 and the BIP70 cases.

2023-06-07 15:14:54 UTC

- reply

📅 Original date posted:2014-03-06
📝 Original message:> Not sure if you've seen it, but here is how we do NFC right
> now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
Thanks for the video! It's always good to see these things in action so
you can start believing in it.
> For now this is just an NDEF URI message with Bitcoin URI inside, and
> then transaction itself propagated to the network by the phone using
> it's own Internet connection. Far not ideal, but even this is supported
> only by Andreas' Wallet, so we cannot move ahead alot really until other
> wallets will have some support in this area.
Supporting Bluetooth is optional in the sense that if a wallet should
not support it, you will still receive the transaction via the P2P
network. So I'd say definately go for Bluetooth.
> As you see - it's taking just few seconds, most of which is manual
> payment confirmation.
I wonder about the receipt step -- are you generating a PDF on device
and sending it via NFC? This is something that could be supported by the
BIP70 payment protocol. We should try to avoid the second tap, its not
intuitive.
> And btw, have you been to London
> lately? Oyster readers now accept contactless cards directly along with
> Oyster cards itself.
Contactless cards? Last I was to London, the Oyster card was already
contactless. Have there ever been magnet-strip-based Oyster cards?
> I wonder if eventually in future we could add
> bitcoin support into that system directly, without hardware replacements.
Neat thought (-:

2023-06-07 15:14:51 UTC

- reply

📅 Original date posted:2014-03-07
📝 Original message:On 03/07/2014 10:26 AM, Johannes Zweng wrote:
> In current phone implementations, the screen must be on already for NFC
> to be active. Also it must be unlocked, although I certainly hope future
> OSes will allow payment apps on the lock screen, just like they allow
> music players.
>
> Just a small input to this point:
> On Android 4.4 the new host card emulation (HCE) feature (aka: the phone
> emulates a ISO-DEP Smartcard and processes ISO7816-4 APDU commands like
> a Smartcard would do) only works when the display is on, but even when
> the screen is locked (can be changed with "android:requireDeviceUnlock"
> in Manifest). See here for detailled
> specification: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
>
> Using the HCE API on Android 4.4 also has the beauty that any app that
> registers itself for HCE and sets its category to CATEGORY_PAYMENT in
> the Manifest automatically shows up in Adroid's system settings under
> "Tap & Pay" (where a user would expect payment applications).
Thanks for the pointer! Good to hear there is finally a decent
documentation for HCE.
Good news: HCE offers the required dispatch ability -- they call it AID
(Application ID).
Bad news: It seems - at least CATEGORY_PAYMENT - very credit card centric.
HCE seems to cover only the payer side. I wonder if there is also an API
for "reader emulation" which we would need for apps to support the payee
side.
Since Android 4.4 market penetration is quite far off, I suggest we
focus on the already established NFC payment protocol(s) for now, it
works pretty well. I will investigate into IsoDep and HCE and see if we
can make it enhance usability.
Interesting side note: They recommend messages transmitted via NFC to
not exceed 1 KB in order for a snappy experience. This (again) questions
usage of bulky X.509 certificates in our payment request messages.
Bitcoin Wallet currently does not sign payment requests, so I could not
try how it would feel.

2023-06-07 15:14:50 UTC

- reply

📅 Original date posted:2014-03-06
📝 Original message:On 03/06/2014 02:44 PM, Mike Hearn wrote:
> I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
> up the phone the connection breaks.
>
> If the phone isn't willing to immediately authorise then it'd have to
> fall back to HTTPS or Bluetooth as normal.
Ok, that would be an option.
> Besides, how do you plan to risk-analyse the memo field?
>
> I guess only the amount and destination are relevant for risk analysis.
The memo field (and its logical evolution, an invoice) also needs to be
verified, since its part of the contract. Imagine sitting in a
restaurant and you're being presented the bill, most people will do a
quick scan of the meals and drinks consumed (and non-malignant errors
are frequent in that business).
> It's already very short if you can do without Android Beam, e.g. on
> Android 2.3.
>
> I think IsoDep based protocols must bypass Beam - when I scan my
> e-passport there's no beam animation.
Everything except Beam bypasses Beam (-: Beam is an Android-specific
protocol. I assume it would also be possible to write an own NDEF
implementation on top of the low level NFC APIs. I want to try as soon
as I have a second NFC-capable phone, preferably Android 4.4.
> Even the current ~10 second roundtrip is a huge improvement to the
> status quo. I recently tried to buy a subway ticket and it took me 7
> full minutes (just for the payment process)!
>
> Then that subway kind of sucks ;)
You can't really blame the subway for a broken payment process.
> Have you been to London and used Oyster?
Yes, it was a complete disaster. Obtaining a ticket took even longer --
ca. 45 minutes. Boarding the train took some additional seconds,
compared to no overhead in Germany where we simply don't have any gates.
On top of that, you walk more (in tunnels) than you get driven around,
get tracked on each movement and if you want to get your (monetary)
change, you need to wait for another 45 minutes.
The upside is, when going by public transport in England I always feel
like Mr. Freeman in City 17 (-:

2023-06-07 15:14:49 UTC

- reply

📅 Original date posted:2014-03-06
📝 Original message:I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
up the phone the connection breaks. It's ok if some people decide to let
the app do risk analysis, but you cannot force it onto users by picking
a protocol that cannot deal with manual verification. Users should
always have the choice to verify their payment without time pressure and
by holding the device of their choice at their individual viewing distance.
Besides, how do you plan to risk-analyse the memo field?
In current phone implementations, the screen must be on already for NFC
to be active. Also it must be unlocked, although I certainly hope future
OSes will allow payment apps on the lock screen, just like they allow
music players.
> To get the very fast light feel the actual contact period has to be
> quite short, so I bet we'd need to optimise the bootup process of the
> Android wallet app.
It's already very short if you can do without Android Beam, e.g. on
Android 2.3. I'd say <200 ms for an BIP21 payment request. Bootup of the
app and everything else happens after -- no need to continue contact.
Indeed most of the bootup time goes into loading complex wallets. Our
long standing plans to clean up the wallet and archieve transactions
should help. Also, if Bitcoin catches on the app will just stay in memory.
The most obvious optimization to speed up signature checking is to make
it lazy. The user can already inspect the payment while signatures are
being checked. Even transaction signing could already happen in advance,
if it can be made sure that no signed transaction "escapes" the dialog
without the users consent.
Even the current ~10 second roundtrip is a huge improvement to the
status quo. I recently tried to buy a subway ticket and it took me 7
full minutes (just for the payment process)!

2023-06-07 15:14:26 UTC

- reply

📅 Original date posted:2014-03-21
📝 Original message:+1
I couldn't do a better job at describing my motivation behind trying to
stuff payment requests into QR codes.
On 03/20/2014 10:52 PM, Roy Badami wrote:
> On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
>
>> Yes, this overlaps somewhat with the PKI signing in BIP70, but not
>> entirely - you might want to serve unsigned payment requests, but
>> still have confidentiality and authenticity for a local face to face
>> transaction. The signing and encryption does different things
>
> I'm not sure if this what you're getting at, but in a common
> face-to-face scenario, it really doesn't overlap so much (in that the
> PKI in BIP70 isn't really helpful).
>
> It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> establishment, that you know neither the legal name of the entity
> running the establishment, nor any electronic identifier (domain name,
> email address) that might be presented to you in an X.509 certificate,
> even if such a certificate is presented in the PaymentRequest.
>
> In many cases I want/need to simply be assured that I am paying "the
> person/organisation which operates that machine behind the counter,
> right there".
>
> In many ways I'll miss the simplicity of BIP21 QR codes for
> face-to-face transactions - because in this use case the payment
> protocol complicates (and in many cases weakens) the assurance that
> you really are paying the entity that prepared the QR code.
>
> roy
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>

2023-06-07 15:14:26 UTC

- reply

📅 Original date posted:2014-03-26
📝 Original message:But these cases are the norm, rather than the exception. Of all these
places I spend my money at during the day I hardly ever know their
official name. I'm thinking in terms of "bakery", "indian restaurant" or
"snack vending machine".
In Germany usually businesses are named like the people that run it.
That usually just one or two random family names plus the legal form of
the company.
On 03/26/2014 11:56 PM, Mike Hearn wrote:
> Yeah, for those cases we'd need to think of something else. That gets
> into the realm of creating our own infrastructure though ...
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:14:22 UTC

- reply

📅 Original date posted:2014-03-21
📝 Original message:On 03/20/2014 01:12 PM, Adam Back wrote:
> Whats a sensible limit on practical/convenient QR code size?
Technically 3 KB. In my experience codes above 1.5 KB become impossible
to scan (ZXing scanner, 3 years ago). You will want to stay below 500
bytes for convenient scanning. That said, I'm convinced there is a lot
of room for scanning improvements.
> How much of the payment protocol message size comes from use of x509?
As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about
4000 bytes on top of that.
As you can see, we have quite some room for improvements to PR payload
(PaymentDetails). X.509 certification will probably not be possible via
QR, at least not until specialized CA's will issue space-efficient certs
(using ECDSA?).

2023-06-07 15:14:20 UTC

- reply

📅 Original date posted:2014-03-21
📝 Original message:On 03/20/2014 06:31 PM, Jeff Garzik wrote:
>> Afaik, BIP73 needs an external server (the web server).
>
> Yes. Internet connectivity is not a rarity these days. Near-field
> web servers also work fine.
Unfortunately it still is. At least here in Germany.

2023-06-07 15:14:18 UTC

- reply

📅 Original date posted:2014-03-20
📝 Original message:Afaik, BIP73 needs an external server (the web server).
On 03/20/2014 04:31 AM, Jeff Garzik wrote:
> Take a look at BIP 73:
> https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki
>
>
>
>
> On Wed, Mar 19, 2014 at 10:22 PM, Alex Kotenko <alexykot at gmail.com
> <mailto:alexykot at gmail.com>> wrote:
>
> Hi Andreas
>
>
> I'm implementing support for BIP70 in my POS at the moment, and I've
> just realized that with options you're proposing usecase I'm looking
> for is not covered.
>
> Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code,
> and I need to still be able to use it for backwards compatibility.
> But at the same time I want to be able to support BIP70. And also I
> want to avoid using external servers, the concept of my POS is that
> everything is happening between just payer's phone and payee's POS
> device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not
> suitable for me.
>
> You're also offering an option to include Base43 encoded PR body
> right inside the Bitcoin URI, but in a way that is not backwards
> compatible with BIP21.
>
> In the end this all means that there is no way for me to at the same
> time keep backwards compatibility with all wallets not supporting
> NFC and BIP70 (all other wallets right now), and keep things inside
> POS without need for external servers.
>
> I understand your intention behind base43 encoding and noncompatible
> URI - you want to make most possible use of QR codes. But I wonder -
> did you compare this base43 to base64 encoded request in a binary QR
> code format? How much do we actually win in total bytes capacity at
> a price of noncompatibility and increased complexity?
>
> And also maybe we can extend BIP72 to include encoded payment
> request in the URL directly in a backwards compatible way?
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-03-02 11:50 GMT+00:00 Mike Hearn <mike at plan99.net
> <mailto:mike at plan99.net>>:
>
> Thanks Andreas.
>
> For BIP standardisation, I think the VIEW intent seems like an
> obvious one. Bluetooth support probably should come later
> if/when we put encryption/auth on the RFCOMM link (probably SSL).
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified
> tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
> Analyzer
> Customize your own dashboards, set traffic alerts and generate
> reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&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
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> 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
>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:14:16 UTC

- reply

📅 Original date posted:2014-03-02
📝 Original message:I've written up a document about all the different methods on how the
payment protocol (both the old one and BIP70) is used in Bitcoin Wallet.
It only provides an overview -- I plan to go into details with separate
(BIP?) documents where needed.
https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
If you have any questions about compatibility, don't hesitate to contact me.
On 01/27/2014 12:59 PM, Andreas Schildbach wrote:
> As promised I'd like to present my work done on leveraging the payment
> protocol for face-to-face payments.
> [...]

2023-06-07 15:12:42 UTC

- reply

📅 Original date posted:2014-01-27
📝 Original message:On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
>> SCAN TO PAY
>> For scan-to-pay, the current landscape looks different. I assume at
>> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>> into a QR-code. Nevertheless, I tried to encode a payment request into
>> the bitcoin URL. I used my existing work on encoding transactions into
>> QR-codes. Steps to encode:
>
> Really interesting work. When using scan-to-pay, after the payer scans the
> QR code with the protobuf PaymentRequest (not a URL to download the
> PaymentRequest) are they using their own connectivity to submit the
> Payment response?
>
> How about putting a Bluetooth address in the payment_url inside the
> PaymentDetails message for the smartphone to send back the Payment
> response and get PaymentAck?
That's exactly what I have prototyped. I am putting a Bluetooth MAC
address into the payment_url. Have a look at the TAP TO PAY paragraph
for details, its mostly the same mechanism.

2023-06-07 15:12:41 UTC

- reply

📅 Original date posted:2014-01-27
📝 Original message:On 01/27/2014 02:11 PM, Mike Hearn wrote:
> I would like to see Bluetooth continue to work for scan-to-pay even in
> the signed case. So for this reason the current approach with a BTMAC
> parameter in the Bitcoin URI seems to work universally across NFC tags
> and QR codes, and would allow download of a signed PaymentRequest even
> in the case where a QR code is used.
I'm not saying I'm against signed payment requests, but unfortunately
they are just too big for QR-codes. Then again, QR-codes *can* take up
to 2 KB. How big would a very basic trust chain plus signature be?
> Because a Bitcoin URI already contains a public key (hash), re-using
> that to establish an encrypted/authd connection on top of an insecure
> RFCOMM socket would seem to be relatively straightforward.
I was under the impression that addresses will go away. Can you
elaborate on the mechanism?
> Obviously such QR-encoded payment requests cannot grow in size as much
> as using other media. In particular, I expect PKI signed requests are
> out of question. However, in face to face payments the value of a sig
> based on PKI is highly questionable, and the fact the sig cannot be
> verified without TCP connectivity doesn't help.
>
> Just a correction here - the reason signed payment requests are "large"
> (about 4000 bytes) is exactly because they *can* be verified offline,
> i.e. by a Trezor. The signed payment request contains all the data
> needed to establish its authenticity, including certificates and the
> signature itself. No TCP connection is needed.
Ok, that's good news (to me). However, you are going to manage trust
stores (adding and revoking) without TCP?
> For face to face payments, I think signing is still useful. For one, we
> want to keep the distinction between "merchant" and "user" as blurry and
> indistinct as possible. A strong separation between merchants and
> consumers is one of the many bad things about the credit card system.
Ack.
> Whilst initially we'd expect the payment protocol to be used by online
> webshops, in future it could be used by little corner shops, children's
> lemonade stands and so on.
Well I'm thinking the other way round. Use Bitcoin where its already
used today -- face to face.
> you probably still would like a receipt if you buy
> something from a local market trader.
Yes, but where is the problem?
> Another use case - we heard a story about a restaurant owner who
> accepted Bitcoin. He printed a static bitcoin URI onto a QR code on the
> menu. A month or two later he discovered one of his waiters had
> re-printed the menus with his own QR code! The people thought they had
> been paying for the meal, and in fact it went right into the pocket of
> the waiter.
Sad story, but it's really a special case. Using a printed QR-code is
clearly the wrong tool for his task, for several reasons.
And again, how is he going to provide the payment request to the payer
without TCP?
> As to how it works, well, that's not hard. Comodo give away free email
> address certs with a few mouse clicks, it's no harder than signing up
> for a website.
We don't want to force people to sign up anywhere. Bitcoin is instant-on.
> - I chose to re-use the "bitcoin:" URL scheme
>
> Other wallets won't know what to do with it and would yield a strange
> error message.
Which is why I said we need some transition time.
> Rather than pack a file into a URL, if you don't want to
> use the current r= extension it's better for apps to just register to
> handle .bitcoinpaymentrequest files / the right MIME type. Downloading
> it and opening it would do the right thing automatically.
That's a good point. I'll implement this asap.
> Remember BIP 73 also! It says that with the apps built-in QR scanner, if
> you scan an HTTP[S] URI, you should try downloading it with a magic
> header. That way you can get a payment request file out of the server.
> Without the magic header (i.e. a normal generic barcode scanner app) it
> would open a web page containing a bitcoin URI clickable link.
Interesting, did not know about this BIP. However I don't understand the
usecase. Its not like my browsers always display QR-codes with URL of
the page being shown. And if the page in question bothers to show a QR
code, it could just as well also link to a payment request resource (as
suggested above).

2023-06-07 15:12:40 UTC

- reply

📅 Original date posted:2014-01-27
📝 Original message:As promised I'd like to present my work done on leveraging the payment
protocol for face-to-face payments. The general assumption is that
individuals don't own X.509 certificates. Their devices may be only
badly connected to the internet or in some cases not at all. I've
implemented a prototype on a branch of Bitcoin Wallet. It is using
bitcoinj 0.11 (not released).
https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol
TAP TO PAY
First I looked at the NFC tap-to-pay usecase. The way it works as
currently rolled out: A BIP21 URL is published using an NDEF URI
message. The URL is supplemented by a Bluetooth MAC address that can be
connected in order to finish the payment. Once connected, a very simple
custom protocol transmits the signed transaction(s) in
bitcoin-serialized form to the payee, who replies with an ack or nack.
The way I prototyped it to work in future: Instead of the BIP21 URL a
BIP70 payment request is published using an NDEF MIME message (mime-type
as per BIP71). The paymentUrl field can (and in the face-to-face case
should) contain a Bluetooth URL which contains the MAC address of the
payee. Because I could not find any standard for Bluetooth URLs, I made
up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66. Once
connected, Payment message and PaymentACK reply are used to finish the
payment. Since Bluetooth sockets are streams, I had to use the delimited
variant of the protobufs for Payment and PaymentACK messages. This
prepends them with a VARINT containing the message length.
All of the above should be easy to migrate. NFC implementations are
rare, and the current Bluetooth protocol is implemented only by Bitcoin
Wallet afaik. Fallbacks are provided where necessary.
In future, I'd like to add encryption to the Bluetooth connection, maybe
using SSL and some DH key exchange.
SCAN TO PAY
For scan-to-pay, the current landscape looks different. I assume at
least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
into a QR-code. Nevertheless, I tried to encode a payment request into
the bitcoin URL. I used my existing work on encoding transactions into
QR-codes. Steps to encode:
1. The payment request is protobuf-serialized. For a simple payment
request, this results in only ~50 bytes thanks to the efficiency of
protobuf.
2. The bytes are encoded using "Base43", which is the same as
Base64/Base58, but its alphabet consists of the characters allowed in
so-called "alphanumeric" QR-codes, minus the characters not allowed in URLs.
3. The resulting string is prefixed by "BITCOIN:"
4. All of that goes into a QR-code, and because it only contains
"alphanumeric" characters, it will produce a very efficient code. For
simple payment requests, I could not notice any difference in scanning
difficulty.
There are some limitations however:
- Obviously such QR-encoded payment requests cannot grow in size as much
as using other media. In particular, I expect PKI signed requests are
out of question. However, in face to face payments the value of a sig
based on PKI is highly questionable, and the fact the sig cannot be
verified without TCP connectivity doesn't help. There should be some
headroom for multiple-output requests and moderately more complex
scripts though.
- I chose to re-use the "bitcoin:" URL scheme, because it's already
whitelisted in web browsers, QR-code scanners and so on. In order to
differentiate "payment requests URLs" from BIP21 URLs, I test for
uri.startsWith("BITCOIN:") because you'll get letters in all-caps from
alphanumeric QR-codes. I will investigate into a better solution.
- Due to wide deployment of BIP21 QR-codes, migration needs to happen in
distinct phases. Ability to parse "payment protocol URLs" comes first,
default to presenting them to users has to come (much) later.
CLICK TO PAY
Finally this is the usecase the payment protocol was invented for and
it's not face-to-face. I don't have much to add, just one thing. As a
byproduct of the above, "payment protocol URLs" can be used for links
published on web pages as well. This might provide a nice replacement
for the imho rather ugly BIP72 specification once the payment protocol
is widely deployed.
Open for discussion.

2023-06-07 15:10:03 UTC

- reply

📅 Original date posted:2013-12-01
📝 Original message:On 12/01/2013 06:19 PM, Mike Hearn wrote:
>> Both can be combined into adapting the current generic messages ("This
>> payment should become spendable shortly" for incoming and "This payment
>> has not been transmitted yet" for outgoing transactions).
>
> What would the new messages say?
Well, for starters I'd suggest something like
"This payment did not become spendable since xxx minutes. Check with the
sender if s/he paid the Bitcoin network fee. Check if your internet
connection is working properly." (incoming)
"This payment still has not been transmitted. Check if your internet
connection is working properly." (outgoing)
> We need to get away from the notion of senders attaching fees anyway.
This is the wrong way around because it’s the recipient who cares about
double spending risk, not the sender. That’s why merchants keep running
into issues with people attaching zero fees. Of course they attach zero
fees. They know they aren’t going to double spend. It’s the merchant who
cares about getting the security against that.
Guess you're right. But as you said, we're not there yet.
> The UI for sending money should end up dead simple - no mention of
fees anywhere, IMO.
Agreed, if the sender does not need to pay a fee any more. On the
receiving side it of course needs to be mentioned. (Or the other way
round, as of today.)
> Unfortunately we lack the protocol pieces to get the right UI here :(
Someone needs to sit down and figure out what the UI *should* look like,
in the ideal world, and then work backwards to figure out what needs to
be done to get us there.
(The ideal world doesn't need a UI for money.)
>> For outgoing transactions, if it is very clear that they're never going
>> to be confirmed, I'd like to see a "Revoke" button.
>
> Disagree. There should never be any cases in which a transaction
doesn’t confirm. Period. I know there have been bugs with bitcoinj that
could cause this in the past, but they were bugs and they got fixed/will
get fixed.
>
> Settlement failure is just unacceptable and building a UI around the
possibility will just encourage people to think of it as normal, when it
should not be so.
I fully understand your point of view. However, its not the reality
currently. (Hopefully it is, after the fixes to bitcoinj.)

2023-06-07 15:10:03 UTC

- reply

📅 Original date posted:2013-12-01
📝 Original message:(my post hasn't shown up for an hour, so I'm sending it again)
On 12/01/2013 02:41 PM, Mike Hearn wrote:
>> As long as the tx is not confirmed (by a broadcast), apps can offer to
>> bump up the fee a little bit.
>
> Unfortunately there are risks to that approach.
I assume you're right, since I do not have so much experience with game
theory.
About the UI:
Generally, for pending tx I'd like to measure time they're not being
broadcast-confirmed and count blocks that they missed being included.
Both can be combined into adapting the current generic messages ("This
payment should become spendable shortly" for incoming and "This payment
has not been transmitted yet" for outgoing transactions). Hint:
Statistics could be offered by bitcoinj.
For outgoing transactions, if it is very clear that they're never going
to be confirmed, I'd like to see a "Revoke" button. This would have
saved us some support hassles with the transmit bugs. It could also
offer a "Top up fee" button, which would replace the tx by a new one.
I'm aware about a possible double spend but who cares? It doesn't matter
which of the two transactions gets into the chain, as long as not both
will be included.

2023-06-07 15:10:02 UTC

- reply

📅 Original date posted:2013-12-01
📝 Original message:On 12/01/2013 12:51 PM, Mike Hearn wrote:
> I propose the following plan:
Thanks taking the initiative and writing this up!
> If a wallet gets a reject message for a tx that has a fee that are by
> its own estimates acceptable, what should it do? What if only some nodes
> report that and others don't?
As long as the tx is not confirmed (by a broadcast), apps can offer to
bump up the fee a little bit.

2023-06-07 15:08:11 UTC

- reply

📅 Original date posted:2013-10-28
📝 Original message:HTTP also defines success codes (2xx). Are we also talking about ACK
messages now, rather than just REJECT messages?
On 10/28/2013 03:52 AM, kjj wrote:
> Any reason not to use actual HTTP codes? I'm not aware of any major
> deficiency in them. Most of them won't apply to us, which is fine, they
> don't seem to apply to HTTP either. We can extend the scheme on our own
> if we find a good reason to.
>
> That implies 16 bits, or a varint. I would avoid a string or varstring
> here; we already have a text field. Varint vs. 16 bits is a minor
> issue, and arguments can be made in both directions. I flipped a coin
> and got heads, so I'll say varint.
>
> Gavin Andresen wrote:
>> RE: use HTTP-like status codes:
>>
>> Okey dokey, I'll add a one-byte machine-readable HTTP-like status
>> code. Unless y'all want a 32-bit status code. Or maybe a varint. Or a
>> three-character numeric string. I really and truly don't care, but I
>> am writing this code right now so whatever you want, decide quickly.
>>
>> If anybody has strong feelings about what the reject categories should
>> be, then please take the time to write a specific list, I can't read
>> your mind....
>>
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:06:57 UTC

- reply

📅 Original date posted:2013-09-25
📝 Original message:On 09/25/2013 01:15 PM, Mike Hearn wrote:
> It won't fit.
Why do you think that? Of course, I would skip the certificate, as its
unnecessary if you see your partner in person.
> But I don't see the logic. A URI contains instructions for
> making a payment. If that instruction is "pay to this address" or
> "download this file and do what you find there", it's no different
> unless there's potential for a MITM attack. If the request URL is HTTPS
> or a secured Bluetooth connection then there's no such possibility.
HTTPS trust is utterly broken unless you fix it by adding the
certificate or a fingerprint to the QR code. Bluetooth is not present in
every case, e.g. QR codes scanned from the web. (Also, we currently
don't have a concept of allowing both. The receiver forces you to either
use BT or HTTP.)
So yes, MITM is what I'm worrying about. When I'm scanning a QR code
from a phone, you don't have that problem (unless sophisticated optical
attacks emerge). Also, the HTTP request can fail and/or be slow, making
the whole payment process more difficult than necessary.
> On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach
> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>
> While it's good to save space, I'm at the moment not convinced that
> taking a de-route via an URL is a good idea to begin with.
>
> The main problem is trust. If you scan a QR code from a foreign phone,
> you trust that that phone is owned by the one you want to send money to.
> By adding the HTTP request that trust is voided.
>
> As soon as there is a BIP70 implementation, I will begin playing with
> putting the payment request directly into the QR code.
>
>
> On 09/25/2013 11:27 AM, Mike Hearn wrote:
> > We could also say that if protocol part (https://) is missing, it's
> > implied automatically. So just:
> >
> > bitcoin:1abc........?r=bob.com/r/aZgR <http://bob.com/r/aZgR>
> <http://bob.com/r/aZgR>
> >
> > I think that's about as small as possible without re-using the
> pubkey as
> > a token in the url.
> >
> >
> > On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen
> <gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>
> > <mailto:gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>>>
> wrote:
> >
> > On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike at plan99.net
> <mailto:mike at plan99.net>
> > <mailto:mike at plan99.net <mailto:mike at plan99.net>>> wrote:
> >
> > BTW, on the "make qrcodes more scannable" front -- is it too
> > late to change BIP 72 so the new param is just "r" instead of
> > "request"? Every byte helps when it comes to qrcodes ...
> >
> >
> > Not too late, assuming there are no objections. Smaller QR
> codes is
> > a very good reason to change it.
> >
> > --
> > --
> > Gavin Andresen
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get
> the most from
> > the latest Intel processors and coprocessors. See abstracts and
> register >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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
> >
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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:04:56 UTC

- reply

📅 Original date posted:2013-07-23
📝 Original message:On 07/23/2013 11:37 AM, Pieter Wuille wrote:
>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
>
> Depends what you mean by expose.
>
> Maintaining an address/script-indexed UTXO is generally useful, in
> particular for things like sweeping addresses. I certainly have
> less problems with 'exposing' this than exposing a fully-indexed
> block chain history.
>
> However, and I expect that's what your question is about, this isn't
> really useful for SPV (or less) nodes, as there is no way to
> authenticate this data. If you can fake a UTXO entry, you can make
> a peer believe anything about their balance, potentially resulting
> in creating a valid transaction that sends change it didn't know
> was there as fee to miners. Other than for normal block chain data,
> there is no way to detect this without at least partial validation.
>
> The only way to do this safely at an SPV security assumption, is by
> having an address-indexed committed merkle UTXO-set tree, like the
> one proposed by Alan Reiner, and being implemented by Mark
> Friedenback. I know Michael Gronager has something similar implemented,
> but I don't know whether it is script-indexed. To be actually useful,
> it likely needs to be enforced by miners - putting a significant
> burden on validation nodes. Still, if it can be done efficiently,
> I think this would be worth it, but more research is needed first in
> any case.
>
> Regarding sweeping keys in the first place - I think using those,
> and relying on address-indexed UTXO sets or blockchains to import
> them, is an idea that doesn't scale very well in the first place.
> If it is for things like scratch card or physical coins, with a
> pre-set value, the obvious solution IMHO is storing the crediting
> transaction with its merkle path together with the key. If that's
> not possible, just the txid:vout of the credit output can suffice.
> Yes, that's more data than is necessary now, but it's so much more
> trivial to use.
I certainly don't want to push ideas that won't work for whatever
reason. So I fully respect whatever you decide regarding that feature.
Personally I have never felt any need for being able to sweep paper
wallets, I am more or less just relaying the need of users.
Let me just say this:
Sweeping paper wallets is a common feature request. People switch to
centralized services just for getting that.
It is my understanding that for the usecase, an address-indexed UXTO is
enough. So you probably don't need to worry about script-indexed for now.
Security issues could be mitigated by applying trust to the REST server,
e.g. because its your own or the one of your apps vendor. Of course,
link-level security would be needed for this (e.g. SSL).
Paper wallets that include the necessary additional information is
something I have been thinking about. I see some issues:
- Paper wallets are already quite widespread. You still won't be able to
sweep those.
- Some people like to "top up" a paper wallet or even just sweep a
portion of it. That would not be possible, and in some cases even lead
to loss of coins because of the "involuntary fee" you described.
- Does the necessary info fit into a QR code?

2023-06-07 15:04:55 UTC

- reply

📅 Original date posted:2013-07-23
📝 Original message:On 07/22/2013 09:42 PM, Jeff Garzik wrote:
> The general goal of the HTTP REST interface is to access
> unauthenticated, public blockchain information. There is no plan to
> add wallet interfacing/manipulation via this API.
Is it planned to expose the UXTO set of a given address? That would be
useful for SPV wallets to be able to swipe a previously unknown private
key (e.g. paper wallet).

2023-06-07 11:48:20 UTC

- reply

📅 Original date posted:2013-04-24
📝 Original message:I had another amendment, which roughly (can't remember the details) has
to do with case-sensitivity of the scheme part and parameter names. If I
remember right, BITCOIN:1d4...?AMOUNT=0.1 would be a correct URI but not
valid in the sense of BIP21 currently.
On 04/24/2013 09:42 AM, Mike Hearn wrote:
> HTML5 allows web apps to register themselves for handling URI schemes,
> such as the bitcoin: URI that is already in use and being extended as
> part of the payment protocol.
>
> The bad news is that for security reasons there is a whitelist of
> acceptable schemes in the spec:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler
>
> The good news is that yesterday I talked to Hixie about it and he added
> bitcoin to the whitelist:
>
> http://html5.org/tools/web-apps-tracker?from=7849&to=7850
>
> I'm currently finding out what the process is for browser makers to
> notice the change (perhaps they watch the spec commit history and
> nothing needs to be done), but within a few months most users should
> have browsers that can accept bitcoin as a web-app handleable protocol
> scheme. I suppose IE10 users may be the laggards, but I guess we can
> live with that for now.
>
> Ian pointed out some errors in the BIP21 spec. What's the process for
> amending the BIP? Do we need to create a new one and mark the old one as
> replaced, or can we just fix it in place given the relatively exotic
> nature of most of the issues? Here's his feedback:
>
>
> - BNF doesn't say what it's character set is (presumably it's Unicode)
>
> - "bitcoinparams" production doesn't define the separator, so in theory
> the syntax is ...?label=foomessage=fooother=foo (rather than
> ...?label=foo&message=foo etc)
>
> - the syntax allows ?amount=FOO&amount=1.1 as far as I can tell, since
> "otherparam" matches any name followed by any value, including "amount"
> followed by a bogus value.
>
> - "pchar" is referenced without definition.
>
> - the "simpler" syntax is just wrong (it would result in
> bitcoin:address?amount=1?label=FOO rather
> than bitcoin:address?amount=1&label=FOO)
>
> BTW the IETF URL specs are being obsoleted
> by http://url.spec.whatwg.org/, at least for Web purposes. In that case
> matters.
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02:59:47 UTC

- reply

📅 Original date posted:2012-01-31
📝 Original message:On 01/31/2012 11:22 AM, Wladimir wrote:
> To ensure forward compatibility with optional fields, we need to define
> how a client handles fields that it doesn't know about.
>
> When should it display an error message, and when should it silently
> accept and ignore the extraneous fields?
IMHO its standard that unknown URL parameters are simply ignored. I
think we should not change this principle.
> (For example, if something that restricts the validity, such
> as "expires" is added later on, it is pretty important not to ignore it.
> Older clients should refuse to comply.)
In this case, you'd need to refuse *all* parameters you don't know
about. In consequence, all extensions would break older clients.

2023-06-07 02:59:33 UTC

- reply

📅 Original date posted:2012-01-31
📝 Original message:Generally I prefer BIP 21 over BIP 20.
I'm neutral on the 'send' parameter - present in both BIPs - which I
don't understand. I think a practical usecase should be given in the BIP.
Also, the 'version' parameter is unclear. What does it mean? Is an oder
defined on versions (1.0b > 1.0)? Why is it an ";" parameter rather than
a normal "&" parameter?
On 01/30/2012 12:55 AM, Amir Taaki wrote:
> Matt Corallo posted a modification of BIP 20 in an earlier email and I
> asked him if he wanted to become the champion of that BIP he submitted.
>
> It is a modification of BIP 20 sans the alternative non-decimal number
> stuff.
>
> https://en.bitcoin.it/wiki/BIP_0021
>
> Right now, I will ask the GUI client implementations like MultiBit or
> Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
> support BIP 20 or BIP 21. Feel free to raise any objections.
>
> More weight will be given to GUIs with actual URI sche me
> implementations and it's good to have a general consensus.
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development