<unnamed>

Public Key

npub12hzwfhx9ptjf2f0va8qllc0h4tcvz5aaefvlvn9uq8z2ssrq027qtvtmxa

Profile Code

nprofile1qqs9t38ymnzs4ey4yhkwns0lu8m64uxp2w7u5k0kfj7qr39ggps840qprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvhf9328

Publishing to

relay.snort.social

Last Notes

2023-06-07 15:38:39 UTC

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn <mike at plan99.net> wrote:
> Or alternatively, fix the reasons why users would have negative
>> experiences with full blocks
>>
>
> It's impossible, Mark. *By definition* if Bitcoin does not have
> sufficient capacity for everyone's transactions, some users who were using
> it will be kicked out to make way for the others. Whether that happens in
> some kind of stable organised way or (as with the current code) a fairly
> chaotic way doesn't change the fundamental truth: *some users will find
> their bitcoin savings have become uneconomic to spend*.
>
> Here's a recent user complaint that provides a preview of coming
> attractions:
>
>
> https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
>
> Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
>> onto a paper wallet. When I try to send it, a window pops up stating
>> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389
>> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
>
>
>
Has there been any talk about reducing the time between blocks? If blocks
were allowed to come twice as fast, they would be able to clear pending
transactions in the mempool the same as if the block size doubled, but
would allow mining to stay more decentralized since miners wouldn't be
working on such large-scale blocks? It would still take more storage space
to store the blockchain, though.
Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/6f2397c3/attachment.html>

2023-06-07 15:23:50 UTC

- reply

📅 Original date posted:2014-07-15
📝 Original message:I was part of adding in that test vector, and I think it's a good test
vector since it is an extreme edge-case of the current definition: If the
BIP38 proposal allows any password that can be in UTF-8, NFC normalized
form, those characters cover the various edge cases (combining characters,
null character, astral range) that if your implementation doesn't handle,
then it can't really be said to be "BIP38-compatible/compliant", right?
The "passphrase" in the test vector is NOT in NFC form; that's the point.
Whatever implementation gets designed has to assume the input is not
already NFC-normalized and needs to handle/sanitize that input before
further processing. To test your implementation for compliance, you should
not be inputting the NFC-normalized bytestring as the password input, you
should be entering the original passphrase as the test. My original pull
request for this change (https://github.com/bitcoin/bips/pull/29) shows a
Python and a NodeJS way to input that test vector password as intended.
Some input devices may already handle the input as NFC, which is great, but
per the BIP38 proposal, that shouldn't be assumed, so various
implementations are cross-compatible. If one implementation assumes the
input is already NFC, they may encode/decode the password incorrectly, and
lock a user out of their wallet. Android allows different user keyboards to
be used, so I'm guessing there's one somewhere that allows manual entry of
unicode codepoints that could be used to enter a null character, and with
the next version of iOS, Apple devices will also get custom keyboard
options, too, so even if the default Apple keyboard does NFC-form properly,
other developers' keyboards may not. So while it is an extreme edge case,
that is not very likely to be used as a "real password" by any user, that's
what test vectors are for: to test for the edge case that you might not
have expected and handled in your implementation.
Brooks
On Tue, Jul 15, 2014 at 8:07 AM, Eric Winer <enwiner at gmail.com> wrote:
> I don't know for sure if the test vector is correct NFC form. But for
> what it's worth, the Pile of Poo character is pretty easily accessible on
> the iPhone and Android keyboards, and in this string it's already in NFC
> form (f09f92a9 in the test result). I've certainly seen it in usernames
> around the internet, and wouldn't be surprised to see it in passphrases
> entered on smartphones, especially if the author of a BIP38-compatible app
> includes a (possibly ill-advised) suggestion to have your passphrase
> "include special characters".
>
> I haven't seen the NULL character on any smartphone keyboards, though - I
> assume the iOS and Android developers had the foresight to know how much
> havoc that would wreak on systems assuming null-terminated strings. It
> seems unlikely that NULL would be in a real-world passphrase entered by a
> sane user.
>
>
> On Tue, Jul 15, 2014 at 8:03 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> [+cc aaron]
>>
>> We recently added an implementation of BIP 38 (password protected private
>> keys) to bitcoinj. It came to my attention that the third test vector may
>> be broken. It gives a hex version of what the NFC normalised version of the
>> input string should be, but this does not match the results of the Java
>> unicode normaliser, and in fact I can't even get Python to print the names
>> of the characters past the embedded null. I'm curious where this normalised
>> version came from.
>>
>> Given that "pile of poo" is not a character I think any sane user would
>> put into a passphrase, I question the value of this test vector. NFC form
>> is intended to collapse things like umlaut control characters onto their
>> prior code point, but here we're feeding the algorithm what is basically
>> garbage so I'm not totally surprised that different implementations appear
>> to disagree on the outcome.
>>
>> Proposed action: we remove this test vector as it does not represent any
>> real world usage of the spec, or if we desperately need to verify NFC
>> normalisation I suggest using a different, more realistic test string, like
>> Zürich, or something written in Thai.
>>
>>
>>
>> Test 3:
>>
>> - Passphrase ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK
>> UPSILON WITH HOOK <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
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140715/298353e5/attachment.html>

2023-06-07 15:14:53 UTC

- reply

📅 Original date posted:2014-03-06
📝 Original message:On Thu, Mar 6, 2014 at 12:12 PM, Mike Hearn <mike at plan99.net> wrote:
> If there was a way for a Bitcoin user to provide feedback on a payment
>> (ECDSA signature from one of the addresses involved in the payment, signing
>> an identifier of the payment and a feedback score)
>>
>
> Well now you're getting into the area that I said "rapidly got very
> complicated".
>
> Define bitcoin user? What stops me paying myself to accrue positive
> reputation? Etc.
>
Yes, I could see how that could get hairy; it would also need some ability
to rate those giving the feedback, such that if you generate a whole bunch
of payments to yourself, those payees don't have reputation on their own,
so their review of you as a payer isn't weighted that highly. Then you have
that ring-of-trust possibility where Alice thinks Eve is bad, so the fact
that Eve thinks Bob is good doesn't impact Alice. But if Carol thinks Eve
is good, Carol thinks Bob is good too, so Bob's reputation is different
based on who's asking, and it's the responsibility of the individual
members to maintain their own good/bad user lists. Would you think that's a
good thing or a bad thing to give the individual players that level of
control/responsibility?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/be0073a8/attachment.html>

2023-06-07 15:14:52 UTC

- reply

📅 Original date posted:2014-03-06
📝 Original message:On Thu, Mar 6, 2014 at 11:07 AM, Mike Hearn <mike at plan99.net> wrote:
> if some sort of Stealth address or HD wallet root was the identity gaining
>> the reputation, then address re-use wouldn't have to be mandatory.
>>
> The identity would be the X.520 name in the signing cert that signed the
> payment request. It doesn't have to be a difficult to obtain cert. It could
> even be self signed for this use case, but then you lose the security
> benefits and a key rotation would delete your reputation, so in practice I
> think most people would want the reputation to accrue to the name itself.
>
That makes sense, to have self-signed certificates as a basic start, but
then is it possible to have a Bitcoin user (address) add reputation/sign
such a certificate, rather than having a central signing authority? If
there was a way for a Bitcoin user to provide feedback on a payment (ECDSA
signature from one of the addresses involved in the payment, signing an
identifier of the payment and a feedback score) such that any user can add
to the reputation with just the Bitcoin infrastructure, without having to
learn X.500 certificate signing on top of EC signatures? If there was a
standard structure for a message to be EC-signed with your Bitcoin client,
and then a distributed store of those signed messages, could that form a
reputation score?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/3f35eb4a/attachment.html>

2023-06-07 15:14:52 UTC

- reply

📅 Original date posted:2014-03-06
📝 Original message:On Mar 6, 2014 3:47 AM, "Mike Hearn" <mike at plan99.net> wrote:
>
> I just did my first contactless nfc payment with a MasterCard. It worked
very well and was quite delightful - definitely want to be doing more of
these in future. I think people will come to expect this kind of
no-friction payment experience and Bitcoin will need to match it, so here
are some notes on what's involved.
>
> 3) Have some kind of decentralised reputation network. I spent some time
thinking about this, but it rapidly became very complicated and feels like
an entirely separate project that should stand alone from Bitcoin itself.
Perhaps rather than try to make a global system, social data could be
exchanged (using some fancy privacy preserving protocols?) so if your
friends have decided to trust seller X, your phone automatically trusts
them too.
A reputation network might be an interesting idea, or several different
networks with different curators (to prevent complete centralization), like
how the US credit score system has three main companies who track your
score. Something like a GPG ring of trust, with addresses signing other
addresses would work well, if some sort of Stealth address or HD wallet
root was the identity gaining the reputation, then address re-use wouldn't
have to be mandatory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/566df540/attachment.html>

2023-06-07 15:12:22 UTC

- reply

📅 Original date posted:2014-01-20
📝 Original message:On Mon, Jan 20, 2014 at 11:42 AM, slush <slush at centrum.cz> wrote:
> Hi all,
>
> during recent months we've reconsidered all comments which we received
> from the community about our BIP39 proposal and we tried to meet all
> requirements for such standard. Specifically the proposal now doesn't
> require any specific wordlist, so every client can use its very own list of
> preferred words. Generated mnemonic can be then applied to any other
> BIP39-compatible client. Please follow current draft at
> https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
>
So, because the [mnemonic]->[bip32 root] is just hashing, you've
effectively made your "mnemonic sentence" into a brainwallet? Since every
mnemonic sentence can now lead to a bip32 root, and only the client that
created the mnemonic can verify the mnemonic passes its checksum (assuming
all clients use different wordlists, the only client that can help you if
you fat-finger the sentence is the client that created it)?
Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140120/6d9774f0/attachment.html>