Bitcoin Forum
December 06, 2016, 02:01:03 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 [1195] 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1805056 times)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 05:50:56 AM
 #23881

...

Grandma and moma aren't you. And that is entire point of this drive to push Paypal, Circle, Coinbase, etc onto the masses.

If you are arguing the masses will have the slightest clue that they need to move their wallet because of some obscure Digital Kill Switch that doesn't affect them, then you are disingenuous and absurd.

So let's assume for a moment you have a functioning brain and you're right that the gvt teams up with all the banks and retail companies all within a giant cabal and the masses all are in Bitcoin.

They hit the dreaded Digital Kill Switch. What happens then?

Dissidents and competitors are targeted and eliminated (Digital Kill Switch one of the important tools of discipline on anyone who doesn't conform). The masses huddle into the NWO one world reserve currency and Global Technocracy fascist economy.

1984.

It is a slow burn eugenics paradigm to achieve Ted Turner's 500 million population goal.

1481032863
Hero Member
*
Offline Offline

Posts: 1481032863

View Profile Personal Message (Offline)

Ignore
1481032863
Reply with quote  #2

1481032863
Report to moderator
1481032863
Hero Member
*
Offline Offline

Posts: 1481032863

View Profile Personal Message (Offline)

Ignore
1481032863
Reply with quote  #2

1481032863
Report to moderator
1481032863
Hero Member
*
Offline Offline

Posts: 1481032863

View Profile Personal Message (Offline)

Ignore
1481032863
Reply with quote  #2

1481032863
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481032863
Hero Member
*
Offline Offline

Posts: 1481032863

View Profile Personal Message (Offline)

Ignore
1481032863
Reply with quote  #2

1481032863
Report to moderator
tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 11, 2015, 05:56:16 AM
 #23882


Quote
[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)

That addresses only a small symptom of the overall problem, i.e. the orphan rate.

It does nothing for the fact that UXTO won't scale with RAM.

Take them out of RAM.  Slow the whole system, and more importantly, use it as the slow system that it is.  Make quality (robustness) the over-arching goal over quantity and speed.  It will never be competitive in this role and will burn itself up trying...even with minimal assistance from those whom it threatens.

It does nothing for the Transactions Withholding attack, pool Sybil attack, and inefficacy of getblocktemplate-at-scale issues I've raised.

More time to cross-check and verify when the system is operating slowly.  More critically this slow rate expands and diversify the pool of potential operators which fosters decentralization into realms (virtual and otherwise) where it can really make a difference.

It can't help you scale to micropayments volume.

Even the most stary-eyed gave up on the micro-payment-on-native-bitcoin pipe dream a long time ago.  They are, however, one of the driving forces behind using Bitcoin in it's current proven form as a backing upon which target solutions such as micropayments can ride and thus become nearly a pure proxy.  (Sidechains of course.)


molecular
Donator
Legendary
*
Offline Offline

Activity: 2128



View Profile
May 11, 2015, 05:59:12 AM
 #23883

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 06:01:34 AM
 #23884


Quote
[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)

That addresses only a small symptom of the overall problem, i.e. the orphan rate.

It does nothing for the fact that UXTO won't scale with RAM.

Take them out of RAM.  Slow the whole system, and more importantly, use it as the slow system that it is.  Make quality (robustness) the over-arching goal over quantity and speed.  It will never be competitive in this role and will burn itself up trying...even with minimal assistance from those whom it threatens.

The tx rate doesn't slow down. You will need massively parallel disk arrays. Again centralization.

It does nothing for the Transactions Withholding attack, pool Sybil attack, and inefficacy of getblocktemplate-at-scale issues I've raised.

More time to cross-check and verify when the system is operating slowly.  More critically this slow rate expands and diversify the pool of potential operators which fosters decentralization into realms (virtual and otherwise) where it can really make a difference.

That doesn't make any sense. It doesn't change any factor that addresses those attacks.

It can't help you scale to micropayments volume.

Even the most stary-eyed gave up on the micro-payment-on-native-bitcoin pipe dream a long time ago.  They are, however, one of the driving forces behind using Bitcoin in it's current proven form as a backing upon which target solutions such as micropayments can ride and thus become nearly a pure proxy.  (Sidechains of course.)

Sidechains will have the same technical challenge.

What you are in effect doing is handing micropayments to Paypal, Coinbase, Circle, etc.. The cartel will control micropayments.

I have the solution. But nobody likes me because I am frank. Insanity prevails!

tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 11, 2015, 06:03:56 AM
 #23885

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.


lunarboy
Hero Member
*****
Offline Offline

Activity: 544



View Profile
May 11, 2015, 06:04:27 AM
 #23886


Quote
[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)



Wouldn't this dramatically weaken/dilute 1/10th  the hashing power? Surely this is playing with fire especially if there was not full consensus at the time of the hard fork? Conflicts more likely won by the 10minute block side Huh

Also it seems to fundamentally change the incentive structure.... what's left after that? just increase the amount of coins to 42 million?  /rhetoric
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
May 11, 2015, 06:15:27 AM
 #23887


Quote
[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)



Wouldn't this dramatically weaken/dilute 1/10th  the hashing power? Surely this is playing with fire especially if there was not full consensus at the time of the hard fork? Conflicts more likely won by the 10minute block side Huh

Also it seems to fundamentally change the incentive structure.... what's left after that? just increase the amount of coins to 42 million?  /rhetoric

It doesn't change the incentive structure at all as long as the block rewards are scaled accordingly. It would still be 25 BTC every 10 minutes (currently), just broken up into 2.5 BTC pieces.

I'm not in favor and frankly it makes me start to question Gavin's motives, which I didn't with respect to just the larger block size. This adds another bit of evidence supporting the case that he is actively supporting centralization, or is being heavily influenced by those in favor of centralization and doesn't care or isn't able to resist that influence.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2128



View Profile
May 11, 2015, 06:17:19 AM
 #23888

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.



He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 11, 2015, 06:26:54 AM
 #23889


Quote
[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

I'm in favor of changing it.  About 16 block per day would be about right as far as I'm concerned.  Bitcoin never was a real-time system and real-time behavior when needed is best done for real in a proxy (e.g., a bitcoin-backed sidechain designed for such use-cases.)



Wouldn't this dramatically weaken/dilute 1/10th  the hashing power? Surely this is playing with fire especially if there was not full consensus at the time of the hard fork? Conflicts more likely won by the 10minute block side Huh

Also it seems to fundamentally change the incentive structure.... what's left after that? just increase the amount of coins to 42 million?  /rhetoric

I was half joking...and half not...I wish the system had been designed such that one could anticipate a solid result in about a day although it is true that it would have killed some early marketing potential (for the bogus idea that Bitcoin is a suitable exchange currency) and Bitcoin probably would have withered on the vine near the beginning of it's life.

At this point in time I favor just sticking to the 10 min frequency.  I would note, however, that the difference between a real real-time system and the 10 minute batch cycle approaches infinity.  The difference between a 10 second human patience time and the 10 min block frequency time is a factor of 60, and that does not include the multiple block confirmations cycles which can and at some point probably will be needed for a solid result.  The factor between my 90 minute proposal and the current 10 minute cycle is 9.  That is my point about Bitcoin being far from a real-time system.  The two options are to try to shoe-horn it into being one which is fraught with danger and risk, or using it as something closer to what it is naively.

As for the circulation and inflation rate rhetoric, I think most people took it as implicit that these factors would not change under either a slower or faster cycle time for an offsetting adjustment.


tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 11, 2015, 06:32:58 AM
 #23890

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.



He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.


molecular
Donator
Legendary
*
Offline Offline

Activity: 2128



View Profile
May 11, 2015, 06:37:09 AM
 #23891

An attack I thought of years ago would be to formulate UTXO's systematically to chain blocks together in such a way that 1) their count would stress the working database (currently implemented in RAM most often) and 2) verifying them would touch as many blocks as possible making rendering of much of the actual blockchain itself require for many transactions.  I'm sure there is a name for such an attack.  If not, call it the 'tvbcof attack' I suppose.

Mining a block with such a tx is disincentivized by its long block propagation time (and hence higher orphan risk). Miners could evaluate tx verification time before inclusion and compare to fee.

How does a miner distinguish between a natural transaction which has this (presumed by me) detrimental characteristic by chance and one which was designed for the purpose of being disruptive?  If they treat all disruptive transactions as attackers (assuming miners really give enough of a shit to try due to orphan problems or otherwise) they are likely to piss off a fair number of people it seems to me.



He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.



We obviously have differing usage patterns. I made 62 transactions so far this year (in the main trezor wallet alone, not counting paying for pizza with mycelium)


PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
lunarboy
Hero Member
*****
Offline Offline

Activity: 544



View Profile
May 11, 2015, 06:43:08 AM
 #23892


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.



Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 11, 2015, 06:45:34 AM
 #23893


Quote
[–]gavinandresenGavin Andresen - Bitcoin Expert

I think 1-minute blocks is a good idea. The best time to roll that out would be the next subsidy halving (makes the code much simpler).

We still need a bigger max block size, though.

   reddit

Just to throw the cat amongst the pigeons, how about changing the block interval?

This is an interesting idea. I can see the benefits but not sure about the block orphaning implications.

I have kicked off a poll!
https://bitcointalk.org/index.php?topic=1057423.msg11343627#msg11343627

tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 11, 2015, 06:47:28 AM
 #23894


He doesn't. He just requires a higher fee for inclusion to make up for the risk of a slower propagation.

In the end it's up to the wallet to assign a higher fee.

This is not up to us to decide anyways. Miners can and probably will or are already doing this or something similar.


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.


We obviously have differing usage patterns. I made 62 transactions so far this year (in the main trezor wallet alone, not counting paying for pizza with mycelium)


I'll look forward to joining you and hopefully eclipsing your profligate spending as soon as I can do so on a variety of sidechains and thus not stress what I consider to be a monumental achievement.


molecular
Donator
Legendary
*
Offline Offline

Activity: 2128



View Profile
May 11, 2015, 06:47:52 AM
 #23895


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.



Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do


One the one hand, yes: his blog post has instilled a sense of urgency and importance in me and I'm still for the 20 MB block size increase. On the other hand a part in me (a destructive part of my personality, I guess) wants to see what would actually happen and how bad things would crash and burn... the user/media reaction and all. It'd be exciting to watch, I'm sure and we could probably scoop up many more cheap coins.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
tvbcof
Legendary
*
Offline Offline

Activity: 1974


View Profile
May 11, 2015, 07:08:56 AM
 #23896


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.


Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do


I anticipated and commented on it years ago in a thread including Mike IIRC.  My solution at the time was as it is now.  Heavily advertise the fact that in almost any sort of a failure mode no actual value is at risk with the possible exception of a few corner-case transactions for a few people who have bad luck.  One's Bitcoin is as safe as one's ability to maintain control of their signing key (which is dubious in way to many cases.)  But that is only if people are using Bitcoin in a certain way...namely as a high-powered solution to be used with caution for critical things.

The route which was taken was exactly the opposite.  That is, steer the herd to a mentality that Bitcoin is a drop-in replacement for every exchange currency and super secure and convenient and generally a panacea which will elevate all human problems.  Now all of a sudden the earth is going to collapse if people people are inconvenienced for a little while and Bitcoin does not perform to it's absurd marketed specs.  If we have a real problem of any sort when the transaction rate approaches any particular maximum then there is no excuse and

 - Dev was completely remiss in addressing real problems...and I've been chagrined at Gavin for a long time for focusing on new GUI's and other 'talking-paperclip' bullshit at the expense of core improvements.  Enough to kill any incentive I may or may not have had to do anything productive toward the solution at all.

 - Almost everyone else involved can be held to fault for false advertising.

---

Since I took the day off and spent most of it on bitcointalk I did run across Maxwell's critique of Mikes article on the tech board.  It's worth a skim and should be active on that board and not terribly difficult to find for anyone who is interested.


lunarboy
Hero Member
*****
Offline Offline

Activity: 544



View Profile
May 11, 2015, 07:22:41 AM
 #23897


 That is, steer the herd to a mentality that Bitcoin is a drop-in replacement for every exchange currency and super secure and convenient and generally a panacea which will elevate all human problems.  
---


you make it sound like convincing the whole world of something is easy Huh  if that were the case we'd all be doing it already.

 Why limit the possibilities and use cases of the protocol?


Since I took the day off and spent most of it on bitcointalk I did run across Maxwell's critique of Mikes article on the tech board.  It's worth a skim and should be active on that board and not terribly difficult to find for anyone who is interested.


i'll have a read
sickpig
Legendary
*
Offline Offline

Activity: 1106


View Profile
May 11, 2015, 07:33:02 AM
 #23898

can one of you tech guys comment on Peter Todds claim that there was an entire book embedded in the BC a month ago?  how is it done?

https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqystoo?context=3

As Odalv already said tx size can be really big. If you go over the 100KB a transaction
is considered non-standard though, see: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L603-L611
and  https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L55-L56

Code:
   // Extremely large transactions with lots of inputs can cost the network
    // almost as much to process as they cost the sender in fees, because
    // computing signature hashes is O(ninputs*txsize). Limiting transactions
    // to MAX_STANDARD_TX_SIZE mitigates CPU exhaustion attacks.
    unsigned int sz = tx.GetSerializeSize(SER_NETWORK, CTransaction::CURRENT_VERSION);
    if (sz >= MAX_STANDARD_TX_SIZE) {
        reason = "tx-size";
        return false;
    }

Code:
/** The maximum size for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_SIZE = 100000;

That said as long as you find a miner/poll that accept to include your tx
in the next block you're golden.

As soon as I have time I'll look for the actual txs that Peter Todd was referring to.


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
worth
Hero Member
*****
Offline Offline

Activity: 556


@PlainTech & @BitSeeds on Twitter


View Profile WWW
May 11, 2015, 08:00:21 AM
 #23899


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.



Trying to figure out why you would do this, even if you apparently almost never use Bitcoin.  Huh

jeezy
Hero Member
*****
Offline Offline

Activity: 728


View Profile
May 11, 2015, 08:09:58 AM
 #23900


Sounds good to me.  I would like to see the fee be around the equivalent of $10 per transaction.  That is about what I set my client to pay and it's worth every penny to me.  In a busy year I may do 10 native transactions or so.  In a dry one (like 2015 so far) the number of transactions I perform drops to zero.



Mike Hearns blogs post finally convinced me this was not such good idea.  Crash landing

What not to do


One the one hand, yes: his blog post has instilled a sense of urgency and importance in me and I'm still for the 20 MB block size increase. On the other hand a part in me (a destructive part of my personality, I guess) wants to see what would actually happen and how bad things would crash and burn... the user/media reaction and all. It'd be exciting to watch, I'm sure and we could probably scoop up many more cheap coins.

Pages: « 1 ... 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 [1195] 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 ... 1560 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!