Jeffrey Paul [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-12-04 to 2018-11-08
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:15:11

- reply

📅 Original date posted:2018-11-08
📝 Original message:> On Nov 7, 2018, at 13:28, Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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.
One can also make the argument that if the user's clipboard is able to be read/modified, then their working environment is already compromised and that the responsibility is already not upon specific application software, but the user or OS.
Down here in the real world, an application that does not support copying and pasting of addresses is not an application that is very useful (to say the least) to many people who want to manage their own wallet, though I understand your desire to avoid such. Perhaps offering alternatives such as supporting signed BIP70 payment requests is what you mean to do.
That said, I still think working around specific malware threats and vectors isn't the application's job, especially when doing so for a tiny, tiny fraction of users that have malware outweighs the needs of the 95%+ that need to support the "I have an address on my clipboard I need to pay" case.
Best,
-jp
--
Jeffrey Paul
+1 312 361 0355
+49 176 8058 2122 (signal)

2023-06-07 19:40:51

- reply

📅 Original date posted:2015-09-18
📝 Original message:> On 18 Sep 2015, at 22:27, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Google Calendar is localized, but has an option to change the timezone
> of an event, it just doesnt have UTC in its options. So, yes, we should
> use something that observes DST in roughly the same way as everyone else
> - CEST/PDT/EST/etc.
According to this post, it is possible to configure Google Calendar to show an additional time zone to your localized one, and GMT/UTC is indeed in the list.
https://productforums.google.com/forum/#!topic/calendar/y6uaiAdZrIg
-jp
--
Jeffrey Paul EEQJ
jp at eeqj.com https://eeqj.com
+1-800-403-1126 (America) +1-312-361-0355 (Worldwide)
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2

2023-06-07 17:41:24

- reply

📅 Original date posted:2015-07-01
📝 Original message:If people attempt to govern Bitcoin, Bitcoin falls apart.
That's why there is no voting and there are no unnecessary hard forks; Bitcoin operates on consensus.
Engineering and research along these lines is folly, as any attempt to impose such concepts as "voting" will rightfully find itself with nothing to govern.
It is a common misconception that the core devs govern Bitcoin; indeed they are the core devs only because they do not try to govern. I urge you to review the history of the term "unix" for an instructive example of what happens in systems that do not depend on consensus.
And now back to regularly scheduled development, I hope.
Best,
-jp
PS: A personal request to the list: could we please limit ourselves to posting about the research and development of Bitcoin Core? Many of us must stay continually abreast of all progress on Bitcoin Core by reading all of -dev daily and subjecting everyone's email inboxes to hundreds of pet theories about governance and block size opinions without patches or simulations is simply abusing the list membership to soapbox. I encourage you to make blog posts instead and post them to /r/Bitcoin or suchlike versus taking up attention span on an *engineering* mailing list.
--
Jeffrey Paul +1 (312) 361-0355
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
> On 01.07.2015, at 10:45, NxtChg <nxtchg at hush.com> wrote:
>
> (sorry for the long post, I tried)
>
> I've been thinking about how we could build an effective Bitcoin governance, but couldn't come up with anything remotely plausible.
>
> It seems we might go a different way, though, with Core and XT continue co-existing in parallel, mostly in a compatible state, out of the need that "there can be only one".
>
> Both having the same technical protocol, but different people, structure, processes and political standing; serving as a kind of two-party system and keeping each other in check.
>
> Their respective power will be determined by the number of Core vs XT nodes running and people/businesses on board. They will have to negotiate any significant change at the risk of yet another full fork.
>
> And occasionally the full forks will still happen and the minority will have to concede and change their protocol to match the winning side.
>
> Can there be any other way? Can you really control a decentralized system with a centralized governance, like Core Devs or TBF?
>
> ----
>
> In this view, what's happening is a step _towards_ decentralization, not away from it. It proves that Bitcoin is indeed a decentralized system and that minority cannot impose its will.
>
> For the sides to agree now would actually be a bad thing, because that would mean kicking the governance problem down the road.
>
> And we _need_ to go through this painful split at least once. The block size issue is perfect: controversial enough to push the split, but not controversial enough so one side couldn't win.
>
> ----
>
> If this is where we're heading then both sides should probably start thinking of themselves as opposition parties, instead of whatever they think of themselves now.
>
> People and businesses ultimately decide and they need a way to cast a Yes/No vote on proposed changes. Hence the two-party system.
>
> If the split in power is, say, 60/40 and the leading party introduces an unpopular change, it can quickly lose its advantage.
>
> We already have the "democratic party" on the left with Gavin and Mike representing the wish of the majority and the "conservative party" on the right, who would prefer things to stay the way they are.
>
> ----
>
> Finally, I propose to improve the voting mechanism of Bitcoin to serve this new reality better.
>
> Using the upcoming fork as an opportunity, we could add something like 8-byte votes into blocks:
>
> * first 4 bytes: fork/party ID, like 'CORE' or 'XT'
> * second 4 bytes: proposition number
>
> (or at least add the ID somewhere so the parties wouldn't have to negotiate block version numbers).
>
>
> Miners are in the business of mining coins, so they are good "sensors" of where the economic majority will be.
>
> We will have a representative democracy, with miners serving as 'hubs', collecting all the noise and chatter and casting it into a vote.
>
> This is not perfect, but nothing ever is.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:39:05

- reply

📅 Original date posted:2015-06-19
📝 Original message:It seems to me that FSS RBF must enforce identical OP_RETURN data on the output scripts as the first seen transaction, as well, to safely continue support for various other applications built atop the blockchain.
Is there a canonical implementation of FSS RBF around somewhere I can review?
Best,
-jp
--
Jeffrey Paul +1 (312) 361-0355
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
> On 19.06.2015, at 15:52, Chun Wang <1240902 at gmail.com> wrote:
>
> Before F2Pool's launch, I performed probably the only successful
> bitcoin double spend in the March 2013 fork without any mining power.
> [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
> the full RBF is. We are going to switch to FSS RBF in a few hours.
> Sorry.
>
>> On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd <pete at petertodd.org> wrote:
>>> On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
>>> It is disappointing that F2Pool would enable full RBF when the safe
>>> alternative, first-seen-safe RBF, is also available, especially since the
>>> fees they would gain by supporting full RBF over FSS RBF would likely be
>>> negligible. Did they consider using FSS RBF instead?
>>
>> Specifically the following is what I told them:
>>
>>> We are
>>> interested in the replace-by-fee patch, but I am not following the
>>> development closely, more background info is needed, like what the
>>> difference between standard and zeroconf versions? Thanks.
>>
>> Great!
>>
>> Basically both let you replace one transaction with another that pays a
>> higher fee. First-seen-safe replace-by-fee adds the additional criteria
>> that all outputs of the old transaction still need to be paid by the new
>> transaction, with >= as many Bitcoins. Basically, it makes sure that if
>> someone was paid by tx1, then tx2 will still pay them.
>>
>> I've written about how wallets can use RBF and FSS-RBF to more
>> efficiently use the blockchain on the bitcoin-development mailing list:
>>
>> http://www.mail-archive.com/[email protected]/msg07813.html
>> http://www.mail-archive.com/[email protected]/msg07829.html
>>
>> Basically, for the purpose of increasing fees, RBF is something like %50
>> cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
>>
>> In addition, for ease of implementation, my new FSS-RBF has a number of
>> other restrictions. For instance, you can't replace multiple
>> transactions with one, you can't replace a transaction whose outputs
>> have already been spent, you can't replace a transaction with one that
>> spends additional unconfirmed inputs, etc. These restrictions aren't
>> "set in stone", but they do make the code simpler and less likely to
>> have bugs.
>>
>> In comparison my previous standard RBF patch can replace multiple
>> transactions with one, can replace long chains of transactions, etc.
>> It's willing to do more computation before deciding if a transaction
>> should be replaced, with more complex logic; it probably has a higher
>> chance of having a bug or DoS attack.
>>
>> You've probably seen the huge controversy around zeroconf with regard to
>> standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
>> it also doesn't make it any more dangerous, so politically with regard
>> to zeroconf it makes no difference. You *can* still use it doublespend
>> by taking advantage of how different transactions are accepted
>> differently, but that's true of *every* change we've ever made to
>> Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
>> zeroconf in the same way.
>>
>>
>> Having said that... honestly, zeroconf is pretty broken already. Only
>> with pretty heroic measures like connecting to a significant fraction of
>> the Bitcoin network at once, as well as connecting to getblocktemplate
>> supporting miners to figure out what transactions are being mined, are
>> services having any hope of avoiding getting ripped off. For the average
>> user their wallets do a terrible job of showing whether or not an
>> unconfirmed transaction will go through. For example, Schildbach's
>> Bitcoin wallet for Android has no code at all to detect double-spends
>> until they get mined, and I've been able to trick it into showing
>> completely invalid transactions. In fact, currently Bitcoin XT will
>> relay invalid transactions that are doublepsends, and Schildbach's
>> wallet displays them as valid, unconfirmed, payments. It's really no
>> surprise to me that nearly no-one in the Bitcoin ecosystem accepts
>> unconfirmed transactions without some kind of protection that doesn't
>> rely on first-seen-safe mempool behavior. For instance, many ATM's these
>> days know who their customers are due to AML requirements, so while you
>> can deposit Bitcoins and get your funds instantly, the protection for
>> the ATM operator is that they can go to the police if you rip them off;
>> I've spoken to ATM operators who didn't do this who've lost hundreds or
>> even thousands of dollars before giving up on zeroconf.
>>
>> My big worry with zeroconf is a service like Coinbase or Shapeshift
>> coming to rely on it, and then attempting to secure it by gaining
>> control of a majority of hashing power. For instance, if Coinbase had
>> contracts with 80% of the Bitcoin hashing power to guarantee their
>> transactions would get mined, but 20% of the hashing power didn't sign
>> up, then the only way to guarantee their transactions could be for the
>> 80% to not build on blocks containing doublespends by the 20%. There's
>> no way in a decentralized network to come to consensus about what
>> transactions are or are not valid without mining itself, so you could
>> end up in a situation where unless you're part of one of the big pools
>> you can't reliably mine at all because your blocks may get rejected for
>> containing doublespends.
>>
>> One of my goal with standard replace-by-fee is to prevent this scenario
>> by forcing merchants and others to implement ways of accepting zeroconf
>> transactions safely that work in a decentralized environment regardless
>> of what miners do; we have a stronger and safer Bitcoin ecosystem if
>> we're relying on math rather than trust to secure our zeroconf
>> transactions. We're also being more honest to users, who right now often
>> have the very wrong impression that unconfirmed transactions are safe to
>> accept - this does get people ripped off all too often!
>>
>>
>> Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
>> waiting to get some feedback:
>>
>> https://github.com/bitcoin/bitcoin/pull/6176
>>
>> Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
>> working on porting it to v0.10.2, and once that's done I'm going to put
>> up a bounty for anyone who can find a DoS attack in the patch. If no-one
>> claims the bounty after a week or two I think I'll start feeling
>> confident about using it in production.
>>
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:28:30

- reply

📅 Original date posted:2015-01-14
📝 Original message:> On 20150114, at 09:39, devrandom <c1.sf-bitcoin at niftybox.net> wrote:
>
> At CryptoCorp we recommend to our customers that they sort
> lexicographically by the public key bytes of the leaf public keys. i.e.
> the same as BitPay.
To clarify: the raw bytes of the public key itself, not the ascii base58 representation of the pubkey hash - right?
-jp
--
Jeffrey Paul EEQJ
jp at eeqj.com https://eeqj.com
+1-800-403-1126 (America) +1-312-361-0355 (Worldwide)
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2

2023-06-07 17:27:42

- reply

📅 Original date posted:2014-12-04
📝 Original message:> On 20141204, at 07:42, Luke Dashjr <luke at dashjr.org> wrote:
>
> Is anyone working on a serialisation format to convey P2SH HD chains? For
> example, to give someone who wants to make recurring payments a single token
> that can be used to generate many P2SH addresses paying to a multisig script.
>
> I'm thinking of something along the lines of a simple series of tokens, each
> indicating either a HD chain or literal script content. For all HD chains in
> the data, a child key would be generated based on the payment number, and all
> tokens concatenated to form the P2SH serialised script. Eg, for a simple 2-
> of-2, you would do something like this:
> literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG)
> Does this sufficiently cover all reasonable use cases?
What is the use case for something like this? It’s my impression that a single token that can be used to obtain many P2SH addresses paying to a multisig script looks something like
bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new
As it’s impossible to actually transmit a tx without network access, why would it be necessary to, at payment time, not contact the payee and use the existing bip70 authenticated payment request protocol to find out exactly what multisig address they’d like paid at that moment?
The model that you describe where a payer can, without communication with the payee, generate additional multisig p2sh addresses based on a set of xpubs presumes that the payee would never want to e.g. cycle their own keys or change their cooperating multisig participants’ keys. Is this wise?
Lately I’ve been thinking of bitcoin addresses (even multisig) as sort of MX records - something that the paying user shouldn’t depend on being static, because they are derived from keys that may change (or be lost or compromised) over time. The canonical “pay me at this address forever QR code” should be a bitcoin: URI that points to a payment request generating URL, should it not?
Best,
-jp
--
Jeffrey Paul EEQJ
jp at eeqj.com https://eeqj.com
+1-800-403-1126 (America) +1-312-361-0355 (Worldwide)
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2