Update: Bounty increased to 34 STEEM : Proof of concept Beem/lightsteem based signed operations for asyncsteem.

in bounty •  6 years ago 

Before I put a 10 STEEM bounty on finding a way to make two currently incompatible Python STEEM RPI libraries asyncsteem (by me) and Beem (by @holger80) play nice in a way that would allow an asyncsteem/Twisted based app use Beem signing functionality without invoking any blocking operations (other than blocking on CPU usage needed to do the actual signing).

As my post on Building an asyncsteem python web app with micro-transaction-based steem user authentication, Redis and Jinja2 did rather well with the Utopian crowd, ending up in the Weekly Top of Utopian.io, I can now increase the bounty from 10 STEEM to 34 STEEM.

The bounty of 34 STEEM is currently coupled to this Task request. I was recently made aware that apart from steem-python and Beem, there is a third blocking STEEM RPC library LiteSteem by @emrebeyler.

Finally, I have moved the deadline for being eligible for the 34 STEEM bounty back one week.

So to summarize

  • The bounty has gone up from 10 STEEM to 34 STEEM
  • The deadline has been extended by one week to 8 October 0:00 AOE
  • It is now also allowed to come up with a solution that instead of Beem uses Litesteem.
Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  
  ·  6 years ago (edited)

Hi pibara, I read your about your task request. I added a option to the transactionbuilder for let beem work complete offline. He needs only the current blocknumber and prefix and builds a signed dict that can then be broadcasted with your async steem. Is this a solution that is fine in your eyes?

Posted using Partiko Android

Sounds promising indeed. The task request also has a 34 STEEM bounty you might find interesting. If you can, as the TR describes " write a proof of concept asyncsteem Python script that does a nonblocking asynchronous signed operation within the context of handling an asynchronous event " before the deadline the 8th of October 0:00 AOE time.

My thoughts are that adding a refund to the microtransaction authentication script ( source code here ) would be a good proof of concept that could reuse a maximum of existing code so that the proof of concept could focus on the specifics of making the two libs play nice.

Within TransferStream::transfer transfer_event["transaction_meta"]["block_meta"] contains block level fields "witness_signature", "block_id", "signing_key", "transaction_merkle_root", "witness" and "previous".

In CookieUtil::process_transfer::process_last_time::process_account, after setting the account cookie mapping would be the place for adding an asynchonous vote using beem transactionbuilder and asyncsteem rpcclient.

But wether you go for the bounty or not, I think that if the bounty/task-request expires without a POC, I shoukd definetely be able to work with what you described. Great work.

Ceterum censeo HF20 esse delendam