Bitcoin Forum
August 16, 2017, 01:24:59 PM *
News: ALL CLEAR: You can now use Bitcoin as you were previously. For more info, including how to claim your BCH (optional), see here.
 
   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 ... 1144 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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1950398 times)
tvbcof
Legendary
*
Offline Offline

Activity: 2226


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

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.


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

Posts: 1502889899

View Profile Personal Message (Offline)

Ignore
1502889899
Reply with quote  #2

1502889899
Report to moderator
1502889899
Hero Member
*
Offline Offline

Posts: 1502889899

View Profile Personal Message (Offline)

Ignore
1502889899
Reply with quote  #2

1502889899
Report to moderator
1502889899
Hero Member
*
Offline Offline

Posts: 1502889899

View Profile Personal Message (Offline)

Ignore
1502889899
Reply with quote  #2

1502889899
Report to moderator
lunarboy
Hero Member
*****
Offline Offline

Activity: 544



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


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: 1512



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


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: 2338



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

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: 2226


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


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: 2226


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

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: 2338



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

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
 #23868


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
 #23869


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: 2226


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


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: 2338



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


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: 2226


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


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
 #23873


 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: 1190


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

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: 557


@PlainTech & @BitSeeds on Twitter


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


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
Legendary
*
Offline Offline

Activity: 966



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


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.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 08:53:09 AM
 #23877

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.

And destroy the use value and network effects of having millions of people transacting in Bitcoin, thus destroying your investment and store-of-value too.

Kudos.  Roll Eyes

P.S. I come back here to see if there are any serious (not useless noise) posts and the only one is from smooth. What else is new. Why he and I aren't working together is still a mystery to me.

tvbcof
Legendary
*
Offline Offline

Activity: 2226


View Profile
May 11, 2015, 08:56:54 AM
 #23878


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

I like to practice what I preach I suppose.


tvbcof
Legendary
*
Offline Offline

Activity: 2226


View Profile
May 11, 2015, 09:08:00 AM
 #23879

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.

And destroy the use value and network effects of having millions of people transacting in Bitcoin, thus destroying your investment and store-of-value too.

Kudos.  Roll Eyes

P.S. I come back here to see if there are any serious (not useless noise) posts and the only one is from smooth. What else is new. Why he and I aren't working together is still a mystery to me.

The value of the 'network effect' peaked some time time ago an it is now a distinct negative and a distinct threat to the system in my opinion.  By now everyone who can make legitimate use of the system has heard about it.  Most of the new-users are of the class who have no real chance of protecting themselves (even less than the historic dismal record that the userbase has demonstrated) and will thus induce even more nanny-systems to lend them a hand.  These are inevitably bad for Bitcoin in a variety of ways (the most common one being that they are scams and/or even worse that the mainstream banking system in multiple important ways.)

Bitcoin will not really fill it's potential until sidechains are up-and-running.  I just hope it lasts that long before it is destroyed from within.  If so something else and probably something much better will take it's place though it would probably set certain things back by a few years.  I hope(d) it would be Bitcoin since I still sit on a fair number of them and it would make my life easier.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 11, 2015, 10:48:36 AM
 #23880

Okay I guess you convinced me.  Cool

Mea culpa.

Pages: « 1 ... 1144 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 ... 1558 »
  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!