<unnamed>

Public Key

npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7

Profile Code

nprofile1qqsry9dn6a7l78uya66663hmzgr235t90vl2wedgpd2gnm8r5upd90qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds08gh2c

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:16:37 CEST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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 17:29:37 CEST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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