Neil Fincham [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-09-29 to 2017-05-18
💬 Posted a total of 5 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-09 12:47:20

- reply

📅 Original date posted:2017-05-18
📝 Original message:
Hi List,
I have a question and if it has been discussed before please just point me
to it and tell me to f off :) . Also, if I am grossly misunderstanding
things please feel free to correct me.
Is there a way to deterministic generate H?
Further explanation:
* With bitcoin addresses we have BIP32 that allows us to generate a Master
Private Key, transform it to a Master Public Key and then use that Master
Public Key to generate a series of addresses.
We can generate addresses without the use of the private keys.
* With LN we generate a random value S and hash it into H and distribute
that and then finally distribute S in order to close the channel.
SO, my question:
Is there a way to deterministic generate H like you can generate addresses
with a Master Public Key without revealing S to the generator and still
being safe to use S to close the channel? (Hopefully I am not just
confused and talking bullshit here)
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170519/95ca0670/attachment.html>

2023-06-07 17:32:49

- reply

📅 Original date posted:2015-08-04
📝 Original message:> Researchers should also keep in mind that some of developers are immature
and have limited knowledge or experience beyond their Bitcoin expertise
("Idiot-savants"). Others want to be in "charge" of drama-laced posts on
reddit and they get upset if others do the same things.
> In any case these rants and attacks by Todd and Garzik should be posted
on their personal blogs or reddit instead of this list.
I very rarely comment on list politics but isn't this the kettle calling
the pot black?
Back to my hole now I promise.
On 5 August 2015 at 12:26, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> For those wishing to do actual research, esp. people such as profs
>> mentoring students, ...
>>
>
> But keep in mind that you're wading into a highly politically charged
>> research field
>> with billions hanging on the blocksize limit; understand that people
>> aren't happy when
>> flawed papers end up on reddit being used to promote bad ideas. You'd be
>> wise to run future
>> work past experts in the field prior to publishing widely if you dislike
>> heated controversy.
>>
>
> Or, I could just point out the obvious rather than try to be polite: you
>> know exactly why
>> the above makes no sense as a reply to this thread and are deliberately
>> lying.
>>
>
> If the situation is the latter, your conduct is toxic to the development
>> mailing list
>> discussion, not to mention a waste of all our time, and you should leave.
>>
>
>
>
>
> Researchers should also keep in mind that some of developers are immature
> and have limited knowledge or experience beyond their Bitcoin expertise
> ("Idiot-savants"). Others want to be in "charge" of drama-laced posts on
> reddit and they get upset if others do the same things.
>
> In any case these rants and attacks by Todd and Garzik should be posted on
> their personal blogs or reddit instead of this list.
>
> Russ
>
>
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
[image: Facebook] <https://www.facebook.com/MineForeman>
[image: Twitter] <https://twitter.com/mineforeman>
[image: LinkedIn] <http://www.linkedin.com/company/mineforeman-com>
Neil Fincham
MineForeman
Phone: +64 21 545 583
99 Sala St, Rotorua, New Zealand. 3010
Website <http://mineforeman.com/> | neil at mineforeman.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/44f9512d/attachment.html>

2023-06-07 15:45:04

- reply

2023-06-07 15:31:40

- reply

📅 Original date posted:2015-03-01
📝 Original message:> Seems like a good deal, what am I missing?
The disruption caused to every other user or the bitcoin network.
Transactions unconfirmed, history is rewritten, the poor Byzantine General
who sent his soldiers off to battle finds out that his scouts have been
paid to change their reports.
Neil
On 2 March 2015 at 06:59, Troy Benjegerdes <hozer at hozed.org> wrote:
> So let's play this out a little.. Let's call it "Solomon's spend[1]"
>
> Exchange gets hacked, bitcoins move.
>
> The exchange has a contract with an insurance company and miners for
> 'scorched earth' theft response that creates a double-spend of the
> original transaction.
>
> So now there's a 10,000 bitcoin incentive for miners to roll back the
> chain and start (re)mining the block where the theft occurred.
>
> The exchange gets an insurance payout, some miner wins the lottery, and
> the thief gets nothing. Seems like a good deal, what am I missing?
>
> [1] http://en.wikipedia.org/wiki/Judgment_of_Solomon
>
> On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote:
> > I should note that my proposal does require a change to the consensus
> > rules...but getting bitcoin to scale will require this no matter what.
> >
> > - Eric Lombrozo
> > On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:
> >
> > > It seems to me we're confusing two completely different motivations for
> > > double-spending. One is the ability to replace a fee, the other is the
> > > ability to replace outputs.
> > >
> > > If the double-spend were to merely add or remove inputs (but keep at
> least
> > > one input in common, of course), it seems fairly safe to assume it's
> the
> > > former, a genuine fee replacement. Even allowing for things like
> coinjoin,
> > > none of the payees would really care either way.
> > >
> > > Conversely, if at least one of the inputs were kept but none of the
> > > outputs were, we can be confident it's the the latter.
> > >
> > > It is possible to build a wallet that always does the former when doing
> > > fee replacement by using another transaction to create an output with
> > > exactly the additional desired fee.
> > >
> > > If we can clearly distinguish these two cases then the fee replacement
> > > case can be handled by relaying both and letting miners pick one or the
> > > other while the output replacement case could be handled by rewarding
> > > everything to a miner (essentially all outputs are voided...made
> > > unredeemable...and all inputs are added to coinbase) if the miner
> includes
> > > the two conflicting transactions in the same block.
> > >
> > > Wouldn't this essentially solve the problem?
> > >
> > > - Eric Lombrozo
> > > On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik at bitpay.com> wrote:
> > >
> > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon at jtimon.cc>
> wrote:
> > >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik at bitpay.com>
> > >> wrote:
> > >> >> This isn't some theoretical exercise. Like it or not many use
> > >> >> insecure 0-conf transactions for rapid payments. Deploying
> something
> > >> >> that makes 0-conf transactions unusable would have a wide, negative
> > >> >> impact on present day bitcoin payments, thus "scorched earth"
> > >>
> > >> > And maybe by maintaining first seen policies we're harming the
> system
> > >> > in the long term by encouraging people to widely deploy systems
> based
> > >> > on extremely weak assumptions.
> > >>
> > >> Lacking a coded, reviewed alternative, that's only a platitude.
> > >> Widely used 0-conf payments are where we're at today. Simply ceasing
> > >> the "maintaining [of] first seen policies" alone is simply not a
> > >> realistic option. The negative impact to today's userbase would be
> > >> huge.
> > >>
> > >> Instant payments need a security upgrade, yes.
> > >>
> > >> --
> > >> Jeff Garzik
> > >> Bitcoin core developer and open source evangelist
> > >> BitPay, Inc. https://bitpay.com/
> > >>
> > >>
> > >>
> ------------------------------------------------------------------------------
> > >> 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
>
>
> --
>
> ----------------------------------------------------------------------------
> Troy Benjegerdes 'da hozer'
> hozer at hozed.org
> 7 elements earth::water::air::fire::mind::spirit::soul
> grid.coop
>
> Never pick a fight with someone who buys ink by the barrel,
> nor try buy a hacker who makes money by the megahash
>
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150302/aecaa366/attachment.html>

2023-06-07 15:24:36

- reply

📅 Original date posted:2014-07-30
📝 Original message:I am also seeing these quite bit on my p2pool box.
Right now it is just a bit of (mostly) harmless spam but in the future I
can see this kind of thing being used in DDOS attacks and "deep scans" to
gather information to be used to harm the bitcoin network. We could easily
block them but then they would just start to spoof regular clients.
We cannot even authenticate them by asking something that only a full
client would know because that would catch out clients sync'ing the
blockchain and SPV clients.
I suspect it is something that is going to have to be dealt with in the
future (I just don't know how yet). We could start by dropping connections
that send incorrect information (IP addresses of 0.0.0.0 or our own IP).
Neil
On 31 July 2014 01:57, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> At least my crawler (bitcoin-seeder:0.01) software shouldn't reconnect
> more frequently than once every 15 minutes. But maybe the two
> connections you saw were instances?
>
> On Wed, Jul 30, 2014 at 3:50 PM, Wladimir <laanwj at gmail.com> wrote:
> >> The version message helpfully tells me my own IP address but not theirs
> ;p
> >
> > Try -logips. Logging peer IPs was disabled by default after #3764.
> >
> > BTW I'm seeing the same abusive behavior. Who is running these? Why do
> > the requests need to be so frequent?
> >
> > Wladimir
> >
> >
> ------------------------------------------------------------------------------
> > Infragistics Professional
> > Build stunning WinForms apps today!
> > Reboot your WinForms applications with our WinForms controls.
> > Build a bridge from your legacy apps to the future.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20140731/ac2b48a5/attachment.html>

2023-06-07 15:07:02

- reply

📅 Original date posted:2013-09-28
📝 Original message:I subscribe to this list so I can keep up-to date with bitcoin development,
can we keep philosophy and tax evasion out of it?
Neil
On 29 September 2013 09:15, <rob.golding at astutium.com> wrote:
> > But the regulatory environment in many geographical regions in
> > uncertain. Do we need to pay capital gains? Do we need to pay a
> > sales taxs etc. etc.
>
> In most regions it's not only 'simple' but trivial - BTC is just
> 'another currency' and accounted for exactly the same way - it doens't
> matter if you sell your hose for GBP, USD, EUR, BTC or sacks of Pig
> Dung, you still have a GBP tax issue ...
>
> > So my idea is to voluntarily pre empt legislation by giving donations
> > to govt (aka taxation) for bitcoin service providers.
>
> You want to volunteer to pay tax ? I'd suggest stronger medication ...
>
> > However, there is something of a problem with voluntary donations.
> > Most people are not satisfied with the way they are spent.
>
> 80% of 'donations' end up spent on 'adminsitration' and not what they
> were donated for, this is a 'greed' issue not a 'currency' issue.
>
> > In the UK
> > a recent survey said that only 18% of people thought that tax money
> > was wisely spent.
>
> Tax isn't voluntary or a donation. The 18% who think UK tax is well
> spent are the 18% of the population who get the tax money, not the 82%
> that pay it ;)
>
> > Can we fix it?
>
> First we kill all the politicians ...
>
> > So let's say I run a business and I make 1 million euros. I wish to
> > donate 10% of my profits to society. But let's say I dont want that
> > money to go to wars of aggression, but rather, to the fire
> > de[department.
>
> So give it to the FD - what you do with your post-tax profits are up to
> you ;)
>
> > At this point everyone wins. The business person is happy to make a
> > contribution. The govt. is happy that it gets more revenue. The
> > fire dept. is happy that it has revenue to do its work. And
> > everything has gone to the right place in a kind of democratic way.
>
> Where does gov't come into this ? I think you're confusing 'tax' which
> you have zero control over and 'donations' which you already have 100%
> control over.
>
> Rob
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130929/acf2c2d6/attachment.html>