Topic: [ANNOUNCE] TENEBRIX CODE BOUNTY (Read 1624 times)

There is an extremely strong support for this tweak from the "we need our deflation BACK" brigade (this whole tweak is the result of email exchange with some of the more vocal and driven people on that front) and it appears that nobody really minds it since it does not affect fundamental network behavior from current user perspective (nominally, fees are still fees and "miner tipping" isn't used) and miner perspective (without subsidy cuts, no one cares about whether fees proper are blackholed)

So the only problem could be update apathy, but since I intend to bundle it with new and better miner suite and perhaps linux blobs, I expect that to be overcome (especially if the DEFLATION brigade will help out on the public awareness front)

Question:

Is there enough support in the TBX community to implement such a change to successfully take over 51% of the chain right away at block x?

I don't mine TBX so this doesn't really concern me, but I'm curious.

Well, finding a keypair that would have a pubkey which, when processed via standard bitcoin sequence, results in EXACTLY DevNull0DevNull0DevNull0DevNull0000000 is expensive enough to be considered a purely theoretical concern (thousands millions of years down the line, my posthuman nanorobotic descendants will reclaim all those brix, muhahahaha!)

Of course, one could make a custom transaction output  script along the lines of, maybe, "push false, return"  for those fees, and modify "standard transaction" rules accordingly.

I guess it's up to the programmer (who I am not) to decide which way to take, but ways that allow easy coin burning in other situations would be considered superior of course.

If I remember correctly, the only EC public key assured not to have a private key is all zeros (or some transformation of it needs to be all zeros). My cryptography books are in storage, so I won't be able to contibute. But it would be nice to have a citation for a mathematically guaranted black-hole address.

There was somebody on this forum posting the elliptic curve crypto code in the programming language J which allowed the use of arbitrarily small finite fields. In a small field one could simply do an exhaustive search for the subfield with no solutions. And then generalize it for the NIST fields and curves.

Alternatively, you could generate a valid key pair on a computer disconnected from the network, write down the public key, burn the whole computer and post the video of the whole stunt on youtube. Probably more people would believe that such a key is a black-hole than when you would publish a mathematical proof.

ArtForz is a highly proficient programmer with almost uncanny grasp of long-term consequences of various tweaks and bells and whistles one might want in a cryptocoin, and he kindly agreed to review the submissions.

Of course, given public and open-source nature of TBX and this bounty, others are welcome to review the code as well

ArtForz is not prone to nepotism and not impervious to calm, rational argument, and given the public nature of this exercise  anyone who disagrees with his assessment upon review will have every mean imaginable to express his/her PoV and provide counter-arguments.

He's busy with a more complicated and important (vital,even) feature , and reviewing submissions is far less work than making one of your own.

So why not get other people involved for a fairly reasonable compensation, huh ?

 bounties for spam, however, are sign of a true masterpiece

It is not very promising if the maintainer of a cryptocurrency is not a developer and has to make a job posting for code improvements 

Upon contemplation, I like the "use special-case bullshit address DevNull0DevNull0DevNull0DevNull0000000 for coin burning" idea very much, as it seems very easy to reuse later for other coin-burning tricks that are about to come

Well, that seems smart.

Since I'm not a coder, "a-la namecoin" should be interpreted as "really thoroughly destroyed, those coins should be", not "implement it specifically as in namecoin" (other tricks are fine, as long as it works as described above).

So yes, "sending" them to a special-cased bullshit address such as DevNull0DevNull0DevNull0DevNull0000000 might be  an option.


 

Couldn't the destruction be done by sending the coin to a non-existing or impossible to create address like "qThisAddressDoesntExist"?

I have no idea how Namecoin does it though.

Edited for clarification

Exactly!

so when you send 0.2 as fee, 0.1 being the minimum fee, would then the tip be 0.1 and 0.1 be destroyed?

Okay, the first TBX code bounty isn't very horribly sophisticated, and the reward will be equivalent of 25 BTCs in TBX @ moment of completion (just so that dear programming types don't worry that much about TBX value fluctuations, a concern some candidates have expressed)

What I want is to slightly tweak fee system so that it becomes a mild deflationary influence. This is one of several upcoming tweaks that introduce deflationary influences (perhaps not strong ones, but combined they will amount to something)  to TBX without cutting subsidies or involving any form of demurrage, since deflation folks are giving  a fascinating ammount of sustained grief (they even found my reg email, somehow   ), and after a while I decided that if someone wants "deflashun" so bad, I may as well find ways to give it to him without compromising core commitments of TBX (such as no subsidy decrease and no demurrage)

The gist is as follows:

****

Basically, currently both mandatory and "speed me up" transaction fees are being sent to the miner.

In a setting where miners will never switch to "feed on fee" model, the fees play only two roles - discourage spam in the chain and "bribe" the miner to process your tx faster (a very "down the line" issue when the net is teeming with them tx'es)

My idea is to basically impose a rule that says that "if currently set fee for a transaction is  2*(minimum mandatory fee for this transaction) or more, BUT no less than X, then it is a TIP.

Tips are sent to the miner and thus normal "miner bribe" stuff applies"

Meanwhile, if fee for a transaction is less than X and/or less than  2*(minimum mandatory fee for this transaction), then it's a fee and it gets destroyed a-la namecoin coin destruction.

Thus, we still can "tip" the miners (with certain minimum for a tip being  X ), but usual "mandatory-antispam" fees are burned, thus creating an additional deflationary effect without "offending" miners or disrupting user's normal coin hoarding inclinations.

In case both a tip and a fee are present (minimum mandatory fee is 0.1, X=0.2, user sets his fee to 0.2), the "minimum transaction fee" is burned and the remaining part is used as "tip" to the miner (if minimum transaction fee is 0.1, X value is 0.2 and user has set his fee to 0.2, 0.1 is burned and the remaining 0.1 is used as fee)

Fee-burning would be best made  network-mandatory for mandatory fees (that is, blocks that contain TXes that don not include a burned fee but  SHOULD have included a burned "minimum transaction fee" per "minimum fees" rules would be best rejected by well-behaving nodes.

edit:
Also, it would be nice for an option that would enable a user to knowingly make a transaction that would burn a specified number of coins to be added.

The mechanism should be ready for deployment at "block N", and should be implemented in a manner that only requires 51% of miners to upgrade (and not all clients), and generally care should be taken to minimize the disruption those who fail to upgrade in time could cause.

****

Art Forz has reviewed this proposal for "general sanity" and will review submissions. The implementation that is found to have no flaws as per ArtForz's assesment, and/or the first to correct any flaws found, shall receive the bounty.

More (tiny but distinctly deflationary) tweaks to come.