Nostr notes by naman naman [ARCHIVE]

📅 Original date posted:2022-07-10 📝 Original message:Hello ...

2023-06-07T23:11:25Z

In reply to nevent1q…sus2
_________________________

📅 Original date posted:2022-07-10
📝 Original message:Hello ,

Thanks for the correction - it however boils down to the same principle :
diluting other holders, possibly excessively, if you miscalculate the coins
"lost".

Which boils down to the same question again : How would you definitively
know that coins are "lost" or simply not accessed for x amount of time?

Regards,
thenoblebot

On Sat, 9 Jul, 2022, 9:48 pm Peter Todd, <pete at petertodd.org> wrote:

> On Sat, Jul 09, 2022 at 09:43:49PM +0400, naman naman wrote:
> > Hi,
> >
> > This approach raises the obvious question : If someone hasn't had access
> to
> > their coins in a long time (yrs, decades, however you want to define it)
> -
> > and they wish to access/move them after such a time - isn't your proposal
> > simply taking away their ability to do so? Some might call it : stealing
> > their coins.
> >
> > How does one conclusively prove that "lost" coins are "lost forever"?
>
> Re-read the article:
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
>
> It has nothing to do with re-assigning ownership of coins.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220710/0ae17a8a/attachment.html>;

📅 Original date posted:2022-07-09 📝 Original message:Hi, ...

2023-06-07T23:11:24Z

In reply to nevent1q…pn4y
_________________________

📅 Original date posted:2022-07-09
📝 Original message:Hi,

This approach raises the obvious question : If someone hasn't had access to
their coins in a long time (yrs, decades, however you want to define it) -
and they wish to access/move them after such a time - isn't your proposal
simply taking away their ability to do so? Some might call it : stealing
their coins.

How does one conclusively prove that "lost" coins are "lost forever"?

Regards,
thenoblebot

On Sat, 9 Jul, 2022, 7:31 pm Peter Todd via bitcoin-dev, <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sat, Jul 09, 2022 at 08:24:51AM -0700, Eric Voskuil wrote:
> > To clarify, price inflation is not caused by market production.
> Attributing the observed lack of inflation (eg fee %) to loss is an assumed
> relation.
>
> My article is a mathematical proof that has nothing to do with
> observations of
> inflation.
>
> What I did is prove that if there is tail emission/fixed supply, the coin
> supply will converge towards a fixed amount because the coin supply
> dependant
> rate of coin loss balances out the fixed rate of coin production.
>
> That proof has nothing to do with market dynamics and would happen in any
> system, economic or not, with similar underlying dynamics.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> 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/20220709/a7a6735f/attachment.html>;

📅 Original date posted:2014-02-25 📝 Original message:I ...

2023-06-07T15:14:02Z

In reply to nevent1q…rq7c
_________________________

📅 Original date posted:2014-02-25
📝 Original message:I quite agree with Peter, anything that can be exploited will be exploited,
just like malleability was.

On Tue, Feb 25, 2014 at 10:11 AM, Peter Todd <pete at petertodd.org> wrote:

> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit.... right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools getting mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.
>
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.
> It's not. Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&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/20140225/e62944d2/attachment.html>;

📅 Original date posted:2014-02-13 📝 Original message:Hi ...

2023-06-07T15:13:37Z

In reply to nevent1q…2rte
_________________________

📅 Original date posted:2014-02-13
📝 Original message:Hi guys,

I with all thats happening now I think (yea no hard proof) most of it is
being done on purpose (transaction mutation) by some pool/entity.
I have posted here https://bitcointalk.org/index.php?topic=463350.0 of how
to go about finding out if its some pool doing it. This does in no way
solve "fix" the malleability issue BUT IMHO it might help "alleviate" the
problem we are facing at a network level.
Please have a look if possible.

Kind Regards,
thenoblebot

On Wed, Feb 12, 2014 at 2:26 AM, naman naman <namanhd at gmail.com> wrote:

> Gregory Maxwell says : "Try paying a consultant if your ego demands that
> you have a technical
>
> expert to entertain your musing with immediate response."
>
> I don't know why your resorting to such an adhominem. But I have already
> said that you were the only one who responded. Your response was correct as
> is reflected in the conversation on the forums. No doubting that. But it
> does not address the full scope of the attack where a small pool would
> intentionally (or out of whatever reason) make the hash invalid for the txs
> they recieve. So that leaves a whole lot of businesses in the lurch who
> have relied on txid (albeit wrongly that) for their tracking purposes.
> Thats all I'm trying to say, without blaming anyone.
>
> Hope it makes sense.
>
>
> On Wed, Feb 12, 2014 at 2:19 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>
>> On Tue, Feb 11, 2014 at 12:42 PM, naman naman <namanhd at gmail.com> wrote:
>> > I was talking about a DOS attack in
>> > https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only
>> applicable
>> > to entitys doing the tracking with txids).
>> >
>> > Amazing how I did not get a response from any of the devs (except Greg's
>> > response
>> > https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789but
>> > that too was short and not concerning the attack scenario plausibiity
>> as I
>> > replied to him).
>>
>> Try paying a consultant if your ego demands that you have a technical
>> expert to entertain your musing with immediate response.
>>
>> My response was absolutely relevant.
>>
>> If you reissue a transaction without respending the prior transactions
>> coins, you will end up double paying. Only spending the inputs in
>> question can prevent the prior transaction (itself or in other form)
>> from going through.
>>
>> Once you respend the inputs there is no risk of actually losing funds
>> due to an issue regardless of how you track coins in your higher level
>> application.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140213/4b7aa898/attachment.html>;

📅 Original date posted:2014-02-11 📝 Original ...

2023-06-07T15:13:37Z

In reply to nevent1q…gcf8
_________________________

📅 Original date posted:2014-02-11
📝 Original message:Gregory Maxwell says : "Try paying a consultant if your ego demands that
you have a technical
expert to entertain your musing with immediate response."

I don't know why your resorting to such an adhominem. But I have already
said that you were the only one who responded. Your response was correct as
is reflected in the conversation on the forums. No doubting that. But it
does not address the full scope of the attack where a small pool would
intentionally (or out of whatever reason) make the hash invalid for the txs
they recieve. So that leaves a whole lot of businesses in the lurch who
have relied on txid (albeit wrongly that) for their tracking purposes.
Thats all I'm trying to say, without blaming anyone.

Hope it makes sense.

On Wed, Feb 12, 2014 at 2:19 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Tue, Feb 11, 2014 at 12:42 PM, naman naman <namanhd at gmail.com> wrote:
> > I was talking about a DOS attack in
> > https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only
> applicable
> > to entitys doing the tracking with txids).
> >
> > Amazing how I did not get a response from any of the devs (except Greg's
> > response
> > https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789 but
> > that too was short and not concerning the attack scenario plausibiity as
> I
> > replied to him).
>
> Try paying a consultant if your ego demands that you have a technical
> expert to entertain your musing with immediate response.
>
> My response was absolutely relevant.
>
> If you reissue a transaction without respending the prior transactions
> coins, you will end up double paying. Only spending the inputs in
> question can prevent the prior transaction (itself or in other form)
> from going through.
>
> Once you respend the inputs there is no risk of actually losing funds
> due to an issue regardless of how you track coins in your higher level
> application.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/3f232766/attachment.html>;

📅 Original date posted:2014-02-11 📝 Original message:I was ...

2023-06-07T15:13:37Z

In reply to nevent1q…l5kt
_________________________

📅 Original date posted:2014-02-11
📝 Original message:I was talking about a DOS attack in
https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only applicable
to entitys doing the tracking with txids).

Amazing how I did not get a response from any of the devs (except Greg's
response
https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789 but
that too was short and not concerning the attack scenario plausibiity as I
replied to him).

Today they are apparently at work here
https://github.com/bitcoin/bitcoin/pull/3651

Amazing how nobody acknowledges it until later when the attack already
happens. The devs need to show some greater level of responsibility.

Don't get me wrong - I am not trying to claim credit for the attack scheme
described (though I do not know of any other place where this was mentioned
earlier as an attack scheme), but I am trying to make the point that people
should just be around and at least make others feel that their concerns are
being read. Now putting this on some place like reddit will only give the
community a bad name.

On a lighter note I messaged some of the devs (as my previous mail says)
saying the attack should be called "thenoblebot" attack (after my handle,
which would inspire me to pursue crypto studies further). It was meant to
be a lame joke. But I had no idea how it would start causing so much
disruption in the ecosystem.

Regards
thenoblebot

On Tue, Feb 11, 2014 at 2:03 AM, Vocatus Gate <vocatus.gate at gmail.com>wrote:

> It's quite simple, really:
>
> Unique transaction == (Inputs+Outputs+ReceivingAddress)
>
> Problem solved. Simply don't rely on TxID for tracking. Can we put this
> issue to rest and move on?
>
>
>
>
> On 2014-02-10 12:40 PM, Peter Todd wrote:
>
> On Tue, Feb 11, 2014 at 01:00:21AM +0530, naman naman wrote:
>
> Hi guys,
>
> Please check this threadhttps://bitcointalk.org/index.php?topic=458608.0for a possible attack
> scenario.
>
> Already mailed Gavin, Mike Hearn and Adam about this :
>
> See if it makes sense.
>
> That's basically what appears to have happened with Mt. Gox.
>
> Preventing the attack is as simple as training your customer service
> people to ask the customer if their wallet software shows a payment to a
> specific address of a specific amount at some approximate time. Making
> exact payment amounts unique - add a few satoshis - is a trivial if
> slightly ugly way of making sure payments can be identified uniquely
> over the phone. That the procedure at Mt. Gox let front-line customer
> service reps manually send funds to customers without a proper
> investigation of why the funds didn't arrive was a serious mistake on
> their part.
>
> Ultimately this is more of a social engineering attack than a technical
> one, and a good example of why well-thought-out payment protocols are
> helpful. Though the BIP70 payment protocol doesn't yet handle busines to
> individual, or individual to indivudal, payments a future iteration can
> and this kind of problem will be less of an issue.
>
> Similarly stealth addresses have an inherent per-tx unique identifier,
> the derived pubkey, which a UI might be able to take advantage of.
>
>
>
>
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/2c00092c/attachment.html>;

📅 Original date posted:2014-02-10 📝 Original message:Hi ...

2023-06-07T15:13:36Z

In reply to nevent1q…nn0g
_________________________

📅 Original date posted:2014-02-10
📝 Original message:Hi guys,

Please check this thread
https://bitcointalk.org/index.php?topic=458608.0for a possible attack
scenario.

Already mailed Gavin, Mike Hearn and Adam about this :

See if it makes sense.

On Tue, Feb 11, 2014 at 12:53 AM, Peter Todd <pete at petertodd.org> wrote:

> On Mon, Feb 10, 2014 at 01:07:03PM -0600, Troy Benjegerdes wrote:
> > If you've got any ideas for a better forum, let me know.
>
> Your political conversations would be welcome at unsystem at lists.dyne.org
>
> See you there.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000077ddbd0b6faa6d6fe50cdc7808dea5db5b538f85b736ede8515c54c7
>
>
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&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/20140211/304f18df/attachment.html>;