<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: A sjsqd walks into a pub...</title>
	<atom:link href="http://trilema.com/2015/a-sjsqd-walks-into-a-pub/feed/" rel="self" type="application/rss+xml" />
	<link>http://trilema.com/2015/a-sjsqd-walks-into-a-pub/</link>
	<description>Moving targets for a fast crowd.</description>
	<pubDate>Wed, 10 Jun 2026 02:23:18 +0000</pubDate>
	<generator>http://polimedia.us</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Check out this demented fuck on Trilema - A blog by Mircea Popescu.</title>
		<link>http://trilema.com/2015/a-sjsqd-walks-into-a-pub/#comment-161763</link>
		<dc:creator>Check out this demented fuck on Trilema - A blog by Mircea Popescu.</dc:creator>
		<pubDate>Sat, 27 Mar 2021 01:42:16 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=60376#comment-161763</guid>
		<description>[...] sjsqd walks into a pub, and Stevegarywhatever's going to... what is he going to do ? He's going to yell [...]</description>
		<content:encoded><![CDATA[<p>[...] sjsqd walks into a pub, and Stevegarywhatever's going to... what is he going to do ? He's going to yell [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A Review of the Bitcoin Category on trilema.com &#171; Ossa Sepia</title>
		<link>http://trilema.com/2015/a-sjsqd-walks-into-a-pub/#comment-148077</link>
		<dc:creator>A Review of the Bitcoin Category on trilema.com &#171; Ossa Sepia</dc:creator>
		<pubDate>Fri, 27 Mar 2020 19:31:02 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=60376#comment-148077</guid>
		<description>[...] adnotated failed introduction of a newcomer to #trilema. [...]</description>
		<content:encoded><![CDATA[<p>[...] adnotated failed introduction of a newcomer to #trilema. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mircea Popescu</title>
		<link>http://trilema.com/2015/a-sjsqd-walks-into-a-pub/#comment-112528</link>
		<dc:creator>Mircea Popescu</dc:creator>
		<pubDate>Fri, 06 Mar 2015 21:56:50 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=60376#comment-112528</guid>
		<description>Anon's idea is not bad imo. 

However, as Peter Lambert points out, even as trivial a fix as "allow user to select change address" would go a very long way to resolve the problem. You could have a clicked-by-default checkbox saying 'generate new address' with an optional field where user can supply an arbitrary address.

The automatically-generated-change-address-for-all-sent-tx model currently in place is very weak, weak to the degree of perhaps being deliberately so. It allows some presumptions to be made by an attacker that should never be allowed.</description>
		<content:encoded><![CDATA[<p>Anon's idea is not bad imo. </p>
<p>However, as Peter Lambert points out, even as trivial a fix as "allow user to select change address" would go a very long way to resolve the problem. You could have a clicked-by-default checkbox saying 'generate new address' with an optional field where user can supply an arbitrary address.</p>
<p>The automatically-generated-change-address-for-all-sent-tx model currently in place is very weak, weak to the degree of perhaps being deliberately so. It allows some presumptions to be made by an attacker that should never be allowed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Lambert</title>
		<link>http://trilema.com/2015/a-sjsqd-walks-into-a-pub/#comment-112521</link>
		<dc:creator>Peter Lambert</dc:creator>
		<pubDate>Fri, 06 Mar 2015 12:44:34 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=60376#comment-112521</guid>
		<description>&#62; How would you implement it ?

The problem now is that during the course of normal use, wallet backups become stale as new addresses are generated for change. 

How about -- the wallet generates a (user) specified number of addresses, and uses ONLY those as change addresses and receiving addresses. If the addresses are all used, it should give a message to the user (perhaps have an option of whether to give you this message or just ignore it?). When the user wants, they can generate another batch of addresses. Thus the user will know when they need to make a new backup, since they are the one who decides when to add new addresses to the wallet.</description>
		<content:encoded><![CDATA[<p>&gt; How would you implement it ?</p>
<p>The problem now is that during the course of normal use, wallet backups become stale as new addresses are generated for change. </p>
<p>How about -- the wallet generates a (user) specified number of addresses, and uses ONLY those as change addresses and receiving addresses. If the addresses are all used, it should give a message to the user (perhaps have an option of whether to give you this message or just ignore it?). When the user wants, they can generate another batch of addresses. Thus the user will know when they need to make a new backup, since they are the one who decides when to add new addresses to the wallet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: anon</title>
		<link>http://trilema.com/2015/a-sjsqd-walks-into-a-pub/#comment-112519</link>
		<dc:creator>anon</dc:creator>
		<pubDate>Fri, 06 Mar 2015 08:02:10 +0000</pubDate>
		<guid isPermaLink="false">http://trilema.com/?p=60376#comment-112519</guid>
		<description>How about -- require user to feed wallet file with significant entropy, proceed to generate addresses on the basis of that (hash and salt, hash and salt). Whenever the user feels like it, he can replace the entropy seed and the salt, thus invalidating his old backups. For as long as the user doesn't feel like it, the security of generated addresses slowly decays (but is still, for at least the first however many decades, massively ahead of the security of addresses generated by the currently deployed scheme).</description>
		<content:encoded><![CDATA[<p>How about -- require user to feed wallet file with significant entropy, proceed to generate addresses on the basis of that (hash and salt, hash and salt). Whenever the user feels like it, he can replace the entropy seed and the salt, thus invalidating his old backups. For as long as the user doesn't feel like it, the security of generated addresses slowly decays (but is still, for at least the first however many decades, massively ahead of the security of addresses generated by the currently deployed scheme).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
