<unnamed>

Public Key

npub1zwqjevtyx2gsgvu6my8zuaumq809qmmss7r8vpd48k3xrttys5qqs76ahu

Profile Code

nprofile1qqsp8qfvk9jr9ygyxwddjr3ww7dsrhjsdacg0pnkqk6nmgnp44jg2qqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqrdrhkz

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 10:09:16 UTC

- reply

📅 Original date posted:2012-05-24
📝 Original message:I think you need the stronger change. Otherwise, the mystery miner could
just put in a few transactions to himself to mask his block. His block
would appear to be of some use while not being helpful.
-Arthur
On Thu, May 24, 2012 at 9:33 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block < X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
>
> The former is easier to implement, though there is the danger that
> no-TX miners simply include a statically generated transaction or two.
>
> The latter might be considered problematic, as it might refuse to
> relay quickly found blocks.
>
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> 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/20120524/a20243f8/attachment.html>

2023-06-07 02:05:43 UTC

- reply

📅 Original date posted:2011-07-16
🗒️ Summary of this message: Luke-Jr suggests overwriting old wallet.dat with random data to secure-delete it. Arthur suggests writing zeros once is sufficient.
📝 Original message:On Thu, Jul 14, 2011 at 7:50 PM, Luke-Jr <luke at dashjr.org> wrote:
> Just wanted to get these suggestions out here:
> 1. Write over the old, unencrypted wallet.dat a couple of times with
> pseudo-
> random data in an attempt to secure-delete it.
>
Writing zeros just once should be sufficient:
http://cmrr.ucsd.edu/people/Hughes/DataSanitizationTutorial.pdf
-Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110716/53d6f237/attachment.html>