Rodney Morris [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-04-21 to 2017-08-22
💬 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 18:04:57

- reply

📅 Original date posted:2017-08-22
📝 Original message:Thomas et.al.
So, in your minds, anyone who locked up coins using CLTV for their child to
receive on their 21st birthday, for the sake of argument, has effectively
forfeit those coins after the fact? You are going to force anyone who took
coins offline (cryptosteel, paper, doesn't matter) to bring those coins
back online, with the inherent security risks?
In my mind, the only sane way to even begin discussing an approach
implementing such a thing - where coins "expire" after X years - would be
to give the entire ecosystem X*N years warning, where N > 1.5. I'd also
suggest X would need to be closer to the life span of a human than zero.
Mind you, I'd suggest this "feature" would need to be coded and deployed as
a future-hard-fork X*N years ahead of time. A-la Satoshi's blog post
regarding increasing block size limit, a good enough approximation would be
to add a block height check to the code that approximates X*N years, based
on 10 minute blocks. The transparency around such a change would need to
be radical and absolute.
I'd also suggest that, similar to CLTV, it only makes sense to discuss
creating a "never expire" transaction output, if such a feature were being
seriously considered.
If you think discussions around a block size increase were difficult, then
we'll need a new word to describe the challenges and vitriol that would
arise in arguments that will follow this discussion should it be seriously
proposed, IMHO.
I also don't think it's reasonable to conflate the discussion herein with
discussion about what to do when ECC or SHA256 is broken. The
weakening/breaking of ECC poses a real risk to the stability of Bitcoin -
the possible release of Satoshi's stash being the most obvious example -
and what to do about that will require serious consideration when the time
comes. Even if the end result is the same - that coins older than "X" will
be invalidated - everything else important about the scenarios are
different as far as I can see.
Rodney
>
>
> Date: Tue, 22 Aug 2017 13:24:05 -0400
> From: Thomas Guyot-Sionnest <dermoth at aei.ca>
> To: Erik Aronesty <erik at q32.com>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>, Chris Riley
> <criley at gmail.com>
> Cc: Matthew Beton <matthew.beton at gmail.com>
> Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
> Message-ID: <4c39bee6-f419-2e36-62a8-d38171b15558 at aei.ca>
> Content-Type: text/plain; charset="windows-1252"
>
> In any case when Hal Finney do not wake up from his 200years
> cryo-preservation (because unfortunately for him 200 years earlier they
> did not know how to preserve a body well enough to resurrect it) he
> would find that advance in computer technology made it trivial for
> anyone to steal his coins using the long-obsolete secp256k1 ec curve
> (which was done long before, as soon as it became profitable to crack
> down the huge stash of coins stale in the early blocks)
>
> I just don't get that argument that you can't be "your own bank". The
> only requirement coming from this would be to move your coins about once
> every 10 years or so, which you should be able to do if you have your
> private keys (you should!). You say it may be something to consider when
> computer breakthroughs makes old outputs vulnerable, but I say it's not
> "if" but "when" it happens, and by telling firsthand people that their
> coins requires moving every once in a long while you ensure they won't
> do stupid things or come back 50 years from now and complain their
> addresses have been scavenged.
>
> --
> Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170823/8ee044f4/attachment.html>

2023-06-07 17:58:40

- reply

📅 Original date posted:2017-03-31
📝 Original message:I didn't say typical, I said every. Currently a raspberry pi on shitty adsl
can run a full node. What's wrong with needing a high end pc and good
connectivity to run a full node?
People that want to, can. People that don't want to, won't, no matter how
low spec the machine you need.
If nobody uses bitcoin, all the security in the world provides no value.
The value of bitcoin is provided by people using bitcoin, and people will
only use bitcoin if it provides value to them. Security is one aspect
only. And the failure to understand that is what has led to the block size
debate.
Rodney
On 1 Apr 2017 10:12, "Eric Voskuil" <eric at voskuil.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote:
> If the obsession with every personal computer being able to run a
> fill node continues then bitcoin will be consigned to the dustbin
> of history,
The cause of the block size debate is the failure to understand the
Bitcoin security model. This failure is perfectly exemplified by the
above statement. If a typical personal computer cannot run a node
there is no security.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY3uJ8AAoJEDzYwH8LXOFOrBoH/1VdXQObKZ2JPHL387Sd8qT4
zzWt8tKFD+6/uCS8re97h1lZcbwb3EzBOB1J15mJ3fqTOU/rPCitN+JZAMgpw/z9
NGNp4KQDHo3vLiWWOq2GhJzyVAOcDKYLsY8/NrHK91OtABD2XIq9gERwRoZZE4rb
OPSjSAGvDK8cki72O7HpyEKX5WEyHsHNK/JmBDdTjlzkMcNEbBlYMgO24RC6x+UA
8Fh17rOcfGv6amIbmS7mK3EMkkGL83WmsgJKXNl4inI1R8z5hVKRqOFMPxmTDXVc
dEHtw8poHOX1Ld85m0+Tk2S7IdH66PCnhsKL9l6vlH02uAvLNfKxb+291q2g3YU=
=HPCK
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/748c1f45/attachment.html>

2023-06-07 17:58:30

- reply

📅 Original date posted:2017-03-31
📝 Original message:You guessed wrong. Multiple data centres are as much about redundancy and
resiliency, and latency.
As for the cost, data centre space, business grade communication lines, and
staff are orders of magnitude more expensive than the physical hardware
they support.
I'd like to call you out on your continuing reduction to absurdity and
slippery slope arguments. Just because we can't handle 4GB blocks today,
doesn't mean we shouldn't aim in that direction. Doesn't mean we shouldn't
be taking our first second and third baby steps in that direction.
If the obsession with every personal computer being able to run a fill node
continues then bitcoin will be consigned to the dustbin of history, a
footnote to the story of the global crypto currency that eventually took
over the world.
Thanks
Rodney
Date: Fri, 31 Mar 2017 12:14:42 -0400
From: David Vorick <david.vorick at gmail.com>
To: Jared Lee Richardson <jaredr26 at gmail.com>
Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Message-ID:
<CAFVRnyqSMVj2Ttc4_5vuk73Z5yRJdxeSodvkdjqsrHbgghcmUQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Then explain why PayPal has multiple datacenters. And why Visa has multiple
datacenters. And why the banking systems have multiple datacenters each.
I'm guessing it's because you need that much juice to run a global payment
system at the transaction volumes that they run at.
Unless you have professional experience working directly with transaction
processors handling tens of millions of financial transactions per day, I
think we can fully discount your assessment that it would be a rounding
error in the budget of a major exchange or Bitcoin processor to handle that
much load. And even if it was, it wouldn't matter because it's extremely
important to Bitcoin's security that it's everyday users are able to and
are actively running full nodes.
I'm not going to take the time to refute everything you've been saying but
I will say that most of your comments have demonstrated a similar level of
ignorance as the one above.
This whole thread has been absurdly low quality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/54de6975/attachment-0001.html>

2023-06-07 17:36:19

- reply

📅 Original date posted:2015-08-17
📝 Original message:Words cannot capture how much I wish Satoshi had put logic like this (or
even just a simple block size doubling every reward halving) in place when
he put in the "temporary" 1MB anti-spam block size limit...
I see problems to this approach. The biggest one I see is that a miner
with 11% of hash power could sabotage block size increases by only ever
mining empty blocks.
I haven't run any statistics or simulations, but I'm concerned that the
interplay between the random distribution of transaction arrival and the
random distribution of block times may lead to false signals.
A 90% full block 1 minute after the previous block is a more "serious"
problem than a 90% full block 30 minutes after the previous block. A 90%
full block after a 90% full block is a more "serious" problem than a 90%
full block after an empty block.
I would expect a robust approach in this manner to look at block sizes
weighted by block times, but this is an interesting proposal regardless.
But I think you'll run up against one of the great schisms in this debate -
those that believe blocks should always be full (or close to it), to
encourage a "fee market" and to encourage off-chain transactions, and those
that think that the blockchain should be useable by almost anyone for
almost anything, implying there should always be spare space in blocks,
with off-chain transactions reserved for microtransactions and zero-conf
(and possibly low-fee transactions). At least, that's my take on it.
Rodney
>
>
> Date: Mon, 17 Aug 2015 11:51:26 +0100
> From: Btc Drak <btcdrak at gmail.com>
> To: Patrick Strateman <patrick.strateman at gmail.com>
> Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
> Max Cap
> Message-ID:
> <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=
> vVyw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Nobody is going to click that...
>
> I guess I am nobody. Here's a copy of the text:-
>
> *Dynamically Controlled Bitcoin Block Size Max Cap
> <http://upalc.com/maxblocksize.php>*
>
> *Assumption*: This article is for those, who already understand the bitcoin
> protocol and aware of the block size controversy. Details of the problem
> statement can be found in BIP 100
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
> Satoshi's opinion regarding block size can be found here
> <https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will
> be
> directly going into the solution without explaining the problem in details.
>
>
> *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
> block each full node does a calculation to find the next target. We will do
> just another calculation here. Nodes will also calculate what % of blocks
> in the last difficulty period is higher than 90% of the maximum block size,
> which is 1 MB for now. If it is found that more than 90% blocks in the last
> difficulty period is higher than 90% of the maximum block size, then double
> the maximum block size. If not, then calculate what % of blocks in the last
> difficulty period is less than 50% of the maximum block size. If it is
> higher than 90%, then half the maximum block size. If none of the above
> condition satisfies, keep the maximum block size as it is.
>
> Please note that, while calculating the % of blocks, it is better to take
> into account the first 2000 of the 2016, than the whole of 2016. This helps
> to avoid the calculation mistake if some of the last few blocks get
> orphaned.
>
>
> *Reasoning*: This solution is derived directly from the indication of the
> problem. If transaction volume increases, then we will naturally see bigger
> blocks. On the contrary, if there are not enough transaction volume, but
> maximum block size is high, then only few blocks may sweep the mempool.
> Hence, if block size is itself taken into consideration, then maximum block
> size can most rationally be derived. Moreover, this solution not only
> increases, but also decreases the maximum block size, just like difficulty.
>
>
> *Other Solutions of this Problem*:-
>
> Making Decentralized Economic Policy
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
> Jeff Garzik
>
> Elastic block cap with rollover penalties
> <https://bitcointalk.org/index.php?topic=1078521> ? by Meni Rosenfeld
>
> Increase maximum block size
> <https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by
> Gavin
> Andresen
>
> Block size following technological growth
> <https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
>
> The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
> <https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
> Thaddeus Dryja
>
>
> Please share your opinion regarding this solution below. For mail
> communication, feel free to write me at bitcoin [at] upalc.com.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/29fde6cb/attachment.html>

2023-06-07 15:47:54

- reply

2023-06-07 15:19:16

- reply

📅 Original date posted:2014-04-21
📝 Original message:Not a bad idea. Semantics of the word abuse not withstanding.
I don't want to become the self appointed mailing list cop, but I notice it
maybe more than others because I almost exclusively read this mailing list
on a mobile device. Hence my asking for feedback without publicly calling
anyone out.
Thanks for taking the time to reply.
Rodney
On 21/04/2014 3:47 pm, "Wladimir" <laanwj at gmail.com> wrote:
> On Mon, Apr 21, 2014 at 6:58 AM, Rodney Morris <rodney.morris at gmail.com>
> wrote:
> > What is the procedure for dealing with it? Is it considered abuse to
> reply
> > to and quote the entire digest for the sake of a few lines of content?
> Am I
> > the only one annoyed by this (if so I'll just shut right up).
>
> I would not go as far as calling it 'abuse' if it is not done on
> purpose. Probably the person doesn't even know he/she is doing this.
> Best to mail the person and ask (nicely) instead of complaining to the
> list.
>
> Wladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/9cd49c00/attachment.html>

2023-06-07 15:19:15

- reply

📅 Original date posted:2014-04-21
📝 Original message:What is the procedure for dealing with it? Is it considered abuse to reply
to and quote the entire digest for the sake of a few lines of content? Am I
the only one annoyed by this (if so I'll just shut right up).
Rodney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/df8dfb85/attachment.html>