Bitcoin Forum
May 05, 2024, 10:23:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Bitcoind alternative - for server  (Read 2651 times)
benjyz
Full Member
***
Offline Offline

Activity: 140
Merit: 107


View Profile
March 08, 2014, 07:19:30 PM
 #21

there was a discussion about the account system recently: https://github.com/bitcoin/bitcoin/issues/3664 it was argued to get rid of accounts for the reasons mentioned above. instead it was suggested to (re-) introduce tagging.

what i would like to say are some server side implementations. I just went through all github repos with the word bitcoin in them and on the server side the only thing I have found is this.
https://github.com/kangasbros/django-bitcoin

there is definitely a lot of room for many more sample apps for a more plug & play environment. most merchant integration happens via commercial API's which is not good IMO.

Quote
It is pointless to cache user balances in SQL, because it may be changed at every user withdrawal. No way to say "send ONLY from THIS address".

you have a set of balances in your database which reflect past payments to a set of addresses. then you rescan and they are up to date. there is no realtime aspect to this. you have to keep track of all internal tx, to prevent double spend. any tx going outside need confirmations, see also https://en.bitcoin.it/wiki/Transaction_Malleability
1714947809
Hero Member
*
Offline Offline

Posts: 1714947809

View Profile Personal Message (Offline)

Ignore
1714947809
Reply with quote  #2

1714947809
Report to moderator
1714947809
Hero Member
*
Offline Offline

Posts: 1714947809

View Profile Personal Message (Offline)

Ignore
1714947809
Reply with quote  #2

1714947809
Report to moderator
Whoever mines the block which ends up containing your transaction will get its fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714947809
Hero Member
*
Offline Offline

Posts: 1714947809

View Profile Personal Message (Offline)

Ignore
1714947809
Reply with quote  #2

1714947809
Report to moderator
miso (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
March 08, 2014, 09:09:04 PM
 #22

Well to clarify bitcoind "core" works as expected.  IMHO the accounts functionality have always been next to worthless (there are other edge cases which can cause unexpected problems).   Most people wouldn't miss it if accounts were moved completely and it would avoid these kind of x-y questions.

I think bitcoind accounts are not worthless because custom reimplementation of the functionality cost long time for each custom implementation and testing.
It is already implemented and tested and provides methods you would maybe implemented, so it saves time in general.
Yes, if you implement totally custom account ledger because it has to be specific, bitcoind account functions are useless - you just need assign id to each address or whatever.
But in my situation I do not have resources (time/people) to reimplement it safely with testing.
Its bad design decision that the same wallet user use as client is on the server. But the client is still not final, so...

I would say that it is easier to be aware of and fix edge cases than to properly reimplement accounts.
What problems bitcoind accounts have? Everyone across the web says about problems, but I have encountered only a few:
1. Fee is added after sendfrom method internal check, so account may have (slightly) negative balance after withdrawal.
2. In the move method, the minconfirmations parameter does not work and is useless - but the wiki documentation describes it. The workaround is to use semaphore/lock/synchronized method/synchronized block and test balance, then move.
3. "" account is weird and I do not like that some methods work with "" implicitly. I just made my RPC interface ignore the methods and "" account.
4. No watching-only wallet support. This is the main reason I am looking for bitcoind alternative, because the cold storage design rocks. I am fine with warning and forcing users to not having large amounts in my app until there is nice cold storage solution or my app became more popular (do not worry, I am not launching any magic). I know the pywallet workaround with keypool and AFAIK it is tbe best solution for bitcoind.
miso (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
March 08, 2014, 09:45:10 PM
 #23

there was a discussion about the account system recently: https://github.com/bitcoin/bitcoin/issues/3664 it was argued to get rid of accounts for the reasons mentioned above. instead it was suggested to (re-) introduce tagging.

what i would like to say are some server side implementations. I just went through all github repos with the word bitcoin in them and on the server side the only thing I have found is this.
https://github.com/kangasbros/django-bitcoin

there is definitely a lot of room for many more sample apps for a more plug & play environment. most merchant integration happens via commercial API's which is not good IMO.

Quote
It is pointless to cache user balances in SQL, because it may be changed at every user withdrawal. No way to say "send ONLY from THIS address".

you have a set of balances in your database which reflect past payments to a set of addresses. then you rescan and they are up to date. there is no realtime aspect to this. you have to keep track of all internal tx, to prevent double spend. any tx going outside need confirmations, see also https://en.bitcoin.it/wiki/Transaction_Malleability
Thanks for the django-bitcoin, seems interesting.
Yes, I am aware of issues of unconfirmed transactions. bitcoind's balance related functions have optional minconf parameter, so working with balances is practical and secure, so I hope the recommended software in this thread have rich APIs
benjyz
Full Member
***
Offline Offline

Activity: 140
Merit: 107


View Profile
March 09, 2014, 05:11:11 PM
Last edit: March 09, 2014, 05:22:05 PM by benjyz
 #24

Why do you need minconf? also forget about accounts. they will likely be removed. an account system is nothing else than a custom tags for addresses you control anyway.

with rpc you can simple iterate over the addresses and check for number of confirms. here is a snippet for bitcoinrpc.

Quote
btc_conn = bitcoinrpc.connect_to_remote('user','secret',btc_ip,'18332')

ra = btc_conn.listreceivedbyaddress()

for x in ra:
    print 'address %s  amount %s  confirms: %s'%(x.address,x.amount,x.confirmations)

Yes, you need atomicity. The way you do that is check for internal orders versus withdrawals. Say you have a service like eBay running on bitcoind. If userA has 1 BTC and purchases a good from userB, you need to make sure userA does not place an order and withdraws at the same time. you need to calculate the correct balance at each time, and withdrawals have to be subtracted immediately. then you can add extra security measures depending on your needs. you simply can't do bitcoin transactions in realtime (without a dedicated channel). you have to let users deposit and withdraw through the blockchain and make sure on your side that you have not an internal double spend/malleability atttack (https://en.bitcoin.it/wiki/Transaction_Malleability).

it would be very good if bitcoind would introduce a proper threading model /hooks (like btcd). It is however extremely unlikely that you reach a performance bottleneck with this pattern, and core devs have other things to worry about. this is largely the problem that not enough code is being shared, but build by merchants. merchants/exchanges are too busy making money, instead of helping the ecosystem, if they are not busy losing money for customers.

again, remember bitcoin does not operate in realtime. every unconfirmed transaction is to be treated as a double spend/fraud.
miso (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
March 10, 2014, 04:26:41 AM
 #25

minconf is useful because I can get users unconfirmed balance, confirmed balance (3x/6x).. So, I can decide if it is OK to resend bitcoins away or move value to other account - for example I allow withdrawal only with 6 confirms but allow to move offblockchain with 3 confirms.

If I wanted to reimplement getbalance I have to use the algo you suggest: retrieve all the addresses, skip irrelevant, skipp addr with confirm. of last TX < 6...
If I have thousands of addresses and many users I would skip most of them. It is probable that the bitcoind's implementation is efficient (I do not know), but at least already tested and implemented so I can use getbalance account minconf
The atomicity: If I went to implement atomic send, I need to [lockA]; getBalance; checkBalance; ?withdraw; [unlockA] and [lockA]; getBalance; checkBalance; ?payForSomething; [unlockA]
This can be replaced with atomic sendfrom. Yes, I have to implement my own lock [lockMove] getBalance; checkBalance; move [unlockMove] and some locks on higher layer of my app, but thats it.
As prototype of my app, bitcoind accounts are suitable. Its not the design which I do not like, but the implementation.
I will change the design with new bitcoind without accounts (next 0.9 should have accounts) or when some other client has watching only wallet for server.

Is there any opensource alternative to bitcoind + pywallet + keypool workaround for watching only wallet?

AFAIK the current 0.8.6 does not have problem with transaction malleability. http://bitcoin.stackexchange.com/questions/22304/is-transaction-malleability-an-issue-when-receiving-payments
Should I know something?
arnuschky
Hero Member
*****
Offline Offline

Activity: 517
Merit: 501


View Profile
April 13, 2014, 10:46:43 AM
 #26

Is there any opensource alternative to bitcoind + pywallet + keypool workaround for watching only wallet?

I've been wondering that as well...
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!