<unnamed>

Public Key

npub1u3hslvx87efh4ee4n8w32ytmx9c0jq7mt9ykjpk35nqcglyte4dsa3p337

Profile Code

nprofile1qqswgmc0krrlv5m6uu6enhg4z9anzu8eq0d4jjtfqmg6fsvy0j9u6kcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds3k37ym

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:59:37 UTC

- reply

📅 Original date posted:2017-04-07
📝 Original message:Hi Tomas,
I've read it and think it is an excellent work, I'd like to see it
integrated into bitcoin-core as a 'kernel module'.
I see there are a lot of proof of concepts out there, IMO every one
deserve a room in the bitcoin client as a selectable feature, to make the
software more flexible and less dictatorial, an user could easily select
which features she wants to run.
Best regards,
Marcos
> I have been working on a bitcoin implementation that uses a different
> approach to indexing for verifying the order of transactions. Instead of
> using an index of unspent outputs, double spends are verified by using a
> spend-tree where spends are scanned against spent outputs instead of
> unspent outputs.
>
> This allows for much better concurrency, as not only blocks, but also
> individual inputs can be verified fully in parallel.
>
> I explain the approach at https://bitcrust.org, source code is available
> at https://github.com/tomasvdw/bitcrust
>
> I am sharing this not only to ask for your feedback, but also to call
> for a clear separation of protocol and implementations: As this
> solution, reversing the costs of outputs and inputs, seems to have
> excellent performance characteristics (as shown in the test results),
> updates to the protocol addressing the UTXO growth, might not be worth
> considering *protocol improvements* and it might be best to address
> these concerns as implementation details.
>
> Kind regards,
> Tomas van der Wansem
> tomas at bitcrust.org
> Bitcrust
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:57:25 UTC

- reply

📅 Original date posted:2017-03-20
📝 Original message:Hi,
Just a thought,
Bitcoin developers shouldn't care about miners business model, they can
always sell their hw and close the bz as soon as bitcoin hardforks to
better ways of doing.
Just focus on making a better cryptocurrency, the more decentralized the
best.
M
> By doing this you're significantly changing the economic incentives behind
> bitcoin mining. How can you reliably invest in hardware if you have no
> idea
> when or if your profitability is going to be cut by 50-75% based on a
> whim?
>
> You may also inadvertently create an entirely new attack vector if 50-75%
> of the SHA256 hardware is taken offline and purchased by an entity who
> intends to do harm to the network.
>
> Bitcoin only works if most miners are honest, this has been known since
> the
> beginning.
>
> On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Iâ€™m very worried about the state of miner centralisation in Bitcoin.
>>
>> I always felt the centralising effects of ASIC manufacturing would
>> resolve
>> themselves once the first mover advantage had been exhausted and the
>> industry had the opportunity to mature.
>>
>> I had always assumed initial centralisation would be harmless since
>> miners
>> have no incentive to harm the network. This does not consider the risk
>> of a
>> single entity with sufficient power and either poor, malicious or
>> coerced
>> decision making. I now believe that such centralisation poses a huge
>> risk
>> to the security of Bitcoin and preemptive action needs to be taken to
>> protect the network from malicious actions by any party able to exert
>> influence over a substantial portion of SHA256 hardware.
>>
>> Inspired by UASF, I believe we should implement a Malicious miner
>> Reactive
>> Proof of Work Additions (MR POWA).
>>
>> This would be a hard fork activated in response to a malicious attempt
>> by
>> a hashpower majority to introduce a contentious hard fork.
>>
>> The activation would occur once a fork was detected violating protocol
>> (likely oversize blocks) with a majority of hashpower. The threshold and
>> duration for activation would need to be carefully considered.
>>
>> I donâ€™t think we should eliminate SHA256 as a hashing method and
>> change
>> POW entirely. That would be throwing the baby out with the bathwater and
>> hurt the non-malicious miners who have invested in hardware, making it
>> harder to gain their support.
>>
>> Instead I believe we should introduce multiple new proofs of work that
>> are
>> already established and proven within existing altcoin implementations.
>> As
>> an example we could add Scrypt, Ethash and Equihash. Much of the code
>> and
>> mining infrastructure already exists. Diversification of hardware (a mix
>> of
>> CPU and memory intensive methods) would also be positive for
>> decentralisation. Initial difficulty could simply be an estimated
>> portion
>> of existing infrastructure.
>>
>> This example would mean 4 proofs of work with 40 minute block target
>> difficulty for each. There could also be a rule that two different
>> proofs
>> of work must find a block before a method can start hashing again. This
>> means there would only be 50% of hardware hashing at a time, and a
>> sudden
>> gain or drop in hashpower from a particular method does not dramatically
>> impact the functioning of the network between difficulty adjustments.
>> This
>> also adds protection from attacks by the malicious SHA256 hashpower
>> which
>> could even be required to wait until all other methods have found a
>> block
>> before being allowed to hash again.
>>
>> 50% hashing time would mean that the cost of electricity in relation to
>> hardware would fall by 50%, reducing some of the centralising impact of
>> subsidised or inexpensive electricity in some regions over others.
>>
>> Such a hard fork could also, counter-intuitively, introduce a block size
>> increase since while weâ€™re hard forking it makes sense to minimise the
>> number of future hard forks where possible. It could also activate
>> SegWit
>> if it hasnâ€™t already.
>>
>> The beauty of this method is that it creates a huge risk to any
>> malicious
>> actor trying to abuse their position. Ideally, MR POWA would just serve
>> as
>> a deterrent and never activate.
>>
>> If consensus were to form around a hard fork in the future nodes would
>> be
>> able to upgrade and MR POWA, while automatically activating on
>> non-upgraded
>> nodes, would be of no economic significance: a vestigial chain
>> immediately
>> abandoned with no miner incentive.
>>
>> I think this would be a great way to help prevent malicious use of
>> hashpower to harm the network. This is the beauty of Bitcoin: for any
>> road
>> block that emerges the economic majority can always find a way around.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
> Andrew Johnson
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>