You are viewing a single comment's thread from:

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

in #bounty7 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

Sort:  

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

Coin Marketplace

STEEM 0.12
TRX 0.33
JST 0.032
BTC 114262.85
ETH 4161.33
USDT 1.00
SBD 0.78