Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

2021-12-12 Thread Karl via bitcoin-dev
On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Indeed, I reiterate that using the Tor network for Bitcoin or whatever > protocol not related to the Tor Browser (ie browsing and HS) does not make > sense, for plenty of reasons >

Re: [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning

2021-12-06 Thread Karl via bitcoin-dev
Hi, I'm not a bitcoin developer. On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > I’ve been thinking about how OP_RETURN is being used to create and trade > NFTs on Bitcoin (think RarePepes, SoG and other

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

2021-08-19 Thread Karl via bitcoin-dev
Something that could work really well here could be having a norm of using the checksum for bright colors, weights, sizes, capitalizations, and/or spacing of the characters of the address, making different addresses more clearly visually distinct. Ethereum uses mixed case to do this a little bit:

Re: [bitcoin-dev] Removing the Dust Limit

2021-08-09 Thread Karl via bitcoin-dev
Why would removing the dust limit impact decentralisation of mining if miners can reconfigure the dust limit for their mined blocks? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Reducing block reward via soft fork

2021-05-25 Thread Karl via bitcoin-dev
If bitcoin were to ever consider changing their PoW algorithm a little, it seems that would immediately make purchased ASIC mining equipment partially or wholly unusable to compromise the chain (and temporarily reduce energy usage without necessarily reducing security). One possible plan to deter

Re: [bitcoin-dev] Reducing block reward via soft fork

2021-05-23 Thread Karl via bitcoin-dev
>> The turn-around time for that takes a population of both users and >> miners to cause. Increasing popularity of bitcoin has a far bigger >> impact here, and it is already raising fees and energy use at an >> established rate. >> >> If it becomes an issue, as bandwidth increases block size could

Re: [bitcoin-dev] Reducing block reward via soft fork

2021-05-23 Thread Karl via bitcoin-dev
On 5/23/21, ZmnSCPxj via bitcoin-dev wrote: > Good morning James, > >> Background >> === >> Reducing the block reward reduces the incentive to mine. It reduces the >> maximum energy price at which mining is profitable, reducing the energy >> use. >> > > If people want to retain previous levels of

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

2021-05-17 Thread Karl via bitcoin-dev
On 5/16/21, Eric Voskuil via bitcoin-dev wrote: > https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox > https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy The chain security actually reduces by 10% in this proposal. So the efficiency paradox is not

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

2021-05-16 Thread Karl via bitcoin-dev
> 1. Has anyone considered that it might be technically not possible to > completely 'power down' mining rigs during this 'cool-down' period of time? > While modern CPUs have power-saving modes, I am not sure about ASICs used for > mining. Sounds like a point to consider, note the economic

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

2021-05-16 Thread Karl via bitcoin-dev
[sorry if I haven't replied to the other thread on this, I get swamped by email and don't catch them all] This solution is workable but it seems somewhat difficult to me at this time. The clock might be implementable on a peer network level by requiring inclusion of a transaction that was

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-09 Thread Karl via bitcoin-dev
On Sun, May 9, 2021, 6:21 AM R E Broadley < rebroad+linuxfoundation@gmail.com> wrote: > On Sat, 8 May 2021 at 15:36, Karl via bitcoin-dev > wrote: > > Bitcoin would get better mainstream public reputation if the block > reward were reduced to reduce mining. This wou

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-08 Thread Karl via bitcoin-dev
Bitcoin would get better mainstream public reputation if the block reward were reduced to reduce mining. This would quickly and easily reduce energy expenditure. A system would be needed to do that with consensus, to make it political. For example, making a norm of extending the block reward

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

2021-04-30 Thread Karl via bitcoin-dev
A good solution here is to make it clear to visitors that facilitation, mediation, and organisation help is badly needed in the core development team. People with such expertise can even be hired directly. A good facilitator opens communication paths between all parties, leaving everyone

Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

2020-09-21 Thread Karl via bitcoin-dev
Coinswap has been a struggling goal for many years now. Consider that bitshares' dexbot just recently lost their funding. Please make your projects usable before you announce you are working on them, to keep your work safe from distraction or harm. On Sun, Sep 13, 2020, 7:11 PM Tom Trevethan

Re: [bitcoin-dev] hashcash-newhash

2020-05-25 Thread Karl via bitcoin-dev
Hi ZmnSCPxj, We have been addressing many concepts. Let's try to slowly trim it down for simplicity. > Reddit claims two entities controlled 62% of the hashrate recently: > https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/ > . Compromising the

Re: [bitcoin-dev] hashcash-newhash

2020-05-25 Thread Karl via bitcoin-dev
asy to find an sha256 preimage on a personal device, somehow. Let's improve the security of the blockchain. On Sun, May 24, 2020, 7:51 PM Ariel Lorenzo-Luaces wrote: > On May 24, 2020, at 1:26 PM, Karl via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>

Re: [bitcoin-dev] hashcash-newhash

2020-05-24 Thread Karl via bitcoin-dev
Hi ZmnSCPxj, Thanks for your reply. I'm on mobile so please excuse me for top-posting. I'd like to sort these various points out. Maybe we won't finish the whole discussion, but maybe at least we can update wiki articles like https://en.bitcoin.it/wiki/Hashcash#Cryptanalytic_Risks with more

Re: [bitcoin-dev] hashcash-newhash

2020-05-24 Thread Karl via bitcoin-dev
Good afternoon ZmnSCPxj, Thanks for holding your end of this discussion with me. Sorry I am so verbose; I am still learning to communicate efficiently. > You mention ASICs becoming commoditized. I'd remind you that eventually > there will be a public mathematical breaking of the algorithm, at

[bitcoin-dev] hashcash-newhash

2020-05-23 Thread Karl via bitcoin-dev
Hi, I'd like to revisit the discussion of the digest algorithm used in hashcash. I believe migrating to new hashing algorithms as a policy would significantly increase decentralization and hence security. I believe the impact on existing miners could be made pleasant by gradually moving the