GentBG x PUSSTEEM - burning both STEEM and PUSS

-
Image
by joviansummer original STEEMIT post: https://steemit.com/blog/@joviansummer/gentbg-x-pussteem-burning-both-steem-and-puss Hello, this is @joviansummer(witness: @jswit), developer of GentBG project. I registered @gentbg account to PUSSTEEM about a week ago and donated some of my own PUSS token to @gentbg's EPUSS account. Now, @gentbg will burn STEEM and EPUSS at the same time. PUSSTEEM's boosting upvotes will help increasing baseline burning significantly. @gentbg's SP reward is delegate to @jsup to get automated upvotes, forming a baseline burning of liquid reward independent of other people's upvotes. Some may argue 100%(both liquid and SP reward) burning is much better, but I chose this approach to prevent @gentbg from becoming a spamming account. Constantly asking for upvotes via mentioning and commenting every week may eventually become a big annoyance to curators. That being said, anyone is welcome to participate in countering STEEM inflation by giving upvotes ...
Post a Comment

파이썬 beem에서 계정 트랜잭션 이력 조회할 때 요청 1회당 조회수 제한(batch_size)

-

by joviansummer
original STEEMIT post: https://steemit.com/blog/@joviansummer/8df222-beem-1-batchsize

파이썬 beem에서 Account 객체의 history() 함수를 이용해서 계정 트랜잭션 이력을 조회할 때, API노드에 한번 요청을 할 때 몇개의 응답을 가져올 것인지를 제한할 수 있습니다. 우선 트랜잭션 이력 조회 방법에 대한 내용은 이전 포스팅을 참고하시기 바랍니다. 아래의 링크입니다.

파이썬 beem에서 계정 트랜잭션 이력 조회(범위 지정)

위의 포스트에 있는 예제 코드를 다시 적어 보면 아래와 같습니다. 

from beem import Steem
from beem.account import Account

steem_node = ["https://api.steemit.com"]
steem = Steem(node=steem_node)

account = Account('joviansummer', blockchain_instance=steem)

history_data = account.history(start=1, stop=5, use_block_num=False)
for record in history_data:
  print(record)

위의 예시에서 history()의 인자에 batch_size 옵션을 추가해 주면 됩니다. 예를 들어 위의 예시에서 첫번째 트랜잭션(start=1)부터 200번째 트랜잭션(stop=200)까지 조회를 할 때 batch_size를 100으로 지정하면, 한번에 100개씩 가져오게 되므로 API노드로 전송되는 조회 요청은 2번이 될 것입니다. 

history_data = account.history(start=1, stop=200, batch_size=100, use_block_num=False)

굳이 이 batch_size를 지정해야 하는 이유는, 최근에 스팀잇의 공식 API노드에서 계정 이력(account history)에 대한 요청의 batch_size에 해당하는 제한 수치를 1000개(기본값)에서 100개로 줄였기 때문입니다. 위의 경우에 batch_size 옵션을 지정하지 않으면 제대로 응답이 오지 않고 예외(exception)가 발생합니다.

계정 이력 조회 관련 제한에 대한 내용은 @ety001님의 포스팅에서 확인 가능하며 아래의 링크입니다. (알려주신 @etainclub님께 감사드립니다)

The official API node will decrease the get_account_history upper limit

@joviansummer의 스팀 프로젝트

스팀 증인노드를 운영중입니다. @jswit에 증인투표해 주시면 감사하겠습니다.
(https://steemitwallet.com/~witnesses)

jswit 증인 노드 프로젝트를 시작합니다.

jsup 업보팅(upvoting) 서비스 소개

jsup 수혜자 지정 기능 추가

jSTEEM 프로젝트 - 텔레그램 챗봇으로 구현하는 스팀 블럭체인 탐색기

STEEM.NFT - 디지털 아트 보존 프로젝트


Posted through the AVLE Dapp (https://avle.io)

Comments

Post a Comment

Popular posts from this blog

스티미언의 영향력 지수 계산

-
by joviansummer original STEEMIT post: https://steemit.com/blog/@joviansummer/5qvaqw 오늘 이런 저런 생각을 하다가 문득 떠오른 내용인데, 잊어버리기 전에 적어 둡니다. 스티미언이 스팀 생태계에 행사할 수 있는 정량적인 영향력에 대해 생각해 보았습니다. 좋은 글을 많이 썼다거나 서비스를 개발했다거나 아는 사람이 많다거나 이런 정성적인 영향력과는 별도로, 수량으로 표시할 수 있는 영향력에 대한 것입니다. 일단 직접적인 수량은 보유한 스팀파워입니다. 예를 들어 50만sp를 보유하고 있다면, 아마 고래라고 칭해도 될 것 같습니다. 그런데, 조금 더 생각해 보면 영향력을 보유한 스팀파워만으로 측정하여 고래라고 간주하는 것은 과도하게 단순화시킨 감이 없지 않습니다. 현재 수량화된 측면에서 스팀 생태계에 영향력을 행사할 수 있는 방법은 2가지가 있습니다. 이 2가지 방법은 스팀파워를 지닌 스티미언 모두에게 유효합니다. 첫번째 방법은 업보팅입니다. 스티미언은 나에게 크게 보팅해 주는 사람의 의견에 영향을 받을 수밖에 없습니다. 큰 스팀파워로 보팅해 주는 스티미언이 많을 수록 커뮤니티가 활성화되고 신규 사용자가 유입될 가능성이 높아집니다. 방글라데시 커뮤니티가 실제 사례라고 할 수 있을 것 같습니다. @jungjunghoon님의 일파만파 운동은 보팅의 영향력을 확대하여 커뮤니티를 활성화하려는 시도라고 생각됩니다. @jsup의 후원 보팅 기능도 이러한 취지로 개발되었습니다. 두번째 방법은 증인투표입니다. 스팀 블럭체인은 증인들이 운영하는 서버(증인 노드)에 의해 유지되기 때문에, 누가 블럭체인을 유지할 것인지를 결정하는 증인투표는 일종의 주권 행사라고 할 수 있습니다. 최상위 증인 20명은 한달에 약 1만스팀을 증인 보상으로 받게 됩니다. 서버 운영비를 충당해야 되므로 1만스팀 전체가 수익이 되는 것은 아니지만 그래도 상당한 수입입니다. 하위 증인들은 순위에 따라 보상을 받는데 21위라고 해도 한달에 ...
Read more

jsup/avle code update - you don't have to write post everyday

-
by joviansummer original STEEMIT post: https://steemit.com/blog/@joviansummer/jsup-avle-code-update-you-don-t-have-to-write-post-everyday Hello, this is @joviansummer, developer of @jsup and@avle voting service. Voting service code for @jsup and @avle has been updated. I had been considering this update for a while, and recently I could come up with detailed implementation plan which resulted in a relatively swift code revision. The new added feature is capability to give daily upvote to the first thing you write for the day(timezone GMT+9) regardless of post or comment/reply. Writing a post everyday can be challenging. In that case, you can write a reply to receive daily upvote because writing a reply everyday is much easier and also a good way to engage in your community. Writing a post everyday just to get an upvote can be very tedious and exhausting, and post itself could easily become low-quality. There may be people who enjoy writing a post everyday, but we can't ignore th...
Read more

jsup/avle 보팅 코드 갱신 - 1일1포스팅 강박에서 벗어나기

-
by joviansummer original STEEMIT post: https://steemit.com/blog/@joviansummer/jsup-avle-1-1 안녕하세요. @joviansummer입니다. @jsup과 @avle의 보팅 코드를 갱신하여 적용하였습니다. 검토는 상당히 오래전부터 진행해 왔습니다만, 최근에 구체적인 설계 방향이 잡히고 기술적으로 어떻게 할 것인지에 대해서도 결정이 되면서 생각보다 빠르게 코드 수정이 진행되었습니다. 새로운 기능은 신청자에 대해서 포스팅이 아니라 댓글에도 보팅을 하는 것입니다. 매일 포스팅하는 것이 부담스럽고 힘들다면 댓글을 달면 됩니다. 당연히 1일1포스팅보다 1일1댓글이 훨씬 쉽고, 댓글을 많이 쓴다고 나쁠 것도 없다고 생각됩니다. 임대 보팅을 받기 위해 억지로 매일 포스팅하는 것은 본인에게도 괴로운 일이고 포스팅 자체도 결국 저품질화될 가능성이 큽니다. 매일 포스팅하는 것이 즐거운 사용자들도 있겠습니다만, 단지 보팅 때문에 억지로 쥐어 짜서 하루에 하나씩 힘들게 포스팅하거나 사실상 내용이 없다시피 한 포스팅을 하는 사용자들도 있는 것이 현실입니다. 보팅을 받아야 한다는 압박감으로 매일 억지로 포스트를 쓰기 시작하면서 스팀잇은 재미 없고 따분한 곳이 되어 갑니다. 게다가 스팀잇의 트렌딩 페이지는 사실상 대량의 임대 셀프 보팅을 받는 사용자의 포스팅을 모아놓은 공간처럼 되어 있어, 이대로 계속 가면 SNS 본연의 매력은 상실하고 코인 채굴장 그 이상도 이하도 아니게 될까 우려되는 측면도 있습니다. 댓글 보팅이 이런 문제를 완화하는데 조금이나마 기여할 수 있지 않을까 생각됩니다. 대상: @jsup 또는 @avle에 스팀파워를 임대하여 보팅을 받고 있는 계정 신청 방법: @jsup 또는 @joviansummer의 최근 포스트에 "댓글 보팅을 신청합니다"라는 내용으로 댓글을 써 주시면 됩니다. 제가 확인하고 서버에 등록하면 다음날부터 해당 계정은 포스트/댓글 관계 없이 그날 처음 작성하...
Read more