What is your take on Bitcoin Knotz? Bitcoin node and wallet by Luke Dashjr

[Accardo]

Laughable to believe that they don't want a hard fork because "most of them are serious maxis". NO - they won't hard fork because the users, the economic majority, and the miners will follow the Core Developers and leave the filter boys with a shitcoin in their hands.

This drama/debate will not last long from now because soon the users will truly understand the issue, AND will truly understand that filtering is not only useless, it hurts network efficiency as well.

This tribe thing won't cause a hardfork, the knot guys want to clarify everyone that Core is not the government of Bitcoin, by providing other routes to Bitcoin. This filter argument only validates that some people who don't want the filter can be with the core and those who wish for filter can go with the knot developers. Yesterday, on podcast, Adamback said filters won't or hardly will work, and the knot guy on same video said it doesn't work sometimes.

Hence, the both sides need to understand ways to implement it to work to some extent. Spam has never been a threat to Bitcoin, but image spam is something to consider how risky it'll become to node operators. The core developers taking out the OP-RETURN limit brought in this fear mongering, nobody wants to go to court for having CSAM on their node. Such people will go with Knot temporary, till the whole drama dies down.

[Wind_FURY]

Laughable to believe that they don't want a hard fork because "most of them are serious maxis". NO - they won't hard fork because the users, the economic majority, and the miners will follow the Core Developers and leave the filter boys with a shitcoin in their hands.

This drama/debate will not last long from now because soon the users will truly understand the issue, AND will truly understand that filtering is not only useless, it hurts network efficiency as well.

This tribe thing won't cause a hardfork, the knot guys want to clarify everyone that Core is not the government of Bitcoin, by providing other routes to Bitcoin. This filter argument only validates that some people who don't want the filter can be with the core and those who wish for filter can go with the knot developers.

No one says that Core is the "government of Bitcoin". None of the Core Developers want to take control and be the "leader" of the community. Although, there should be a leader to guide development and tell the community "this is where we're going", no? But that's a different debate.

Yesterday, on podcast, Adamback said filters won't or hardly will work, and the knot guy on same video said it doesn't work sometimes.

It doesn't work because it doesn't actually stop it, AND dick pic and fart sound lovers could merely go to the miners and pay them to include it in their blocks.

Hence, the both sides need to understand ways to implement it to work to some extent. Spam has never been a threat to Bitcoin, but image spam is something to consider how risky it'll become to node operators. The core developers taking out the OP-RETURN limit brought in this fear mongering, nobody wants to go to court for having CSAM on their node. Such people will go with Knot temporary, till the whole drama dies down.

If they're scared of Ordinals, which the data are prunable, THEN they should be scared of BitcoinStamps, which embeds the data in the UTXO set where it's PERMANENT.

[Satofan44]

Laughable to believe that they don't want a hard fork because "most of them are serious maxis". NO - they won't hard fork because the users, the economic majority, and the miners will follow the Core Developers and leave the filter boys with a shitcoin in their hands.

No, it is not. There is no need to exaggerate. A real maxi understands that a contentious hard fork is detrimental to Bitcoin and should be reserved for the extremest emergencies, which this is not. It has nothing to do with economic value. Why would they care about that? They will have coins on both chains with a fork.

This drama/debate will not last long from now because soon the users will truly understand the issue, AND will truly understand that filtering is not only useless, it hurts network efficiency as well.

I've already explained to you somewhere else that we have all kinds of filters, therefore filtering is not useless. Stop repeating nonsense and start learning. Even the block size limit itself is a filter. Should we remove it completely since it is useless? 

No one says that Core is the "government of Bitcoin". None of the Core Developers want to take control and be the "leader" of the community. Although, there should be a leader to guide development and tell the community "this is where we're going", no? But that's a different debate.

If you act like the de-facto government, pretending that you are not the government doesn't change anything.

This tribe thing won't cause a hardfork, the knot guys want to clarify everyone that Core is not the government of Bitcoin, by providing other routes to Bitcoin. This filter argument only validates that some people who don't want the filter can be with the core and those who wish for filter can go with the knot developers. Yesterday, on podcast, Adamback said filters won't or hardly will work, and the knot guy on same video said it doesn't work sometimes.

The situation that we are in is not good. Putting aside any issues directly relating to luke-jr, knots is obviously not the solution. Still the situation is useful to highlight the problem that we are in. There is a power imbalance between the 3 main groups in Bitcoin: miners, nodes and developers. How to restore it again to a better state is the difficult question. I don't have a good answer for that. 

[gmaxwell]

Even the block size limit itself is a filter. Should we remove it completely since it is useless?  

Woah there. Way to much term drift. Policy and Consensus rules are very very different.

Filters as a consensus rule would be another kettle of fish.  They'd actually be effective, but the filterbois don't push for them because they still wouldn't _work_ because the traffic they're concerned with doesn't care how its encoded and can just change.

I think a contentious hardfork can be good -- disruptive in the short term, but even that can help by bringing attention back to bitcoin in cryptocurrency businesses that spend most of their energy on constant trashfire shitcoins... and in the long term it can be very good by further clarifying the principles of Bitcoin and helping to give otherwise disruptive elements of the community an outlet to enact their own vision.  They say their filtering shit will work, accomplish something useful, and not turn into a fully censored hell hole? Oh really? Feel free to show us all.

[jstefanop]

Even the block size limit itself is a filter. Should we remove it completely since it is useless?  

Woah there. Way to much term drift. Policy and Consensus rules are very very different.

Filters as a consensus rule would be another kettle of fish.  They'd actually be effective, but the filterbois don't push for them because they still wouldn't _work_ because the traffic they're concerned with doesn't care how its encoded and can just change.

I think a contentious hardfork can be good -- disruptive in the short term, but even that can help by bringing attention back to bitcoin in cryptocurrency businesses that spend most of their energy on constant trashfire shitcoins... and in the long term it can be very good by further clarifying the principles of Bitcoin and helping to give otherwise disruptive elements of the community an outlet to enact their own vision.  They say their filtering shit will work, accomplish something useful, and not turn into a fully censored hell hole? Oh really? Feel free to show us all.

Ive already said this on X, only real solution if both sides truly want to **LIMIT** spam is a soft fork eliminating the witness discount, and adding a fee mutiplier to ALL data (excess witness + OP_RETURN).

Wont censor, will reduce spam, and those that still want to use large data will pay their fair share of fees for it vs standard txs.

[joker_josue]

Ive already said this on X, only real solution if both sides truly want to **LIMIT** spam is a soft fork eliminating the witness discount, and adding a fee mutiplier to ALL data (excess witness + OP_RETURN).

Wont censor, will reduce spam, and those that still want to use large data will pay their fair share of fees for it vs standard txs.

In other words, an extra fee for those who use data beyond financial transactions?
It doesn't seem like a bad idea to me, and it's fair for everyone, since everyone pays for what they use on the network.

Now, is this actually being discussed and is there interest in implementing it?

[ABCbits]

--snip--

Ive already said this on X, only real solution if both sides truly want to **LIMIT** spam is a soft fork eliminating the witness discount, and adding a fee mutiplier to ALL data (excess witness + OP_RETURN).

Wont censor, will reduce spam, and those that still want to use large data will pay their fair share of fees for it vs standard txs.

It's bold suggestion. But it'll also reduce total Bitcoin TPS, since there would be less TX fit in a block. Personally i would rather make OP_FALSE OP_IF ... OP_ENDIF non-standard (or even invalid), since no monetary/financial TX would use such script.

[stwenhao]

Personally i would rather make OP_FALSE OP_IF ... OP_ENDIF non-standard (or even invalid)

Non-standard wouldn't matter, because users can simply not upgrade, and still use it, because it is standard in the current version.

Making it invalid will start cat-and-mouse games, where people would switch to "OP_TRUE OP_NOTIF ... OP_ENDIF", and other similar things instead.

[Satofan44]

Even the block size limit itself is a filter. Should we remove it completely since it is useless?  

Woah there. Way to much term drift. Policy and Consensus rules are very very different.

They are different, but that doesn't mean that it is not a filter. The user has stated that filtering is useless by which it is meant all filtering, which is categorically incorrect as there are various types of useful filters involved in the network. I merely picked the best filter that we have as an example, which happens to be also a consensus rule.  

Filters as a consensus rule would be another kettle of fish.  They'd actually be effective, but the filterbois don't push for them because they still wouldn't _work_ because the traffic they're concerned with doesn't care how its encoded and can just change.

How would they be effective if they wouldn't work for the intended traffic?

They say their filtering shit will work, accomplish something useful, and not turn into a fully censored hell hole? Oh really? Feel free to show us all.

This is the kind of king-like stance that I talked about previously and which should not be fostered by Core though. You're supposed to listen even when you don't like what you are hearing, that helps preserve the balance.

Ive already said this on X, only real solution if both sides truly want to **LIMIT** spam is a soft fork eliminating the witness discount, and adding a fee mutiplier to ALL data (excess witness + OP_RETURN).

Wont censor, will reduce spam, and those that still want to use large data will pay their fair share of fees for it vs standard txs.

Doesn't this excessively punish large transactions like UTXO consolidation?

[d5000]

Ive already said this on X, only real solution if both sides truly want to **LIMIT** spam is a soft fork eliminating the witness discount, and adding a fee mutiplier to ALL data (excess witness + OP_RETURN).

Another one who totally ignores the "fake public keys" problem *yawn*.

I hate to repeat it so many times, but look into https://stampchain.io/explorer. There are 1.2+ million NFTs stuffed into fake public keys (only with that single protocol, and there are more ...) and which in addition reside permanently in the UTXO set, making operation more costly for the nodes than if they used OP_RETURN.

Your measure would not catch any of these NFTs, because while there are some fake public keys who can be detected as fake, about half of them don't. This would mean that if you wanted to check them for "correctness", the NFT spammers could run that check too before they submit their transaction, and they would have to discard only half of the keys they're using, which would not mean even a significant computation effort.

I have myself thought about a rather similar measure some years ago: to create a very simple "payment" transaction type with a discount only applied to these transactions, which could only be used with a script similar to P2WPKH, i.e. "only" for the most simple kinds of payments to a public key hash / address (excluding multisig, P2PK, Taproot etc.). This measure would create a bit of overhead for the "fake public key" spammers if they wanted to use the cheapest option, because they couldn't use the most effective scripts like P2MS (where you can stuff data into multiple keys one after another instead of having to use an output for every key). But at the end the spammers would probably pay the same fees if they still use the "fake public key" or "fake address" method with this new transaction type.

How would they be effective if they wouldn't work for the intended traffic?

They would be "effective" in the sense of blocking the exact type of traffic like Taproot envelopes but not in the goal of eliminating spam because they would simply use different scripts, like fake public keys.

This is the kind of king-like stance that I talked about previously and which should not be fostered by Core though

AFAIK @gmaxwell isn't a Core developer anymore (at least he's no longer active at Github). He participates in discussions like you and me, but I think he's a little bit of a better understanding of Bitcoin's inner workings

[Satofan44]

How would they be effective if they wouldn't work for the intended traffic?

They would be "effective" in the sense of blocking the exact type of traffic like Taproot envelopes but not in the goal of eliminating spam because they would simply use different scripts, like fake public keys.

That makes sense, thanks.

This is the kind of king-like stance that I talked about previously and which should not be fostered by Core though

AFAIK @gmaxwell isn't a Core developer anymore (at least he's no longer active at Github). He participates in discussions like you and me, but I think he's a little bit of a better understanding of Bitcoin's inner workings

Sure he isn't a developer, but that does not mean that he does not represent Core in other ways. He has influence, power and possibly even some control over some people and therefore you can see his statements as a reflection of Core's core (lol) sentiment. Were it not so you would occasionally see cases where his opinion is in contrast with with what Core is doing or wants to do. This practically never happens. Further, besides achow there is no other Core person writing at these forums at all really. Lastly, unlike him, you and me really have no influence at all.  

Ive already said this on X, only real solution if both sides truly want to **LIMIT** spam is a soft fork eliminating the witness discount, and adding a fee mutiplier to ALL data (excess witness + OP_RETURN).

Another one who totally ignores the "fake public keys" problem *yawn*.

I hate to repeat it so many times, but look into https://stampchain.io/explorer. There are 1.2+ million NFTs stuffed into fake public keys (only with that single protocol, and there are more ...) and which in addition reside permanently in the UTXO set, making operation more costly for the nodes than if they used OP_RETURN.

Luckily they didn't use OP_RETURN for this, right..? Luke-jr will save Bitcoin again.  


https://x.com/mononautical/status/1974493719719268610

[gmaxwell]

This is the kind of king-like stance that I talked about previously and which should not be fostered by Core though

AFAIK @gmaxwell isn't a Core developer anymore (at least he's no longer active at Github). He participates in discussions like you and me, but I think he's a little bit of a better understanding of Bitcoin's inner workings

Sure he isn't a developer, but that does not mean that he does not represent Core in other ways. He has influence, power and possibly even some control over some people and therefore you can see his statements as a reflection of Core's core (lol) sentiment.

What the actual fuck?

This is the kind of dumbfuckery and delusion that disqualifies a persons on these subjects.  What is this "some control"?    You're just making up nonsense to try to justify some unjustifiable opinion you've taken. Stop it.  It identifies you as either stupid or a piece of shit and either is someone no one should listen to.

The position you were commenting on doesn't have to do anything with authority-- it's about the fundimental nature of bitcoin as a censorship resistant system.  If _core_ were the parties pushing censorcrap then I'd be saying the same thing there:  What they want doesn't matter because the people opposed to censorship will simply route around them while they stand around wanking their paper straw ban.   So it's not a comment from any kind of authority except the fundamentally stronger position of anti-censorship in a system built for and around anti-censorship concepts.

It's also happens to be a think that people who do work on core have pointed out: that miners bypassed this restriction already and there isn't anything they can do about that.  The fact that I'm saying the same thing is because it's the truth and no one has a monopoly on the truth.  It's only when it comes to manipulation and spin that commonality is evidence of collusion or at least influence.

Were it not so you would occasionally see cases where his opinion is in contrast with with what Core is doing or wants to do.

You might if you were actually looking for that rather than just trying to confirm your own views (as in, I dunno, the most recent post of mine that makes any comment about functionality in core other than the filtering subject-- "As it stands I think it is a somewhat unsafe feature"..."they're hard to audit (arguably harder than the code) and don't require majority hashpower collusion to abuse so if anything the security process for them should be more strenuous"..."It's not a hypothetical risk either"..."I'd been expecting it to eventually get used by some more tamper resistant process, rather than just").

But your position isn't logical because except for smoothbrained oppositional defiant idiots that reflexively oppose good ideas just because someone of some perceived authority likes them normal people don't have any need to oppose stuff that other people are doing unless they both disagree and it affects them.  Core does a lot of shit I disagree with (and did even when I did work on it!) but which is of no consequence to me.  So like in the above example I think core has fucked up, but they did so mostly by pointing a gun at their own forehead, rather than having done something that concerns me so I had no reason to say anything about it except when someone brought the subject up.

[ABCbits]

Ive already said this on X, only real solution if both sides truly want to **LIMIT** spam is a soft fork eliminating the witness discount, and adding a fee mutiplier to ALL data (excess witness + OP_RETURN).

Another one who totally ignores the "fake public keys" problem *yawn*.

I hate to repeat it so many times, but look into https://stampchain.io/explorer. There are 1.2+ million NFTs stuffed into fake public keys (only with that single protocol, and there are more ...) and which in addition reside permanently in the UTXO set, making operation more costly for the nodes than if they used OP_RETURN.

Luckily they didn't use OP_RETURN for this, right..? Luke-jr will save Bitcoin again.  


https://x.com/mononautical/status/1974493719719268610

I got curious and did quick search. mempool.space give tag to that TX with "Fake scripthash"[1] and it seems it use standard called OLGA stamps[2]. It's crazy, considering using Ordinal would be cheaper and less bloat considering size of the arbitrary data. I'm not sure what Knots could do without also limit certain type of monetary TX or turn it into cat-and-mouse.

[1] https://mempool.space/tx/b1278acf50c27342753d01af9013a709509fdd920bc40ddcbec0738aaec2764c?showFlow=false#flow
[2] https://github.com/mikeinspace/stamps/blob/main/OLGA.md

[Satofan44]

What the actual fuck?

This is the kind of dumbfuckery and delusion that disqualifies a persons on these subjects.  What is this "some control"?    You're just making up nonsense to try to justify some unjustifiable opinion you've taken. Stop it.  It identifies you as either stupid or a piece of shit and either is someone no one should listen to.

I didn't make anything up, people are still allowed to have opinions. I could explain what I mean but perhaps that discussion is better suited for a separate topic, i.e., we might be going a bit too far into off topic territory.

I got curious and did quick search. mempool.space give tag to that TX with "Fake scripthash"[1] and it seems it use standard called OLGA stamps[2]. It's crazy, considering using Ordinal would be cheaper and less bloat considering size of the arbitrary data. I'm not sure what Knots could do without also limit certain type of monetary TX or turn it into cat-and-mouse.

[1] https://mempool.space/tx/b1278acf50c27342753d01af9013a709509fdd920bc40ddcbec0738aaec2764c?showFlow=false#flow
[2] https://github.com/mikeinspace/stamps/blob/main/OLGA.md

This is the first time I am hearing of OLGA stamps.

Anyway, the point is that Knots can't do anything. AFAIK there is no good method available for filtering this kind of stuff. So by trying to restrict OP_RETURN instead of encouraging it they are creating a stronger incentive for this way of storing data on the chain. That's why I posted this example here as soon as I encountered it. This stamping thing is orders of magnitude worse for Bitcoin than OP_RETURN that they can't even be compared in terms of detrimental effects.

This approach creates (effectively) permanent UTXOs, wherein a small amount of bitcoin dust is burnt.

If you care about Bitcoin, you will not develop something like this. Does luke even have any thoughts on this part of the subject or is he purposely avoiding the topic because it is difficult?  

[Wind_FURY]

Laughable to believe that they don't want a hard fork because "most of them are serious maxis". NO - they won't hard fork because the users, the economic majority, and the miners will follow the Core Developers and leave the filter boys with a shitcoin in their hands.

No, it is not. There is no need to exaggerate. A real maxi understands that a contentious hard fork is detrimental to Bitcoin and should be reserved for the extremest emergencies, which this is not. It has nothing to do with economic value. Why would they care about that?

 

Incentives - the ONE that's making the network stick together, and it's not debatable.

They will have coins on both chains with a fork.

But one chain will be like BCash, a shitcoin.

This drama/debate will not last long from now because soon the users will truly understand the issue, AND will truly understand that filtering is not only useless, it hurts network efficiency as well.

I've already explained to you somewhere else that we have all kinds of filters, therefore filtering is not useless. Stop repeating nonsense and start learning. Even the block size limit itself is a filter. Should we remove it completely since it is useless?  

Filtering is useless because dick-pic and fart-sound loves will go directly to the miners and pay them to have their dick-pics and fart-sounds in the blockchain.

What part of that don't you understand?

       ¯\_(ツ)_/¯

What the actual fuck?

This is the kind of dumbfuckery and delusion that disqualifies a persons on these subjects.  What is this "some control"?    You're just making up nonsense to try to justify some unjustifiable opinion you've taken. Stop it.  It identifies you as either stupid or a piece of shit and either is someone no one should listen to.

I didn't make anything up, people are still allowed to have opinions. I could explain what I mean but perhaps that discussion is better suited for a separate topic, i.e., we might be going a bit too far into off topic territory.

 

[Satofan44]

Incentives - the ONE that's making the network stick together, and it's not debatable.

You are not making any sense. Whether this network or their network becomes the majority network, the incentive is the same. You claim that they won't fork because of that, I claim that it doesn't make sense.

They will have coins on both chains with a fork.

But one chain will be like BCash, a shitcoin.

Again, you are not making a case for your argument. Economically speaking they don't care which chain becomes the largest, they get coins on both. BCash was a good opportunity to make some extra Bitcoin albeit at some risk. You just made up some claims about the other side yet you have no proof of anything. Refrain from making such baseless claims.

Filtering is useless because dick-pic and fart-sound loves will go directly to the miners and pay them to have their dick-pics and fart-sounds in the blockchain.

What part of that don't you understand?

       ¯\_(ツ)_/¯

No. You are mistaken. Some filtering is useless, other filtering is very useful and we have all kinds of filters in Bitcoin. Some are policy rules others are consensus rules, but they are filters in both cases. If you are not technologically adept to know the difference you should stay away from these threads instead of spreading misinformation.

Sucking up to an authority just because they are an authority is never a good look.  

[nutildah]

I got curious and did quick search. mempool.space give tag to that TX with "Fake scripthash"[1] and it seems it use standard called OLGA stamps[2]. It's crazy, considering using Ordinal would be cheaper and less bloat considering size of the arbitrary data. https://github.com/mikeinspace/stamps/blob/main/OLGA.md

The reason why this came about is because the Stamps protocol was born out of Counterparty, which uses multisig for transactions that are too big to fit in OP_RETURN. (I suppose this practice could be done away with now thanks to Core 30. Of course Counterparty is much older than Segwit.

Stamps were a reaction to Ordinals and an attempt to appeal to its users, with the selling point being "can't be pruned." The idea of embedding image data in Counterparty transactions predates Stamps by 9 years. "OLGA" is an acronym but its also a nod to OLGA, the first 1-of-1 token anywhere and arguably the first NFT.

In Aug 2015, JP Janssen, the creator of OLGA, embedded a 20 kb, stamp-sized image in a Counterparty broadcast, with the data split among 172 multisig outputs. Interestingly, these weren't "fake key" multisig outputs. They were consolidated and spent in April 2017.

However not all multisig outputs in Counterparty or spendable; for what reason I don't really understand, but I would like to.

Some transactions from Counterparty were created with invalid public keys and are no longer redeemable.

See also: https://github.com/bitcoin/bitcoin/issues/5939

Does luke even have any thoughts on this part of the subject

He does:



I guess the stamps are filtered in Knots by baremultisig=0.

[d5000]

I guess the stamps are filtered in Knots by baremultisig=0.

The answer of MikeInSpace (I guess he's the Bitcoin Stamps creator) seems to confirm this. The following sentence is however the essence of the problem with filters:

The problem with a cat and mouse game is that the mouse can iterate much faster than the cat.

Of course they could create a very specific filter for the OLGA protocol (which uses P2WSH) too, e.g. detecting the OP_RETURN metadata attached to them, but the problem with this approach is that "the mouse" can always change the protocol, without any harm, because the existing NFTs are already in the blockchain, and it may even increase their value as "legacy" Stampchain NFTs. In the end you will be filtering a lot of legit transactions too, probably.

Interesting historic insight, by the way

No. You are mistaken. Some filtering is useless, other filtering is very useful and we have all kinds of filters in Bitcoin. Some are policy rules others are consensus rules, but they are filters in both cases.

Policy "filters" all have the problem Wind_FURY states.

I've looked into Protocol Rules to see which rules could be seen as "filters". Apart from the "obvious" rules (e.g. that no transaction can create coins out of thin air, transactions cannot be bigger as the block size limit etc.), I've found the following ones for transactions ("tx" messages):

5. Make sure none of the inputs have hash=0, n=-1 (coinbase transactions)
6. Check that nLockTime <= INT_MAX, size in bytes >= 100, and sig opcount <= 2
7. Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey not matching the two usual forms
11. For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction
15. Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block

For those who know more: are rules 7 and 15 really consensus rules? In particular rule 15 seems very loosely defined. I guess here the wiki article is incorrect.

Nevertheless you're correct, there are a few "effective" filters as of now. We could add a Taproot envelope filter to them, but my guess is that TapScript is flexible enough to allow constellations which could store significant quantities of data without being "blockable" if the goal is to not cripple "legit" TapScript use cases.

[Wind_FURY]

Incentives - the ONE that's making the network stick together, and it's not debatable.

You are not making any sense. Whether this network or their network becomes the majority network, the incentive is the same. You claim that they won't fork because of that, I claim that it doesn't make sense.

I'm sorry if you don't understand how Bitcoin as a decentralized network, or any decentralized system for that matter, truly works. It's a FACT, and it's NOT debatable.

-- Snip --

I'll end the discussion there because it's useless talking to you. I debate people in the forum to learn something out of it, but you're not one of those people yet. I'm not trying to offend you, ser. Pardon me.


gmaxwell, you're a mod in this subforum. Perhaps signatures should be disabled in Development & Technical Discussion?

    🤔

[Pmalek]

I don't know anything about Bitcoin Knotz, but if I wanted to run a full node, I am not sure that I would want that to be Knotz. Luke Dashjr as the head developer and main maintainer, no thanks. He claims to have been hacked and lost over 200 BTC. Some of those coins he allegedly kept in cold wallets. I wouldn't want the security of my Bitcoin wallet to rely on a person who gets his cold wallets hacked. And if he wasn't hacked and the story was made up, then he is lying. I also wouldn't trust a liar.