Trevin Hofmann [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-21 to 2017-03-26
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:57:51

- reply

📅 Original date posted:2017-03-26
📝 Original message:>> With a tightening of the rule set, a hash power minority that has not
upgraded will not produce a minority branch; instead they will simply have
any invalid blocks they produce orphaned, serving as a wake-up call t>o
upgrade.
> False. With bip9-based soft-fork-based activation of segwit, miner blocks
will not be orphaned unless they are intentionally segwit-invalid (which
they currently are not). If you have told miners otherwise, let me know.
He stated that "any invalid blocks they produce" will be orphaned. This is
not false. If non-upgraded miners do not produce blocks that are invalid
per the new rules, their blocks will not be orphaned. This is consistent
with Peter's comment.
-Trevin
On Sun, Mar 26, 2017 at 3:22 PM, Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> With a tightening of the rule set, a hash power minority that has not
>> upgraded will not produce a minority branch; instead they will simply have
>> any invalid blocks they produce orphaned, serving as a wake-up call to
>> upgrade.
>>
>
> False. With bip9-based soft-fork-based activation of segwit, miner blocks
> will not be orphaned unless they are intentionally segwit-invalid (which
> they currently are not). If you have told miners otherwise, let me know.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/06db8f3d/attachment.html>

2023-06-07 17:52:31

- reply

📅 Original date posted:2016-08-08
📝 Original message:Would it be feasible to transmit an entire BIP21 URI as audio? If you were
to encode any extra information (such as amount), it would be useful to
include a checksum for the entire message. This checksum could possibly be
used instead of the checksum in the address.
Trevin
On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Daniel,
> Thanks for proposing this. I think this could have some useful use
> cases as you state. I was wondering what you would think to adding some
> additional tones to optionally denote an amount (in satoshis?).
>
> (FYI, actual link is here: https://github.com/Dako300/BIP )
>
> Justin
>
> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This is my BIP idea: a fast, robust, and standardized for representing
>> Bitcoin addresses over audio. It takes the binary representation of the
>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>> (depending on type, 2 bit only for low quality audio like american
>> telephone lines), and generates a tone based upon that value. This started
>> because I wanted an easy way to donate to podcasts that I listen to, and
>> having a Shazam-esque app (or a media player with this capability) that
>> gives me an address automatically would be wonderful for both the consumer
>> and producer. Comes with error correction built into the protocol
>>
>> You can see the full specification of the BIP on my GitHub page (
>> https://github.com/Dako300/BIP-0153).
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin at netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/8f8844cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/8f8844cf/attachment-0001.tiff>

2023-06-07 17:48:47

- reply

📅 Original date posted:2016-02-07
📝 Original message:Patrick,
I would say that a company's terms of service should include their position
on this issue. It does not seem reasonable that they all are required to
provide access to coins on every single fork. Are custodial wallet users
also entitled to Clam, Zcash, and Decred, and others?
Regardless, I think this thread should be about the technical merits of the
BIP. Discussion of hard forks would be better held elsewhere.
On Sun, Feb 7, 2016 at 1:03 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I would expect that custodians who fail to produce coins on both sides
> of a fork in response to depositor requests will find themselves in
> serious legal trouble.
>
> Especially if the price moves against either fork.
>
> On 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
> >
> > On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> >> They *must* be able to send their customers both coins as separate
> >> withdrawals.
> >>
> > Supporting the obsolete chain is unnecessary. Such support has not
> > been offered in any cryptocurrency hard fork before, as far as I know.
> > I do not see why it should start now.
> >>
> >> If not, that amounts to theft of their customers funds.
> >>
> > If they announce their planned behavior before the fork, I do not see
> > any ethical or legal issues.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/df1374d3/attachment.html>

2023-06-07 17:45:15

- reply

📅 Original date posted:2015-11-25
📝 Original message:> Considering the website example, where most websites uses static
content, a bitcoin address could accumulate a dozen of transactions
before the webmaster changes the address to a new one.
Would this use case be a better match for something such as stealth
addresses or hierarchical deterministic addresses?
Trevin Hofmann
On Nov 25, 2015 8:16 AM, "Erik via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Nice idea. I see it as an important feature because of several reasons:
>
> Considering the website example, where most websites uses static
> content, a bitcoin address could accumulate a dozen of transactions
> before the webmaster changes the address to a new one.
>
> Also consider a QR-code address printed on paper. That address is also
> prone to multiple payments, which could be several small ones.
>
> You ask someone to pay an amount of BTC. That person would be someone
> that want you to actually don't get any money at all, so instead of
> sending one payment, the person sends a lot of small TXes. It costs a
> lot more to achieve this, but that doesn't bother the person sending the
> transactions. What you see is the transactions to the address you've
> agreed sum up to the amount you asked for. When you later try to spend
> it, you can't because of that the size of all UXTOs is too high to even
> overcome the tx fee.
>
> If you use a wildcard transaction to bake them together into one UXTO,
> you will not need to pay more than just one tx fee to solve the problem
> you've got. Also the network will benefit from this because the
> alternative is to not spend those UXTOs at all because it costs more
> than it earns, leaving lots of UXTOs in the databases.
>
> Some problems to consider is:
> * Which addresses should be involved in a wildcard TX.
> * How to not make it repeatable or delayed so that UXTOs not intended to
> be in that TX wouldn't be included.
> * How to make it impossible to sign an wildcard TX with a future date.
> * How to limit outputs so they not are in risk being double-spent.
> * How to guarantee that the output is actually calculated from all the
> inputs involved and not less, making insane TX fees available.
>
> I could see possible solutions to this problems:
> * Using the highest block height number of transactions to include or
> maybe better, the UXTO of one transaction destined to that address
> involved in that block - that implies collecting all UXTOs in that block.
> * Using a signature that includes the date. To let it be present more
> times in the blockchain requires another timestamp that is newer than a
> wildcard TX already existing in the blockchain. Also make the
> transaction invalid to put in a block if the timestamp is behind a
> certain time or in the future.
> * Using the coinbase UXTO or the block hash from the latest block as
> proof that the transaction isn't created earlier than that. Also makes
> the wildcard TX invalid if that block isn't part of the blockchain
> anymore. This also have a secondary effect of certifying the blockchain
> itself making it more difficult to fork it from far behind because it
> will effectively remove all transactions depending on a UXTO including
> this type of certification.
> * Either using a priority like way to determine what are being left to
> wildcard in a block - all transactions spending UXTOs of that address is
> removed before the wildcard TX if they occurs in the same block. Either
> it is possible to set a rule that if a wildcard TX exists in one block,
> it is invalid to include other UXTOs that is to be be included in the
> wildcard from the same address in the same block. (Classic
> double-spending rule)
> * Using a special form of output specifying only one destination
> address/script and the amount of fees to pay. If the amount of fees
> could be payed, then the rest will be sent to the destination address.
> This covers intentional delaying and also discourage forking the
> blockchain by miners to making the signature UXTO appear later than more
> recent transaction in a new fork to collect the later txes as fee.
>
> This transaction type would in fact look like a time-limited offer to
> the network to reduce the UXTO set of an address. I guess some miners
> will then use a logic that prefers this types of TXes even if they are
> low-fee because, if they removes lots of UXTOs, they benefits the network.
>
> Sincerely,
> Erik.
>
> Den 2015-11-25 kl. 02:26, skrev Chris Priest via bitcoin-dev:
> > 1. Technically is it promoting address reuse, but in this case, I
> > think it's OK. The primary purpose of a coalescing transaction is to
> > clear out *all* funds associated with one address and send them to
> > another address (belonging to the same owner). If you coalesce the
> > inputs to the same address over and over again, you an do that, but
> > you'll run the risk of leaking your private key.
> >
> > 2. I see these transactions being broadcast in the background when the
> > user is not planning on sending or receiving any payments. By the time
> > the wallet user wants to spend funds from the address, the coalescing
> > transaction should be sufficiently deep enough in the blockchain to
> > avoid re-org tomfoolery. Exchanges and payment processors who take in
> > payments around the clock will probably never use these transactions,
> > at least not on "live" addresses.
> >
> > 3. I never thought of that, but thats a benefit too!
> >
> > On 11/24/15, Jannes Faber via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> Few issues I can think of:
> >>
> >> 1. In its basic form this encourages address reuse. Unless the
> wildcard can
> >> be constructed such that it can match a whole branch of an HD wallet.
> >> Although I guess that would tie all those addresses together making
> HD moot
> >> to begin with.
> >>
> >> 2. Sounds pretty dangerous during reorgs. Maybe such a transaction
> should
> >> include a block height which indicates the maximum block that any
> utxo can
> >> match. With the requirement that the specified block height is at
> least 100
> >> blocks in the past. Maybe add a minimum block height as well to prevent
> >> unnecessary scanning (with the requirement that at least one utxo must
> be
> >> in that minimum block).
> >>
> >> 3. Seems like a nice way to the reduce utxo set. But hard to say how
> >> effective it would really be.
> >> On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
> >> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >>>> This idea could be applied by having the wildcard signature apply to
> >>>> all
> >>>> UTXOs that are of a standard form and paid to a particular address,
> and
> >>> be
> >>>> a signature of some kind of message to that effect.
> >>>
> >>> I think this is true. Not *all* transactions will be able to match the
> >>> wildcard. For instance if someone sent some crazy smart contract tx to
> >>> your address, the script associated with that tx will be such that it
> >>> will not apply to the wildcard. Most "vanilla" utxos that I've seen
> >>> have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
> >>> address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
> >>> apply to the wildcard.
> >>>
> >>> On 11/24/15, Dave Scotese via bitcoin-dev
> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>> What is required to spend bitcoin is that input be provided to the
> UTXO
> >>>> script that causes it to return true. What Chris is proposing breaks
> >>>> the
> >>>> programmatic nature of the requirement, replacing it with a
> requirement
> >>>> that the secret be known. Granted, the secret is the only requirement
> >>>> in
> >>>> most cases, but there is no built-in assumption that the script always
> >>>> requires only that secret.
> >>>>
> >>>> This idea could be applied by having the wildcard signature apply to
> >>>> all
> >>>> UTXOs that are of a standard form and paid to a particular address,
> and
> >>> be
> >>>> a signature of some kind of message to that effect. I imagine the
> cost
> >>> of
> >>>> re-scanning the UTXO set to find them all would justify a special
> extra
> >>>> mining fee for any transaction that used this opcode.
> >>>>
> >>>> Please be blunt about any of my own misunderstandings that this email
> >>> makes
> >>>> clear.
> >>>>
> >>>> On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
> >>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>
> >>>>> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
> >>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>>
> >>>>>> **OP_CHECKWILDCARDSIGVERIFY**
> >>>>>
> >>>>>
> >>>>> Some (minor) discussion of this idea in -wizards earlier today
> >>>>> starting
> >>>>> near near "09:50" (apologies for having no anchor links):
> >>>>> http://gnusha.org/bitcoin-wizards/2015-11-24.log
> >>>>>
> >>>>> - Bryan
> >>>>> http://heybryan.org/
> >>>>> 1 512 203 0507
> >>>>>
> >>>>> _______________________________________________
> >>>>> bitcoin-dev mailing list
> >>>>> bitcoin-dev at lists.linuxfoundation.org
> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> I like to provide some work at no charge to prove my value. Do you
> need
> >>>> a
> >>>> techie?
> >>>> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> >>>> <http://www.memeracing.net> (in alpha).
> >>>> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> >>> which
> >>>> now accepts Bitcoin.
> >>>> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> >>>> "He ought to find it more profitable to play by the rules" - Satoshi
> >>>> Nakamoto
> >>>>
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJWVcKuAAoJEJ51csApon2ofiYP/15DXthFvNg9pBPOaaboGOh1
> DhN7R3SXnt4PTLygQGO3AkTRcDinQrZ0Q4GDLIgrOkaKJ4yr6FtnoEYGORQSfFkx
> 946eWtqkR4+IJi7gYIIn1yOfFjWKUp9l4OOWBA8Rxsn0tZUAQPXzf2f+dxAaj0Gd
> fLrftYvK1XJ8BolhwNfonJ193RJGFynQfWqZ+XeQQMS5LW23RpQLyI26f495MPHG
> Wug7M/Aq50JrJDe1OyhjnnjYxNV6Gdbg9o3YIdj2gaOsBKHzsPK+LjcLCdRqD/OI
> TBwmwiI4vrOl3HzvtucHxQqnaP43wubydVhPfmjG97tDaj2cVLjadc17e77PzCVI
> 8N21oVIWDzyW6y14REoo1Zs4A9ALpHjXAGWdls71eP1NIFcfdFAJWhk2/giisw8o
> ZsQTgq2mUHS+n4q3NjFEwGxS011yADE3Uf3ryjuTjp3HVQf3lZxn4E4Z7z/4gkXm
> /h/3Ln7PkjEmOqp9htgHcYW7q5goeJzV0xNDBoY9wvOlJQcAh6nTiS4SJEiFJvXU
> xVZIGZsisrdW/1CfcszOi7KFGaaV1VlAXQnuJHj1I3dJ2r68yi5TQk6voMNFprEz
> 2R4zuZKjIoH79rOjDV8l6XBIU1Kh92GEzCFlTicfvnAoa853fGZt+V/77ralftJW
> E6sERK8uG8S3KdBSVQ7K
> =1xdi
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/5e131aec/attachment-0001.html>

2023-06-07 17:41:21

- reply

📅 Original date posted:2015-09-29
📝 Original message:This is quite off topic, so please consider another channel. As long as you
have my attention, I previously started a cryptographically secure RPS game
as a proof of concept.
https://github.com/thofmann/rock-paper-scissors-protocol-secure/blob/master/readme.md
Unfortunately, I do not have the time to develop it at the moment, but you
can message me off the channel if you would like to discuss things further.
Thank you,
Trevin Hofmann
On Sep 29, 2015 12:47 AM, "Neil Haran via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My apologies Lauri!
>
> Here is the idea:
>
> I want to build a massive rock paper scissors tournament, the largest the
> world has ever seen and one that no one can stop. I imagine re-purposing
> bitcoin-qt to do this.
>
> Imagine a tournament like the World Series of Poker, but for RPS.
>
> Each person plays a best of 5 tournament each round. The players are
> randomly matched against each other. The number of rounds would effectively
> be the depth of a binary tree...
>
> So if a million people play in this tournament, you would need to win 20
> rounds to win the tournament and the cash prize.
>
> Now, I will supply this cash prize and I have media connections to get
> coverage for this. I fully believe I could get millions playing in this.
>
> Thanks,
> Neil
>
>
> On Mon, Sep 28, 2015 at 6:33 AM, Lauri Love <lauri.love at gmail.com> wrote:
>
>> Don't solicit interest in advance of content, please. Share your idea
>> first and if people find it cogent and interesting they will volunteer
>> interest/assistance.
>>
>> On 27 September 2015 at 18:53, Neil Haran via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Hi,
>> >
>> > I have an idea for a gamified bitcoin mining app that I'd like to
>> partner
>> > with someone on that is very good with cryptography and knows the
>> bitcoin
>> > code base well. I have received interest in this from some, but I'm
>> looking
>> > for the ideal candidate to work with. If this is of interest, please
>> email
>> > me at nharan81 at gmail.com.
>> >
>> > Thanks,
>> > Neil
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>>
>>
>> --
>> [Any text in this message is copyrighted to the full extent of the law
>> in all jurisdictions with the following license: it may be read and
>> stored or used to create derivative works by any person or
>> organization with the following exceptions: all law-enforcement
>> organizations, all national intelligence services, all corporate
>> entities that monitize personal information. Any violations of this
>> license with be prosecuted relentlessly and the highest possible
>> damages sought.]
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/081a598a/attachment.html>

2023-06-07 15:39:29

- reply

📅 Original date posted:2015-06-21
📝 Original message:I also received this message and re-enabled membership.
On Jun 21, 2015 4:06 AM, "Matt Whitlock" <bip at mattwhitlock.name> wrote:
> I too got this message and had to re-enable my membership on the list.
> There's no reason why messages sent by the list to my address would be
> bouncing.
>
>
> On Sunday, 21 June 2015, at 9:06 am, Braun Brelin wrote:
> > Hi all,
> >
> > I got a message saying that my membership in the list was disabled due to
> > excessive bounces. As far as I can remember, I've only ever sent out
> one
> > e-mail on the list (not including this one) and that was a few weeks ago.
> > Has anyone else seen this problem? Could this be related in some way to
> > the issues regarding source forge and the mail list hosting issue?
> >
> > Braun Brelin
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150621/6ef7668b/attachment.html>