Geir Harald Hansen [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-10-22 to 2015-12-27
💬 Posted a total of 13 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 19:46:57

- reply

📅 Original date posted:2015-12-27
📝 Original message:Last I heard it was believed the miner had made their own mining client
and that the block withholding was a bug, not an intended feature.
On 26.12.2015 09:12, Multipool Admin via bitcoin-dev wrote:
> Any attempt to 'fix' this problem, would most likely require changes to
> all mining software, why not just make mining more decentralized in general?
>
> For example, allow anyone to submit proofs of work to Bitcoind that are
> some fraction of the network difficulty and receive payment for them if
> they're valid. This would also encourage the proliferation of full
> nodes since anyone could solo mine again. Then, the next coinbase
> transaction could be split among, say, the top 100 proofs of work.
>
> Eligius already does their miner payouts like this.
>
> If you want to fix an issue with mining, fix the selfish mining issue
> first as it's a much larger and more dangerous potential issue.
>
> I don't believe it was ever clearly established whether Eligius suffered
> a block withholding attack or was just the victim of a miner with (what
> was, at the time) a large amount of faulty hardware, however, from the
> Bitcointalk threads at the time I believe it was assumed to be the latter.
>
> --Adam
>
>
> On Sat, Dec 19, 2015 at 8:44 PM, Peter Todd via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via
> bitcoin-dev wrote:
> > Then shouldn't this be something the pool deals with, not the bitcoin protocol?
>
> There is no known way for pools - especially ones that allow anonymous
> hashers - to effectively prevent block withholding attacks without
> changing the Bitcoin protocol.
>
> --
> 'peter'[:-1]@petertodd.org <http://petertodd.org>
> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:34:48

- reply

📅 Original date posted:2015-08-13
📝 Original message:3) A few more people begin using bitcoin. Bitcoin buckles and dies.
- Something happens a few months from now causing an influx of new users
and more transactions.
- Blocks are constantly full.
- A backlog of transactions keeps growing indefinitely.
- At first people say "bitcoin is slow". After a while they say "bitcoin
doesn't work".
- Changing the hard limit on block size requires a fork and takes too long.
- As bitcoin no longer works people stop using it.
- Bitcoin lives out the last of its days in the backwaters of the
internet with only 5 users. They keep telling people "we increased the
block size now". Unfortunately noone is listening anymore.
- People laugh at you and say "I told you that buttcoin thing was doomed
to fail. After all it wasn't real money."
If the hard limit had been increased earlier then mining pools would
have been able to react quickly by upping their own soft limit. But this
was not the case and so ended Bitcoin.
So in summary:
By increasing the block size limit you run the risk of:
- The transaction fee market takes a little longer to develop.
By not increasing the limit you run the risk of:
- Bitcoin dies. The end.
Transaction fees should not be the main topic of this discussion, and
probably not even a part of it at all. That seems outright irresponsible
to me.
Regards,
Geir H. Hansen, Bitminter mining pool
On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:
> I believe all concerns I've read can be classified in the following groups:
>
>> 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will become
> more unreliable.
> - People will migrate to competing systems (PoW altcoins) with lower fees.
>
>> 2) Software problem independent of a concrete block size that needs to
>> be solved anyway, often specific to Bitcoin Core (ie other
>> implementations, say libbitcoin may not necessarily share these
>> problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the program
> crash by using too much memory.
> - There's no good way to increase the fee of a transaction that is
> taking too long to be mined without the "double spending" transaction
> with the higher fee being blocked by most nodes which follow Bitcoin
> Core's default policy for conflicting spends replacements (aka "first
> seen" replacement policy).
>
> I have started with the 3 concerns that I read more often, but please
> suggest more concerns for these categories and suggest other
> categories if you think there's more.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:46:43

- reply

2023-06-07 17:41:41

- reply

📅 Original date posted:2015-07-04
📝 Original message:How do I get Bitminter on the list of approved pools at
https://bitcoin.org/en/alert/2015-07-04-spv-mining ?
Regards,
Geir H. Hansen, Bitminter

2023-06-07 17:26:23

- reply

📅 Original date posted:2014-10-12
📝 Original message:On 12.10.2014 01:34, Pieter Wuille wrote:
> * No orphan blocks stored in memory anymore (reducing memory usage during sync).
Will this slow down reorgs after a fork, compared to today?
Regards,
Geir H. Hansen, Bitminter

2023-06-07 17:26:23

- reply

📅 Original date posted:2014-10-12
📝 Original message:On 12.10.2014 11:52, Wladimir wrote:
> On Sun, Oct 12, 2014 at 10:41 AM, Geir Harald Hansen
> <operator at bitminter.com> wrote:
>> On 12.10.2014 01:34, Pieter Wuille wrote:
>>> * No orphan blocks stored in memory anymore (reducing memory usage during sync).
>>
>> Will this slow down reorgs after a fork, compared to today?
>
> Why would you think so? Orphan blocks are blocks whose parent is not
> known. In the case of a reorganization the client 'jumps' to a new
> best chain, for this to happen the original tip and the new best tip
> and all their parents must be already known.
I was thinking of shorter sides of forks as being orphaned. Sorry for
the confusion.
Regards,
Geir H. Hansen, Bitminter

2023-06-07 04:32:59

- reply

📅 Original date posted:2011-10-22
🗒️ Summary of this message: Bitcoin translation coordination requested. Transifex tool suggested for easy translation submission. Norwegian Bokmål translation requested.
📝 Original message:On 22.10.2011 12:51, Nils Schneider wrote:
>> And is anybody willing to take the job of coordinating translation
>> efforts, figuring out if Transifex is a good tool to use, and writing
>> some documentation to make it easy for people to create and submit new
>> translations?
>
> I have exported all .ts to transifex.
>
> https://www.transifex.net/projects/p/bitcoin/resource/tx/
If you add Norwegian Bokmål, I can do that one. Language code "nb".
Regards,
Geir Harald Hansen