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 17:47:06

- reply

📅 Original date posted:2015-12-25
📝 Original message:On 20.12.2015 18:00, Emin Gün Sirer via bitcoin-dev wrote:
> Instead, we will have the bigger
> pools become more suspicious of signing up new hash power, which is a
> good thing.
Block withholding attacks do not differentiate between small and large
pools. When Eligius and BTCGuild got hit with this, they were far from
the biggest pools at the time.
When my pool, Bitminter, got a new large miner who found 1 block where
average luck would have had them find 3, one of the other miners claimed
they must be withholding blocks. Even if there is no logic or evidence
behind it, after one person cries wolf the others get nervous. This way
even the possibility of block withholding can keep smaller pools from
growing. It takes more hashpower to put a dent in a bigger pool, so you
will see less such panic.
> And we will have small groups of people who have some reason
> for trusting each other (e.g. they know each other from IRC, conferences,
> etc) band together into small pools. These are fantastic outcomes for
> decentralization.
Three guys with 1 TH/s, 2 TH/s and 100 GH/s meet at a conference and
decide to start a private pool? Obviously that doesn't work. Maybe three
people with huge warehouses of miners would work together if they knew
and trusted each other.
Those small miners need to mine with people they don't know to get an
acceptable variance.
If you kill off mining pools then small miners have no way to achieve
acceptable variance and they will disappear. There will only be big
warehouse miners left, the ones who are big enough to solo mine.
That's not helping decentralization.
> Right, it's not clear at all that yelling at people has much effect. As much
> fun as I had going to that meeting with GHash in London to ask them to
> back down off of the 51% boundary, I am pretty sure that yelling at large
> open pools will not scale. We needed better mechanisms for keeping pools
> in check.
I agree. It's very disappointing how most miners and pools handle this
(BTCGuild being the exception). But I do not think block withholding is
a good tool. It can easily destroy small pools, but it won't put a dent
in a pool that goes over 50%.
Block withholding is a tool big pools can use to put smaller competitors
out of business.
And even if it was effective I would not use block withholding to attack
other pools.
> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
> time when we should count our blessings, not work actively to render
> them inoperable.
Is it? Is there any example of block withholding leading to more
decentralized mining?
If I remember right, GHash being too big ended with BitFury moving some
of their hashpower out of the pool. I don't know where that hashpower
went and whether the problem was solved or merely hidden.
GHash profitability being very low for some time wasn't due to block
withholding, it was a bug that some miners abused to get paid for the
same work multiple times. This made it look like a lot of work was done
while finding few blocks.
> Basically you have the pool pick a secret k for each share, and commit
> to H(k) in the share. Additionally the share commits to a target divider
> D. The PoW validity rule is then changed from H(block header) < T, to be
> H(block header) < T * D && H(H(block header) + k) < max_int / D
>
>
> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>
> Once again, this suggestion would make the GHash-at-51% situation
> possible again. Working extra hard to re-enable those painful days
> sounds like a terrible idea.
Block withholding didn't solve the problem back then. And guess what,
those painful days are here right now. China is at 65% and block
withholding isn't solving it.
I was disappointed when GHash got too big and refused to do anything. It
was sad when their miners didn't do anything. Then they used
double-spends to scam a casino. I was shocked that noone cared. Now two
thirds of the bitcoin hashpower is within the control of a single
government. This time I expected noone would care - but I'm still
disappointed. I'm also surprised at the irrational behavior; there are
so many who go out of their way to put their own investments in danger.
For a long time now many miners and pools have been irresponsible with
the hashpower. But block withholding just makes it worse.
Regards,
Geir H. Hansen, Bitminter mining pool

2023-06-07 17: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 17: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 15:46:43

- reply

2023-06-07 15: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 15: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 15: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 10:27:57

- reply

📅 Original date posted:2012-08-12
📝 Original message:On 11.08.2012 20:56, Wladimir wrote:
> Duplicate strings are not a problem. Some strings are used multiple
> times in the program, and thus appear multiple times in the translation.
> This is because there are cases in which a string that is the same in
> English is translated differently in another language based on the context.
That makes sense. But it's hard to translate when you just see the same
string twice and don't know the context where it will be used.
> At least Qt translator fills duplicates in automatically, with the
> option to change them if desired. I'm not sure about Transifex but I've
> heard it's the same there.
No, I just use copy and paste.
> Use UPnP to map the listening port (default: 0)
> Use UPnP to map the listening port (default: 1 when listening)
>
> The default depends on compiler flags, hence the two messages. I suppose
> the message could be split up, so that "Use UPnP to map the listening
> port" is factored out.
Sorry, forgot there was a compiler flag for this. No need to split this
up. As long as there is no explanation or description for each string I
think it's easier to translate whole sentences.
On 11.08.2012 20:32, Wladimir wrote:
> By the way, by far the most common support request I have at my pool is
>
> users withdrawing coins and not seeing it in their wallet because it's
> not up-to-date with the block chain. Might be worth adding
something in
> the bitcoin-qt GUI to make it more obvious that users can't see new
> transactions and why.
>
> For 0.7 we've added a red "(out of sync)" warning to the balances when
> the block chain is out of date.
Perfect. This will prevent a lot of confusion. Thanks!
Regards,
Geir H. Hansen, bitminter.com

2023-06-07 10:27:44

- reply

📅 Original date posted:2012-08-11
📝 Original message:On 02.08.2012 18:43, Jeff Garzik wrote:
> There seems to be consensus that we should go ahead and do a release,
> before leveldb or ultraprune or anything major lands. There is no
> major landmark feature, but just a useful collection of small changes.
> It seems like a good time to Release Early, Release Often and make a
> checkpoint release.
Looks like much goodness in this version. Thanks for all this work.
Any chance that options to limit the size of blocks and prioritize paid
vs free txes could make it in?
By the way, by far the most common support request I have at my pool is
users withdrawing coins and not seeing it in their wallet because it's
not up-to-date with the block chain. Might be worth adding something in
the bitcoin-qt GUI to make it more obvious that users can't see new
transactions and why.
> 2) Translations update 2012-08-01 (fetched from Transifex)
I just now updated the Norwegian translation on Transifex, if you'd like
to do another pull before the release. For some reason there were many
strings I had already translated that now had no translation and had to
be done again (even ones that had the same English text). Many languages
are now only about 50% translated.
Also there were new duplicated strings:
"Verify a message to ensure it was signed with a specified Bitcoin address"
"Sign a message to prove you own a Bitcoin address"
"Clear &All"
These two seem odd:
Use UPnP to map the listening port (default: 0)
Use UPnP to map the listening port (default: 1 when listening)
Regards,
Geir H. Hansen, bitminter.com

2023-06-07 03:12:12

- reply

📅 Original date posted:2012-03-04
📝 Original message:On 04.03.2012 02:04, Luke-Jr wrote:
> On Saturday, March 03, 2012 6:51:34 PM Geir Harald Hansen wrote:
>> Long polling as currently implemented in pools has a race condition.
>> Does the miner reconnect first or does another block change happen
>> first? "Double" block changes are common with merged mining and I'm
>> doing all sorts of tricks in my pool backend to reduce this problem.
>
> How would you suggest addressing this? I presume if a share solves blocks on
> multiple chains, you just longpoll once when that's successful?
If the client doesn't tell you which block change it saw last, you can't
avoid this problem completely.
>> How about another entry "longpollid" in long poll responses. The last
>> seen longpollid should be included by the client in future long poll
>> requests. This enables the server to see if the client has missed any
>> block changes. The ID could perhaps be submitted in an HTTP header
>> (X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params
>> could hold an object with a key "longpollid". Could be a string or
>> number, like "workid".
>
> Hmm, the problem is that adding any parameters to getmemorypool itself breaks
> compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific
> again. Any ideas?
I think long polling and reconnecting to LP is an HTTP-specific problem
anyway? So it may be best to go with an HTTP header. See below for an
idea for a capabilities reporting system, though, which would allow
putting this data into JSON.
>> Another useful value in the getmemorypool response would be "height", so
>> the miner can include the correct height in the coinbase. I would like
>> that in bitcoind as well. One JSON-RPC call instead of two, and no race
>> condition between getmemorypool and getblocknumber.
>
> Good catch. Should this be required (since it might be necessary for future
> Bitcoin blocks), or just "should" for compatibility?
I think "should" makes sense.
>> It should be explained how target vs. fulltarget works.
>
> What is unclear about this?
Reading through it again it is mostly clear except for one thing, how to
submit "share/merkle" style. It doesn't say exactly how to submit this data.
It says merkle tree, but a merkle branch should suffice. Also, I believe
the coinbase must always be the first transaction of a block? So we
won't need the transaction's index in the merkle tree (it's always index
zero). This would then be just an array of sha256 hashes making up the
merkle branch for the coinbase.
I'd prefer if block header, coinbase tx and merkle branch were submitted
in 3 pieces. When merged mining and submitting a block generating proof
to the aux backend you put an auxiliary proof of work between the block
header and transactions. So the header and transactions are not
necessarily adjacent. Also, there's no merkle branch in a regular
bitcoin block.
>> Perhaps some things should be optional for a client to implement?
>
> Doing this safely needs some way for clients to communicate capabilities to
> the server, which has the problem of passing parameters to getmemorypool.
Let's add an optional "servercapabilities" key on the server side, the
value being a space-delimited list of what's supported by the server. If
that list contains "clientcapabilities" then the client may, instead of
sending an empty request, send an object where one of the keys is
"clientcapabilities", and the value is a space-delimited list of extensions.
Those names are a bit long, maybe "caps" is better.
Ok, this is not entirely clean. For the first request the client won't
know what the server supports. For subsequent requests I guess always
assume the last caps the server reported.
>> I think "noncerange" is of limited use and there's a good chance of getting
>> the endianness wrong.
>
> There is no mining hardware to date that exhausts even half the nonce space,
> so I'd really prefer to see this as a required feature on the miner side. On
> the other hand, it's merely an extension for getwork, so I can see the problem
> so long as we're using getwork proxies.
Yes, you can end up getting half a nonce range from an upstream server,
and not being able to make use of it because your downstream clients
don't support it.
A single GPU can make full use of the noncerange if you allow the
timestamp to slip a few seconds into the past. I believe most miners do
that today.
Also worth including are the "hostlist" and "switchto" getwork
extensions. I think those can fit right into the JSON response, to keep
with being transport-agnostic, but otherwise look like they do for getwork.
Regards,
Geir H. Hansen

2023-06-07 03:12:06

- reply

📅 Original date posted:2012-03-03
📝 Original message:On 28.02.2012 23:06, Luke-Jr wrote:
> Please review and comment/critique:
> https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool
Looking forward to implementing this in my pool backend and miner.
A few comments:
"transactions add or remove transactions (both of the above; default if
"transactions" omitted) "
In the above, you may want to specify that the "transactions" referred
to here is the one in the first table (JSON-RPC response object) and not
the mutations. For a moment I thought free tx editing was the default.
Long polling as currently implemented in pools has a race condition.
Does the miner reconnect first or does another block change happen
first? "Double" block changes are common with merged mining and I'm
doing all sorts of tricks in my pool backend to reduce this problem.
How about another entry "longpollid" in long poll responses. The last
seen longpollid should be included by the client in future long poll
requests. This enables the server to see if the client has missed any
block changes. The ID could perhaps be submitted in an HTTP header
(X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params
could hold an object with a key "longpollid". Could be a string or
number, like "workid".
Another useful value in the getmemorypool response would be "height", so
the miner can include the correct height in the coinbase. I would like
that in bitcoind as well. One JSON-RPC call instead of two, and no race
condition between getmemorypool and getblocknumber.
It should be explained how target vs. fulltarget works.
Perhaps some things should be optional for a client to implement? I
think "noncerange" is of limited use and there's a good chance of
getting the endianness wrong.
Regards,
Geir Harald Hansen

2023-06-07 02:33:15

- reply

📅 Original date posted:2011-10-24
🗒️ Summary of this message: The text provides examples of duplicated strings in Bitcoin's wallet software, which could be improved by distinguishing strings based on context.
📝 Original message:Three quick examples of duplicated strings. There are many more. Some of
the smaller ones may make sense to have duplicated several times in
english as their translated versions may differ in other languages. But
with these below I don't see the point.
Twice, with a small difference (<b> vs. none):
WARNING: If you encrypt your wallet and lose your passphrase, you will
<b>LOSE ALL OF YOUR BITCOINS</b>! Are you sure you wish to encrypt your
wallet?
WARNING: If you encrypt your wallet and lose your passphrase, you will
LOSE ALL OF YOUR BITCOINS! Are you sure you wish to encrypt your wallet?
Again twice, with a small difference (%s vs %1):
This transaction is over the size limit. You can still send it for a fee
of %1, which goes to the nodes that process your transaction and helps
to support the network. Do you want to pay the fee?
This transaction is over the size limit. You can still send it for a fee
of %s, which goes to the nodes that process your transaction and helps
to support the network. Do you want to pay the fee?
Twice, looks exactly the same:
Generated coins must wait 120 blocks before they can be spent. When you
generated this block, it was broadcast to the network to be added to the
block chain. If it fails to get into the chain, it will change to "not
accepted" and not be spendable. This may occasionally happen if another
node generates a block within a few seconds of yours.
Generated coins must wait 120 blocks before they can be spent. When you
generated this block, it was broadcast to the network to be added to the
block chain. If it fails to get into the chain, it will change to "not
accepted" and not be spendable. This may occasionally happen if another
node generates a block within a few seconds of yours.
Regards,
Geir Harald Hansen
On 24.10.2011 20:10, John Smith wrote:
>
> Indeed. It could make sense. That's the reason why Qt distinguishes
> strings based on context as well as content.
>
> But it could also be nonsense. Can you be more specific as to which strings?
>
> JS
>
> On Mon, Oct 24, 2011 at 1:24 PM, Christian Decker
> <decker.christian at gmail.com <mailto:decker.christian at gmail.com>> wrote:
>
> Actually no, the same string may have to be translated in different
> ways depending on the context they appear in. That sometimes happens
> for italian, and I'm sure it happens in other cases too. Not sure
> whether this is the cause for duplicate strings for now, but it might.
>
> Regards,
> Chris
>
>
> On Sat, Oct 22, 2011 at 6:14 PM, Geir Harald Hansen
> <operator at bitminter.com <mailto:operator at bitminter.com>> wrote:
>
> What do you know, it worked. Finished.
>
> Once again Norway finishes ahead of Sweden. :P
>
> By the way, I had to translate some of the exact same strings
> 2-3 times.
> That's something you may want to improve on.
>
> On 22.10.2011 15:28, Nils Schneider wrote:
> > I think it's possible to add it yourself. Just click on "add
> translation"
> >
> > On 22.10.2011 14:26, Geir Harald Hansen wrote:
> >> 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

2023-06-07 02:33:06

- reply

📅 Original date posted:2011-10-22
🗒️ Summary of this message: Norway finished ahead of Sweden in a translation project. Some strings had to be translated multiple times, which could be improved.
📝 Original message:What do you know, it worked. Finished.
Once again Norway finishes ahead of Sweden. :P
By the way, I had to translate some of the exact same strings 2-3 times.
That's something you may want to improve on.
On 22.10.2011 15:28, Nils Schneider wrote:
> I think it's possible to add it yourself. Just click on "add translation"
>
> On 22.10.2011 14:26, Geir Harald Hansen wrote:
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning at Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning at Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 02: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