Bitcoin Forum
March 28, 2024, 07:45:58 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
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 ... 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 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 ... 1557 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2032126 times)
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
May 07, 2015, 05:52:12 AM
 #23501

given what has happened to Ripple today, i am forced to haul out one of my old time memes which i have now taken up to 70% probability in my own mind:

"The blockchain may only ever be applicable to Bitcoin as Money".


I'd put it this way: "We will know if the blockchain is applicable to more than money only when Bitcoin is well established as money".

that is not bad.  not bad at all.  how about this:

"We will know if the blockchain is applicable to more than money only when after Bitcoin is well established as money".-majamalu

in other words:

the blockchain - money and maybe more

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

Posts: 1711655158

View Profile Personal Message (Offline)

Ignore
1711655158
Reply with quote  #2

1711655158
Report to moderator
1711655158
Hero Member
*
Offline Offline

Posts: 1711655158

View Profile Personal Message (Offline)

Ignore
1711655158
Reply with quote  #2

1711655158
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711655158
Hero Member
*
Offline Offline

Posts: 1711655158

View Profile Personal Message (Offline)

Ignore
1711655158
Reply with quote  #2

1711655158
Report to moderator
1711655158
Hero Member
*
Offline Offline

Posts: 1711655158

View Profile Personal Message (Offline)

Ignore
1711655158
Reply with quote  #2

1711655158
Report to moderator
1711655158
Hero Member
*
Offline Offline

Posts: 1711655158

View Profile Personal Message (Offline)

Ignore
1711655158
Reply with quote  #2

1711655158
Report to moderator
hdbuck
Legendary
*
Offline Offline

Activity: 1260
Merit: 1002



View Profile
May 07, 2015, 06:45:08 AM
 #23502

<quote> Contrary to what the public may think, there is no consensus amongst the developers regarding Gavin Andresen’s proposal to increase the block size to 20mb (Thanks to Peter Todd who brought this up during his Bitdevs NYC talk which I attended).

The only devs that have come out in strong favor of this proposal is Gavin and Mike Hearn.

Skeptics of 20mb increase (Note that some people here do favor a block size increase, but none has strongly committed to 20 megabytes as the exact size nor its timing.)

Pieter Wuille
Current Affiliations: Blockstream
Bitcoin core: top 5 core developer by # of commits. Has commit access.
Comments: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07466.html

Gregory Maxwell
Current Affiliations: Blockstream
Bitcoin core: top 20 core developer by # of commits. Has commit access.
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090559/
https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqycy4h

Jeff Garzik
Current Affiliations: BitPay
Commit access: top 20 core developer by # of commits. Has commit access.
Comments: https://twitter.com/anjiecast/status/595610865979629568
http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html

Matt Corallo
Current Affiliations: Blockstream
Bitcoin Core : top 10 core developer by # of commits
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090292/

Peter Todd
Current Affiliations: Viacoin,Dark Wallet, Coinkite, Smartwallet, Bitt
Bitcoin Core: top 20 core developer by # of commits
Comments: https://www.reddit.com/r/Bitcoin/comments/34y9ws/it_must_be_done_but_is_not_a_panacea/cqza6rq?context=3
https://www.youtube.com/watch?v=lNL1a7aKThs

Luke Dashjr
Current Affiliations: Eligius Mining Pool
Bitcoin Core: top 10 core developer by # of commits
Comments: http://www.reddit.com/r/Bitcoin/comments/34y48z/mike_hearn_the_capacity_cliff_and_why_we_cant_use/cqzadpn

Bryan Bishop
Current Affiliations: LedgerX
Bitcoin Core: various @ https://github.com/kanzure
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090516/



https://www.reddit.com/r/Bitcoin/comments/354qbm/bitcoin_devs_do_not_have_consensus_on_blocksize/
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 07:03:52 AM
 #23503

<quote> Contrary to what the public may think, there is no consensus amongst the developers regarding Gavin Andresen’s proposal to increase the block size to 20mb (Thanks to Peter Todd who brought this up during his Bitdevs NYC talk which I attended).

The only devs that have come out in strong favor of this proposal is Gavin and Mike Hearn.

Skeptics of 20mb increase (Note that some people here do favor a block size increase, but none has strongly committed to 20 megabytes as the exact size nor its timing.)

Pieter Wuille
Current Affiliations: Blockstream
Bitcoin core: top 5 core developer by # of commits. Has commit access.
Comments: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07466.html

Gregory Maxwell
Current Affiliations: Blockstream
Bitcoin core: top 20 core developer by # of commits. Has commit access.
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090559/
https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqycy4h

Jeff Garzik
Current Affiliations: BitPay
Commit access: top 20 core developer by # of commits. Has commit access.
Comments: https://twitter.com/anjiecast/status/595610865979629568
http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html

Matt Corallo
Current Affiliations: Blockstream
Bitcoin Core : top 10 core developer by # of commits
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090292/

Peter Todd
Current Affiliations: Viacoin,Dark Wallet, Coinkite, Smartwallet, Bitt
Bitcoin Core: top 20 core developer by # of commits
Comments: https://www.reddit.com/r/Bitcoin/comments/34y9ws/it_must_be_done_but_is_not_a_panacea/cqza6rq?context=3
https://www.youtube.com/watch?v=lNL1a7aKThs

Luke Dashjr
Current Affiliations: Eligius Mining Pool
Bitcoin Core: top 10 core developer by # of commits
Comments: http://www.reddit.com/r/Bitcoin/comments/34y48z/mike_hearn_the_capacity_cliff_and_why_we_cant_use/cqzadpn

Bryan Bishop
Current Affiliations: LedgerX
Bitcoin Core: various @ https://github.com/kanzure
Comments: http://sourceforge.net/p/bitcoin/mailman/message/34090516/



https://www.reddit.com/r/Bitcoin/comments/354qbm/bitcoin_devs_do_not_have_consensus_on_blocksize/

yep, all the Blockstream devs spreading their FUD.  and i'm in the thick of it.
bambou
Sr. Member
****
Offline Offline

Activity: 346
Merit: 250


View Profile
May 07, 2015, 07:12:15 AM
 #23504

Gavin is spreading MIT/USG FUD.
why the hurry?
Especially when there is no consensus?

Bitcoin is certainly not going to dissapear anyway.. THAT is HIS FUD.

Non inultus premor
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1197



View Profile
May 07, 2015, 07:15:29 AM
 #23505

With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?

Yes it is called replace by fee

I'm not sure. With replace by fee, you can change other things in the transactions (like outputs), no? This makes double-spending much easier. I'm not sure wether "increase fee" can even be done, since it also requires changes to the outputs (and maybe inputs).

I see replace-by-fee as a very bad idea currently.

First off, I think it's inevitable, as there is nothing that would make a miner want to not accept a higher fee.

That said, you can make a restricted version that doesn't allow reducing any outputs. You would have to add an additional input to pay the higher fee.

rocks
Legendary
*
Offline Offline

Activity: 1153
Merit: 1000


View Profile
May 07, 2015, 07:24:36 AM
 #23506

With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?

Yes it is called replace by fee

I'm not sure. With replace by fee, you can change other things in the transactions (like outputs), no? This makes double-spending much easier. I'm not sure wether "increase fee" can even be done, since it also requires changes to the outputs (and maybe inputs).

I see replace-by-fee as a very bad idea currently.

First off, I think it's inevitable, as there is nothing that would make a miner want to not accept a higher fee.

That said, you can make a restricted version that doesn't allow reducing any outputs. You would have to add an additional input to pay the higher fee.

Anything that reduces any of the outputs of a transaction already broadcast through the network is by definition a double spend. This would essentially invalidate instant acknowledgement by the P2P network, and force everyone to wait for a block confirmation, crippling many services in the process.

To increase the fee, you have to either reduce an output or add an input. Reducing an output is not an option, so you'd have to add an input, which at that point is essentially a new transaction replacing the earlier. That is a big change from today's bitcoin IMHO.
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 07:26:54 AM
 #23507

Gavin is spreading MIT/USG FUD.
why the hurry?
Especially when there is no consensus?

Bitcoin is certainly not going to dissapear anyway.. THAT is HIS FUD.

how about this?

pwuillie, gmax, luke, and corrallo are spreading Blockstream SC FUD.  what, they don't care if the protocol breaks at 1MB full blocks coming soon?  what a bunch of communists.
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 07:31:05 AM
 #23508

interestingly, we're getting some whiffs of deflation in the futures markets tonite.  the invisible hand has about 6h to reverse this or there are going to be fireworks tomorrow.  get out the popcorn.
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1197



View Profile
May 07, 2015, 07:38:42 AM
Last edit: May 07, 2015, 07:58:08 AM by smooth
 #23509

With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?

Yes it is called replace by fee

I'm not sure. With replace by fee, you can change other things in the transactions (like outputs), no? This makes double-spending much easier. I'm not sure wether "increase fee" can even be done, since it also requires changes to the outputs (and maybe inputs).

I see replace-by-fee as a very bad idea currently.

First off, I think it's inevitable, as there is nothing that would make a miner want to not accept a higher fee.

That said, you can make a restricted version that doesn't allow reducing any outputs. You would have to add an additional input to pay the higher fee.

Anything that reduces any of the outputs of a transaction already broadcast through the network is by definition a double spend. This would essentially invalidate instant acknowledgement by the P2P network, and force everyone to wait for a block confirmation, crippling many services in the process.

To increase the fee, you have to either reduce an output or add an input. Reducing an output is not an option, so you'd have to add an input, which at that point is essentially a new transaction replacing the earlier. That is a big change from today's bitcoin IMHO.

The version that that only allows adding additional outputs (and therefore inputs) has already been discussed for years and maybe implemented. So it is certainly possible (the original question).

Another possible approach is child-pays-for-parent. In this case you respend your change with a higher fee. The fee credit counts toward the entire tx chain, causing the parent be mined faster.

As I said before though, I consider all of these inevitable as mining continues to become more competitive (especially after 1+ more block halving). If you are relying on zero confirm transactions, you better have a plan for what you're going to do when they break.
Erdogan
Legendary
*
Offline Offline

Activity: 1512
Merit: 1005



View Profile
May 07, 2015, 07:48:59 AM
 #23510

With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?

Yes it is called replace by fee

A two year old discussion that went past me Smiley. So it is not obviously advantageous.

Erdogan
Legendary
*
Offline Offline

Activity: 1512
Merit: 1005



View Profile
May 07, 2015, 11:42:53 AM
 #23511

In todays reddit discussions, someone (Raystonn) promised to create a 20 MB "unfriendly" fork. Good idea I think, but, I might change it again and run an unlimited fork.

What would happen? If no increase is advised, it will  work as normal. If a larger block arrives, I would follow that, and if orphaned, I will revert. No hassle for me, I am not that dependent on being on the prime fork at any specific time. If a larger than 20 MB block arrives, I can handle that the same way.

If more people think like this, we could end up with unlimited size from gavins cutoff date.

cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 02:28:48 PM
 #23512

In todays reddit discussions, someone (Raystonn) promised to create a 20 MB "unfriendly" fork. Good idea I think, but, I might change it again and run an unlimited fork.

What would happen? If no increase is advised, it will  work as normal. If a larger block arrives, I would follow that, and if orphaned, I will revert. No hassle for me, I am not that dependent on being on the prime fork at any specific time. If a larger than 20 MB block arrives, I can handle that the same way.

If more people think like this, we could end up with unlimited size from gavins cutoff date.



yeah, that is a revealing thread.  Raystonn is angry and i don't blame him.

the devs, all Blockstream except for Todd (who has for years been at odds with Gavin & just about every other core dev until now), are wanting to let the 1MB ceiling be hit to force up tx fees. as discussed here, i think that is a bad idea in that the Bitcoin user base is still tiny and immature.  this inconvenience and breakage of Bitcoin likely will cause even dedicated users, like Raystonn, to abandon Bitcoin for another altcoin as well as prevent any new users from adopting.  the key thing here is that none of the alternatives that they're suggesting are even close to primetime; SC's, Lightning, payment channels.  thus, they offer no immediately viable alternatives.

also, they're constructing a boogie man scenario whereby large miners might collude to fabricate spam-like "large" blocks that cause smaller miners to struggle processing it thus potentially driving them out of business.  i think that makes no sense at all.  in an open system such as we have, a miner doing this will be immediately detected.  if it's IP can be identified and the process itself causes any problem at all (debatable), that miner can be sealed off from the network if necessary.  but more fundamentally, i say they won't try that, at least on the consistently needed basis required to drive out competitors.  it's too risky and they stand to lose a ton of money trying this.  not only from detection but a game theoretic basis.  i foresee miners continuously doing a look back of maybe 1000 blocks or so measuring the avg size of blocks coming thru the network.  they will try to stick close to that size and continue to make them as small as possible so that when solved they can be propagated thru the network as fast as possible to capture the reward.  remember, the real prize right now is capturing those 25BTC so that is priority #1.  large blocks are the antithesis of this goal as their large block can be orphaned by latency not to mention dicking around with constructing such a large cumbersome block.  and even if they happen to get one largish block thru, they would have to be able to sustain such an attack for quite a long time to drive any competitors out of business.  an attacking large pool like this has no idea of the financial condition of any of their smaller competitors such as capitalization, access to ultra low electricity, business acumen of founders, and overall technical ability to counteract such a stupid attack.  a large pool miner will instead continue to take the honest route in constructing avg size blocks to go after the reward.  if they're 30% of the network, they know with certainty they will make 30% of the block rewards plus tx fees.  that is calculable and known and most importanty the safe thing to do.  attacking smaller miners, whom they know nothing about, is foolish and extraordinarily risky and most likely will fail and result in their own bankruptcy.

all the objections that i'm hearing from these guys are mostly political and economic, areas which i do not have confidence that they understand.  not to mention that almost all of them have an economic conflict of interest.
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
May 07, 2015, 02:33:55 PM
 #23513

I'd like to know who is behind several of the sock puppet accounts on Reddit who are participating on the discussion.

Over the last year or so I've noticed some distinctive writing characteristics appear in threads about a few specific topics, and the distinctive characteristics are spread across multiple Reddit accounts.

Sometimes they accidentally give themselves away by using that distinctive style and then delete the post.

Fortunately I've taken to performing lots of screenshots so I catch most of them before they get deleted.
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 02:38:50 PM
 #23514

the Blockstream devs seem to forget that pools consist of individual users who are willing to aggregate their hashing power together to the pool operator.  any operator who abuses that privilege will get shafted; just look at how ghash has been punished down to a mere 3% of the network despite what guys like gmax have been raving about for years.  attempting what i think is a stupid technical attack of bloated blocks makes no sense as it would be quite costly and risky.  no, gvts won't walk in the doors of several of these pool and force them to conduct this attack.  there already exists a legal basis for running mines which can be used by the operators to defend themselves from such blatant illegal collusion.  plus, most of the operators are dedicated Bitcoin believers who want to get their hands on as many BTC as fast as possible before the next 10x ramp just like their users.  they would more likely do a Ladar Levinson (Lavabit) that would embarrass any gvt as well as punish that same gvt thru legal action.  think back to the 0.8.1 fork where miners, lead by Eleuthria, did the ultimate to save the network.
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile
May 07, 2015, 02:39:01 PM
 #23515

Gloves starting to come off already. Suppose it was inevitable.

Definitely: http://sourceforge.net/p/bitcoin/mailman/message/34090292/


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 02:41:04 PM
 #23516

I'd like to know who is behind several of the sock puppet accounts on Reddit who are participating on the discussion.

Over the last year or so I've noticed some distinctive writing characteristics appear in threads about a few specific topics, and the distinctive characteristics are spread across multiple Reddit accounts.

Sometimes they accidentally give themselves away by using that distinctive style and then delete the post.

Fortunately I've taken to performing lots of screenshots so I catch most of them before they get deleted.

i'd like to know who is behind the "Bitcoin Expert" handle flair that you brought to my attention last night.  it's been brought out specifically for that one thread.  since theymos is apparently against the block size increase and runs /rBitcoin, it probably is him:

https://www.reddit.com/r/Bitcoin/comments/354qbm/bitcoin_devs_do_not_have_consensus_on_blocksize/
Bagatell
Hero Member
*****
Offline Offline

Activity: 722
Merit: 500



View Profile
May 07, 2015, 02:48:56 PM
 #23517

i'd like to know who is behind the "Bitcoin Expert" handle flair that you brought to my attention last night.  it's been brought out specifically for that one thread. 

First time I've seen it.
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 03:04:00 PM
 #23518

i'd like to know who is behind the "Bitcoin Expert" handle flair that you brought to my attention last night.  it's been brought out specifically for that one thread. 

First time I've seen it.

it's a shameful tactic.  right up theymo's alley.
_mr_e
Legendary
*
Offline Offline

Activity: 817
Merit: 1000



View Profile
May 07, 2015, 03:10:59 PM
 #23519

I love how they bombard me with propaganda:

http://www.reddit.com/r/Bitcoin/comments/354qbm/bitcoin_devs_do_not_have_consensus_on_blocksize/cr122wx
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
May 07, 2015, 03:17:12 PM
 #23520


everyone who disagrees within that thread gets bombarded.  that thread is a coordinated planned event.
Pages: « 1 ... 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 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 ... 1557 »
  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!