Thanks.


I know this is true for mining, i.e. CreateNewBlock, but my question is specifically about relaying/admitting to mempool. From what I can see, no matter how high the tx priority is, if there is zero fee then it's subject to rate-limiting. This suggests that even high priority transactions may not get relayed properly if they don't include a fee. Just want to make sure that I'm interpreting it correctly.

Hi I'm trying to understand the default behavior for relaying of zero fee transactions.

In AcceptToMemoryPool we have:


There's no reference to tx priority; am I right in saying that all zero-fee transactions are subject to rate-limiting, regardless of their priority?  I had the impression that this was not the case, given how it is often said that transactions with sufficiently high priority can be sent safely without fees.

An additional question: in the wiki it says that "A transaction may be safely sent without fees if ... all outputs are 0.01 BTC or larger". I'm not sure where this 0.01 BTC figure comes from, I couldn't find any reference to it in the code, could someone point it out for me?

Thanks.

Hi,

On the Lockbox documentation page https://bitcoinarmory.com/about/using-lockboxes/ it's stated that:

"There is no compromise to security by using a lockbox multiple times, and we would encourage you to use a lockbox as many times as necessary if it matches your security and convenience needs."

This comes as a surprise to me, having heard time and time again that address reuse is bad, and having seen the consequences of address reuse in the Android SecureRandom bug. Is lockbox (multisig) address reuse different in any way from the single address case, that would lessen the risk? As a computer security layperson, how would I go about evaluating the risk involved in reusing lockbox addresses?

Thanks for this great new feature and would appreciate some insight on this topic.

Hi, I just created a greenaddress.it wallet and played around a bit, overall I am quite impressed with the concept and its execution. Just a few thoughts:

1) nLockTime for user refund is nice and all, but the time-locked refund tx is only provided after the new incoming tx has been broadcast, so your nLockTime solution does not protect me, if for example, if I receive a payment in a state where greenaddress.it keys have already been lost, for example. Of course this is the way the service has been designed, so I'm not sure if there exists a solution. Have you any thoughts about this? Is there a way to design a payment protocol perhaps such that the sender only signs the inbound tx after the nLockTime tx has been provided to the recipient?

2) Micropayments. I notice that the way micropayment channels are set up is very similar to how greenaddress.it works. I wonder if you have given any thought to integrating a micropayment system into your wallet? I have been waiting to see a real solution for receiving off-blockchain, zero-fee transactions which doesn't require the sender to have an account with any specific third party like Coinbase for example.

Good luck with your service!

I find nothing factually wrong with your point of view, but I can't help but feel that your approach to this problem is against the spirit of Bitcoin. Centralized systems requiring trust are generally cheaper to operate than decentralized ones - think for example of modern governments and the deadlock that they often find themselves in - the cost of a centralized system however is in the potential abuse of trust, monopolistic inefficiencies, etc.

The great innovation of Bitcoin is in allowing for a decentralized financial network at a relatively low cost. While you may be right in saying that the economics may not permit small transactions to go on the blockchain, our focus should be to push the limits of the technology to reduce costs, and then let the free market decide what the blocksize should be, rather than chastising people for having "this kind of religious thinking". Centralized payment systems on top of Bitcoin will always exist, it is up to the individual to decide if the cost of giving up autonomy is less than the cost of using Bitcoin directly, however we ought to do all we can to make centralized systems unnecessary.

I'm sorry if the debate on this issue has evolved significantly beyond this, please feel free to point me in the right direction.

Hi everyone, as an average bitcoin user, Armory's offline mode is very appealing to me. However I fall into the 'electrum users' camp of those not able to run a full node. So I was wondering if there is any way for me to still utilize Armory offline, for example is there any web service that would manage my watch-only Armory-compatible wallet for me, and generate and broadcast the transactions?

I think, for casual but security conscious bitcoin users, that this would go a long way in allowing us to benefit from the great features of Armory by making it more accessible. Thank you!

Nagato,

Regarding the new verification policies, was wondering what specific regulations are you being required to comply with? Have you been in contact with MAS regarding the status of Bitcoin? And if so could you describe their stance towards it?

Would like to understand the regulatory climate better, thank you.

eyci

Hi. Would like to know, will there be support for automated trading? Also, is there any place to view the historic trade data? Thanks.

This just appeared on reddit:


http://www.reddit.com/r/Bitcoin/comments/1b8gir/strongcoin_account_hackedcleaned_out/

One thing to bear in mind perhaps is that in the long run the block reward goes to zero and miners only receive income from transaction fees. The block rewards they receive now can be seen as a means to bootstrap the entire system by providing incentive to develop the infrastructure.

Cross-posted this in the Multibit forum.

https://bitcointalk.org/index.php?topic=159345.0

I'm cross-posting from the newbie forum, please help this guy if you can.

rJa6Y9VvHiv4yWAesV17oefk4EJcyA7LDF

I think it's worth noting that Bitcoin is not proprietary technology so notions of competition may not fully apply. Its stakeholders are all the people who are interested in a free currency - so if someone comes up with a significantly better solution, we should have no problem shifting to that.

If Bitcoin develops in such a way that it retains its decentralized nature and its technical integrity, I'm not sure I see the advantage in having a diverse set of crypto-currencies - but I'm happy to be proven wrong.

Coins are not directly represented in the system - instead what is stored is the chain of transactions beginning from newly mined coins up until the present, so yes in a sense this transaction record (blockchain) goes on indefinitely, and from this your wallet balance is determined. Currently the blockchain is about 4.5 GB and growing. You can see a lot of statistics at blockchain.info.

I don't mine myself but there are some mining profitability calculators on the net, e.g.

http://www.bitcoinx.com/profit/

Bought my first coins there about a week ago, real smooth and no problems.

Hi everyone I'm a new user here, very interested in the potential of Bitcoin, and eager to see it succeed.

I'm curious about all aspects of Bitcoin security, and I was trying to figure out the cost of owning 50% of the network hashrate. I found some rough calculations by others online, but was not very satisfied, so I made some calculations of my own and I would like to share it with you.

The "cost of 50% ownership" is defined here as the cost C of buying N number of mining devices where N is the existing number of devices in the network. The idea is that, with time, N reaches an equilibrium level that is dependent on the total miner profit, and the minimum ROI that miners are prepared to accept. By making assumptions about these quantities, we can have a theoretical estimate of what C would be.

The graph below plots [C / BTC market cap] vs. [Average TX fee per BTC], the model being that C is proportional to both the market cap and the tx fees.

http://i.imgur.com/LeNa4mTl.png


In terms of interpreting the graph (disregarding accuracy concerns for now) we see that in order for the cost C to be 10% of the market cap (22 million out of 220 million USD today), transaction fees need to be about 1.5% on average.  In contrast, if transaction fees are 0.02 percent (roughly the level today), then the cost is 0.15% of the market cap (330k USD today).

The calculation details are as follows -

-------------------------
Scenario assumptions:
1a. State-of-the-art mining hardware is accessible and is used by all miners.
1b. Miner income from block reward is negligible compared to transaction fees (true in long term)
1c. There exists an equilibrium in the amount of time taken for a mining device to break even on its fixed cost. At any level below this equilibrium, more miners will enter the market, and any higher, miners will leave. 

Three values used in the calculation, which are somewhat arbitrary and open to dispute:
2a. Equilibrium time for miners to break even (BE): EQ_BE_TIME = 12 months.
This in practice is determined by the market and depends on the mining risk profile. I am just guessing a value here.

2b. Electricity-to-Hardware cost ratio: ELE_COST_RATIO = 0.35
This is (electricity cost of operating 1 device for duration EQ_BE_TIME) / (cost of 1 device), and I have estimated this using the Avalon ASIC data from https://en.bitcoin.it/wiki/Mining_hardware_comparison:
ELE_COST_RATIO = 0.12 (USD per kWh) * 0.4 (kW for ASIC device) * 8640 (hours per year) / 1200 (cost of device) = 0.35

2c. Daily transaction volume ratio: DAILY_TX_RATIO = 0.025.
This is the ratio of transaction volume per day / number of coins in circulation, and I estimated this from http://blockchain.info/charts/estimated-transaction-volume.

The equilibrium number N of mining devices in the network is related to the above three values as follows:

(TX_FEE_RATIO * DAILY_TX_RATIO * MARKET_CAP) * EQ_BE_TIME * 30 / N = DEVICE_COST * (1 + ELE_COST_RATIO)

where TX_FEE_RATIO is the average transaction fee per BTC, MARKET_CAP is the total BTC capitalization, and DEVICE_COST is the cost of 1 mining device.

The total value of all mining hardware in the network, C, relative to the MARKET_CAP, is

N*DEVICE_COST/MARKET_CAP and this is a function of TX_FEE_RATIO, after fixing the other parameters as explained above.
------------------------


Comments and criticisms on the methodology / assumptions / values are all welcome.

eyci

Heya lilbit, nice to meet you

Hi everyone - just got into bitcoin and am very excited about its potential. Also looking forward to joining the main forums. Cheers all.

eyci