Bitcoin Forum
November 20, 2017, 07:16:43 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   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 ... 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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2010264 times)
NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
May 06, 2015, 07:10:15 PM
 #23501

Added some diagrams which should greatly enhance understanding of the protocol:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

Those sexy diagrams are a helpful addition.

I've always enjoyed the ongoing romance of Alice and Bob.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
1511205403
Hero Member
*
Offline Offline

Posts: 1511205403

View Profile Personal Message (Offline)

Ignore
1511205403
Reply with quote  #2

1511205403
Report to moderator
1511205403
Hero Member
*
Offline Offline

Posts: 1511205403

View Profile Personal Message (Offline)

Ignore
1511205403
Reply with quote  #2

1511205403
Report to moderator
1511205403
Hero Member
*
Offline Offline

Posts: 1511205403

View Profile Personal Message (Offline)

Ignore
1511205403
Reply with quote  #2

1511205403
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511205403
Hero Member
*
Offline Offline

Posts: 1511205403

View Profile Personal Message (Offline)

Ignore
1511205403
Reply with quote  #2

1511205403
Report to moderator
1511205403
Hero Member
*
Offline Offline

Posts: 1511205403

View Profile Personal Message (Offline)

Ignore
1511205403
Reply with quote  #2

1511205403
Report to moderator
Patel
Legendary
*
Offline Offline

Activity: 1279



View Profile WWW
May 06, 2015, 07:12:29 PM
 #23502

big, big trouble:



been waiting for this since 09
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
May 06, 2015, 07:33:40 PM
 #23503

Added some diagrams which should greatly enhance understanding of the protocol:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

Those sexy diagrams are a helpful addition.

I've always enjoyed the ongoing romance of Alice and Bob.

They have a true romance, but Eve is always trying to spoil it.

justusranvier, thanks for sharing and explaining this work in this thread
Livermore
Newbie
*
Offline Offline

Activity: 20

History repeats


View Profile
May 06, 2015, 08:02:40 PM
 #23504


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

 I don't see any bearish signs yet. 200day EMA (white) still rising and price is above it. It has served as big big support 5 times.

However I do agree with your DXY bearish. Time for correction.

Oct2015 starts the 4th bubble. -May2014 prediction
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 06, 2015, 08:10:45 PM
 #23505

big, big trouble:





 I don't see any bearish signs yet. 200day EMA (white) still rising and price is above it. It has served as big big support 5 times.

However I do agree with your DXY bearish. Time for correction.


last minute stick save $DJT +12.9.  still concerning.  we're very close.

we all have our indicators, methods with which to analyze the markets.  i like Dow Theory and cycle analysis so we'll see.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 06, 2015, 10:11:07 PM
 #23506

I'm trying to find out if this is different to the last gavin update, where the rolling increase was proposed 20mb first and X% per increment after. Or if this new proposal is a different hacked increase to 20mb, thus requiring another hard fork in the future should this new limit need changing?
thanks

The new proposal is similar to Satoshi's original 2010 example where the max block size increases after a predetermined block height (115,000).
Instead, Gavin has code allowing a one-off increase, blocks up to 20MB which are later than a predetermined timestamp (1st March 2016 00:00:00 UTC). Block timestamps can only vary +/- a couple of hours from UTC. The advantage is that everyone will know the date by which they need to have their full node upgraded. Working with block height means that the cut-over could vary, a couple of weeks earlier or later, depending on difficulty changes.

Hopefully, this will get unanimous consensus in core dev (the 5 people with commit access) so that there is not a split. In theory Gavin could commit this change and someone else reverse it in an "edit war". That would be a sad situation. However, Gavin has a trump card which means he *should* be able to prevail even if he were to be in a minority of 4:1 against. Satoshi gave him the key to broadcast alerts to all the instances of BitcoinCore. So, he could fork the code and create, say "Bitcoin20", and advise all BitcoinCore users that they need to upgrade to Bitcoin20 (or BitcoinXT). I really hope it does not come to that.

He has consulted many stakeholders and indications are that major miners, exchanges, wallet providers, 3rd party services, and BitcoinXT will be on-board with the change. Those that want to see how 1MB affects fees might get their wish, because March 2016 is a fair way off and there may be long periods of nearly-full 1MB blocks. The resulting problems for ordinary users will create an avalanche of demand for the 20MB change, or Bitcoin20, if that is what it takes.

It is worth repeating: just because the max block size increases does not mean the blocks immediately get bigger. The 1st 20MB block may be 5 years away.

edit: the last point about future limit changes. Yes, other hard-forks may be necessary, however, 20MB is large enough that it buys time for alternative scaling methods to be fully developed and implemented, such as the Lightning Networks.

sickpig
Legendary
*
Offline Offline

Activity: 1218


View Profile
May 06, 2015, 10:32:30 PM
 #23507

Matt Corallo, Blockstream co-founder, just sent an email with the subject "Block Size Increase" on btc dev mailing list , you could read it all here:

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

quoting the relevant part:

Quote from: Matt Corallo on btc dev mailing list
Personally, I'm rather strongly against any commitment to a block size
increase in the near future
. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full. What we see today are
transactions enjoying next-block confirmations with nearly zero pressure
to include any fee at all (though many do because it makes wallet code
simpler).

bold is mine

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

Activity: 1078


100 satoshis -> ISO code


View Profile
May 06, 2015, 11:22:10 PM
 #23508

Matt Corallo, Blockstream co-founder, just sent an email with the subject "Block Size Increase" on btc dev mailing list , you could read it all here:

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

quoting the relevant part:

Quote from: Matt Corallo on btc dev mailing list
Personally, I'm rather strongly against any commitment to a block size
increase in the near future
. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full. What we see today are
transactions enjoying next-block confirmations with nearly zero pressure
to include any fee at all (though many do because it makes wallet code
simpler).

bold is mine

This is an example of what I was saying yesterday about core dev being too focused on the tech to see the big picture.
Matt suggests using the 1MB to apply upwards fee pressure. This is using a bit of software for something for which it was not intended. It is like using a hammer to fix a car engine. Mike Hearn has recently provided the missing piece of the puzzle of why Satoshi put the 1MB in place. It was for anti-spam when everyone who used Bitcoin needed to run a full node: a time when there were no lightweight wallets.

The idea which thezerg recently came up with is far superior to just leveraging the 1MB to force up fees (which won't work as people will start to abandon Bitcoin instead).

I'm for Gavin's 20MB increase.  But if I was doing it, I'd propose actually building a real supply/demand curve so economic analysis actually works.  The reason it doesn't work today is because additional demand (price) cannot ever create new supply (space in the block).

So I'd do it by allowing txn fee paying blocks to be located beyond the limit (its now a "soft" limit).  In other words, if your txn pays 0uBTC fee it can be located in the block at 0-20MB, if 1uBtc located at 0-21MB, if 2uBTC located at 0-22MB, 3uBTC located at 0-23MB, etc (or some other pricing curve).  So supply (space in a block) can actually increase as demand increases.

You might be able to look at historical block size vs price information to actually price this... it does not need to be perfect since an error will just move the graph a bit.  The biggest concern would be if exponential BTC price increases (vs fiat) makes the minimum fee way too high.  In that case, we are no worse than today's proposal.

I like this proposal a lot.

High-priority non-fee transactions that consume older coins are suppose to be just that, free and gain priority access to a block. Today's situation is even if your transaction has enough priority to qualify for free processing, they often take hours to confirm since most minors do not pick high priority transactions without a fee. This completely defeats the purpose of having the priority system at all.

Reserving a front space in each block for high-priority non-fee transactions does two things:
1) It would ensure that high-priority transactions are processed in a timely fashion
2) It would encourage more competition from low-priority transactions and possibly increase the fees they need to offer to be processed quickly

This would shift transaction fees more towards for profit services that are built on top of bitcoin and away from individual wallet users. I would consider this to be a good thing.

Anyone on this thread have contact with any of the core developers? Have they considered it? If not how could zerg propose it (provide people here also think it makes sense...)

If core dev came up with a variation of this, e.g. based upon a function of the median aggregate block fee over the previous 2016 blocks for the "buying" of blockspace >1MB then perhaps their position could be taken more seriously.

Erdogan
Hero Member
*****
Offline Offline

Activity: 826


View Profile
May 07, 2015, 12:43:29 AM
 #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?

smooth
Legendary
*
Offline Offline

Activity: 1596



View Profile
May 07, 2015, 12:56:28 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
majamalu
Legendary
*
Offline Offline

Activity: 1652



View Profile WWW
May 07, 2015, 04:52:08 AM
 #23511

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".

http://elbitcoin.org - Bitcoin en español
http://mercadobitcoin.com - MercadoBitcoin
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 07, 2015, 04:56:35 AM
 #23512

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

Activity: 1652



View Profile WWW
May 07, 2015, 05:26:56 AM
 #23513

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

Yep. If people understood this, we wouldn't have so many entrepreneurs and developers building castles in the air.

http://elbitcoin.org - Bitcoin en español
http://mercadobitcoin.com - MercadoBitcoin
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
May 07, 2015, 05:49:10 AM
 #23514

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.

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

Activity: 2408



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

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

Activity: 1274



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

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

Activity: 1764



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

<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


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

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



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

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


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

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.
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 ... 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!