summaryrefslogtreecommitdiff
path: root/ce/90aa1b0efa013889758ba7b482e8a540466910
blob: 5cd1ad5dade286ef7d22288baf5ebd4371570aba (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
Return-Path: <marc@rupy.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4C33F413
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  3 Aug 2016 09:53:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from v-smtpout3.han.skanova.net (v-smtpout3.han.skanova.net
	[81.236.60.156])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id D2FA3FD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  3 Aug 2016 09:53:52 +0000 (UTC)
Received: from rupy.se ([2.248.42.217]) by cmsmtp with SMTP
	id Uss3bbVjabd4bUss3bILXp; Wed, 03 Aug 2016 11:53:51 +0200
Received: by rupy.se (Postfix, from userid 1000)
	id E3A8131531; Wed,  3 Aug 2016 11:53:51 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by rupy.se (Postfix) with ESMTP id DEA0C31530
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  3 Aug 2016 11:53:51 +0200 (CEST)
Date: Wed, 3 Aug 2016 11:53:51 +0200 (CEST)
From: Marc Larue <marc@rupy.se>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <alpine.LNX.2.00.1608031152530.359@rupy.se>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-CMAE-Envelope: MS4wfAWJVXy1uznMwOLifIpN2eDLE6rxpaUN6tUnJ9Y6nNN4qzp5fs6uPoP2jxKwLhEnNyjHy6v4WzsI3i5bXy/zH99fXZ/7/xXR10SJTuhxgvyQGwi7i1zA
	q3xkqD4xPQFhcQwgniADwkkiSyF5MxvnjDdrb28SNcj5vtbuCaZcxNaP
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 03 Aug 2016 18:25:03 +0000
Subject: [bitcoin-dev] Fees and Accounts
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2016 09:53:57 -0000

Hi,

I have 2 problems with bitcoind that separately are not a problem but
together they make the platform unusable for many projects.

If I have accounts I need to make sure the account holders do not 
overcharge their account. To do this I can now use "createrawtransaction() 
+ fundrawtransaction() + signrawtransaction()" and then make sure the
transaction can be paid by an account.

But since you deprecated the accounts and there is no
sendrawtransactionfrom() method; I either have to build my own account
system (this is no picknick btw, since you need to track all incoming 
funds to all addresses and having an integrated account system in bitcoind 
is 100% necessary to do this effectively).

Or I might be able to go ahead and speculate that you will not be able to
untangle the account code and hack my bitcoind to have a sendfrom with a
fixed fee parameter that overrides the size multiplication and I just do
the math before I send hoping that the transactions go through (this is 
bad but better than having accounts overcharge because they send dust that 
induce high fees).

I understand the privacy problems with using accounts for off-chain
microstransactions but currently it's the best workable option.

I hope you understand that I'm not trolling here, I have been mining since
2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I descovered
that once transactions will require fees (back then they didn't) and that
your system is not able to handle fees with accounts, I stopped developing
everything related to bitcoin.

There are probably 100s if not 1000s of developers in the same situation.

You can't just deprecate accounts like that because nobody likes the code.
Without accounts bitcoind is only a person-to-person manual client.

To build many-to-many automatic "organisations" on top of bitcoind you 
need accounts and you need fees that are predictable.

Kind Regards,

/marc