Bitcoin Forum
November 19, 2017, 10:23:56 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 ... 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 [1379] 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2009524 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 27, 2015, 03:32:49 PM
 #27561

character assassins please step up.

you're letting the thread fall too low.
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.
1511130236
Hero Member
*
Offline Offline

Posts: 1511130236

View Profile Personal Message (Offline)

Ignore
1511130236
Reply with quote  #2

1511130236
Report to moderator
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
June 27, 2015, 03:47:06 PM
 #27562

About Poll,
I think that bitcoin needs a variable size, readjust depending on the size.

That mechanism exists it's cleverly linked to the value stored in the network.
The debate is when the network has a low value how should we intervene to prevent abuse.

One side see introducing mechanisms for high fees as the best deterrent. The opponents say that will limit adoption.
The other see growth as a higher priority and intervention only if abuse becomes a problem. Innovation in tech sets a good president for this approach.

Many Core developers are risk adverse, it's their way or the highway as they are the gate keepers, they are also the ones who would have to fix any problems so they feel they are better equipped to make this decision. - problem is this has highlighted a conflict in development and that is central controlled policy makers decided for us which brigs into question the whole idea that Bitcoin is decentralized.  

In my view If anything we should be planning for Bitcoin growth and working on ways to prevent the existing mechanism from abuse.  

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 27, 2015, 03:52:01 PM
 #27563

geezuz crimony.  look at the blocks filling up.  and this is NOT a spam attack. it's from use:

http://btc.blockr.io/block/list/

yet Cripplecoin.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 27, 2015, 03:53:11 PM
 #27564

geezuz crimony.  look at the blocks filling up.  and this is NOT a spam attack. it's from use:

http://btc.blockr.io/block/list/

yet Cripplecoin.

blocks are filling up b/c of the buying going on. 

who here wants to be stuck with unconfirmed tx buy pressure b/c of the fricking 1MB'ers?
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 27, 2015, 04:07:00 PM
 #27565

throwing random numbers to kick the can further down the road seems quite juvenile.
A fixed size increase as a way to buy time before the measures needed to make the limit unnecessary can be put into place is a very reasonable and practical solution.

The long term solution is to have no magic constants for transaction rate limits, but getting there will take time.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 27, 2015, 04:09:00 PM
 #27566

tvbcof, TPTB, iCEBlow, MOA, kazukiPIMP?

i know they gotcha on Ignore but that's beside the point.  the point is for you to help me generate even more views and keep the thread front and center so more and moar ppl can view the poll results and so you can reinforce my importance and this thread to the community.

get with the character assassinations you thugs.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 27, 2015, 04:12:25 PM
 #27567

Quoted for truth:

https://www.reddit.com/r/Bitcoin/comments/3bajai/by_expecting_a_few_developers_to_make/cskk0vq

Quote from: ferretinjapan
Absolutely. A decision to hard fork or not is not up to any developer, it doesn't matter whether they are a core developer, working on XT, or a different version. It doesn't matter if 90% of developers want the rules to change, or 5% do, they should be given slightly more consideration than the rest of the community when it comes to deciding to fork or not.

If their egos are so damn fragile that they'll spit the dummy when the community does something they don't like, then they need to be schooled on what their purpose in the Bitcoin community is, and what it isn't. They are advisers, mentors, and improvers that have the know-how to make changes in the Bitcoin software that can be reviewed and implemented by the community, for the community's benefit. They are NOT representatives of the community that have the power to veto or direct how Bitcoin should grow, or develop over time. The fact that they some take sides (side with people rather than support solutions), get personal, threaten to up and leave/sell their coins, and spread FUD, rather than state their case logically and technically is not what any developer should be doing.
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 27, 2015, 04:31:00 PM
 #27568

geezuz crimony.  look at the blocks filling up.  and this is NOT a spam attack. it's from use:

http://btc.blockr.io/block/list/

yet Cripplecoin.

blocks are filling up b/c of the buying going on.  

who here wants to be stuck with unconfirmed tx buy pressure b/c of the fricking 1MB'ers?

According to https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html there are 2,794,041 (53.24%) addresses with value less than 0.0001 btc.

If we have enough space for this shit https://blockchain.info/tx/73026d18b0b3e627c7b1b84bea69496963b91d7e2ddb1b9efab9622836e6c6c8 then we do not need increase in block size.

Let them pay $1 per transaction.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 27, 2015, 04:35:12 PM
 #27569

Quoted for truth:

https://www.reddit.com/r/Bitcoin/comments/3bajai/by_expecting_a_few_developers_to_make/cskk0vq

Quote from: ferretinjapan
Absolutely. A decision to hard fork or not is not up to any developer, it doesn't matter whether they are a core developer, working on XT, or a different version. It doesn't matter if 90% of developers want the rules to change, or 5% do, they should be given slightly more consideration than the rest of the community when it comes to deciding to fork or not.

If their egos are so damn fragile that they'll spit the dummy when the community does something they don't like, then they need to be schooled on what their purpose in the Bitcoin community is, and what it isn't. They are advisers, mentors, and improvers that have the know-how to make changes in the Bitcoin software that can be reviewed and implemented by the community, for the community's benefit. They are NOT representatives of the community that have the power to veto or direct how Bitcoin should grow, or develop over time. The fact that they some take sides (side with people rather than support solutions), get personal, threaten to up and leave/sell their coins, and spread FUD, rather than state their case logically and technically is not what any developer should be doing.

+1.  I read that comment and thought the same thing.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 27, 2015, 04:50:47 PM
 #27570

Much of the blocksize-limit debate is about keeping Bitcoin decentralized.  But I'm not even sure we even agree what that word means!  I'll propose the following as a working definition:

  "A system is decentralized if no entity exists that can exert veto power over the consensus process."

Interestingly, according to this definition a system cannot be more decentralized or less decentralized.  Similar to how a woman cannot be a little bit pregnant, a system is either decentralized or it is not.  

Of course there's certain behaviours that a woman can do to increase the chances of moving from the "not" state to the "pregnant" state, and certain precautions she can take to decrease these chances--but this is a different matter entirely to whether she is or is not pregnant.  Analogously, there are certain designs that may be more (or less) robust to moving to a centralized state, but that's a different thing from whether the system is or is not decentralized.  

So we actually need two distinct terms: "decentralized" is one of them, but we need another term that refers to the system's likelihood of remaining in the decentralized state.  

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 27, 2015, 04:58:09 PM
 #27571

I read that comment and thought the same thing.
I think it would be a tragedy for them to miss that lesson, and then lose the ability to make beneficial contributions to Bitcoin in the future.

I'd love to see the blinded output amounts from Confidential Transactions make it into Bitcoin, but I don't think their current approach to this debate is a viable way of ensuring they'll be in a position to advocate for that in the future.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 27, 2015, 05:07:19 PM
 #27572

I read that comment and thought the same thing.
I think it would be a tragedy for them to miss that lesson, and then lose the ability to make beneficial contributions to Bitcoin in the future.

On a related note, the people whom I follow and consider the top thinkers in bitcoin, were perhaps 2 to 1 in favour of SPVP sidechains.  I've noticed that this blocksize debate has triggered several of them to reconsider, and my hunch is that this group is now 2 to 1 against.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 27, 2015, 05:12:22 PM
 #27573

I read that comment and thought the same thing.
I think it would be a tragedy for them to miss that lesson, and then lose the ability to make beneficial contributions to Bitcoin in the future.

I'd love to see the blinded output amounts from Confidential Transactions make it into Bitcoin, but I don't think their current approach to this debate is a viable way of ensuring they'll be in a position to advocate for that in the future.

I would afraid to have CT on main chain.
There may be bug (or luck to find some number) and then creating bitcoins out of nothing. And nobody can verify.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 27, 2015, 05:20:20 PM
 #27574

There may be bug (or luck to find some number) and then creating bitcoins out of nothing. And nobody can verify.
That is the risk - the scheme relies on the security of ECDSA to protect the currency supply.

We're already relying on ECDSA to protect our balances from overt theft, so I'm not sure how much it actually changes the security model to also rely on it to protect our balances from covert theft via counterfeiting.

The reason I'm interested in amount blinding is that my current project is working out a multi-step plan to kill graph analysis. With the right plan and without blinded amounts we can kill graph analysis, but with blinded amounts we can drive a stake through its heart to make sure it stays dead.
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 27, 2015, 05:35:08 PM
 #27575

There may be bug (or luck to find some number) and then creating bitcoins out of nothing. And nobody can verify.
That is the risk - the scheme relies on the security of ECDSA to protect the currency supply.

We're already relying on ECDSA to protect our balances from overt theft, so I'm not sure how much it actually changes the security model to also rely on it to protect our balances from covert theft via counterfeiting.

The reason I'm interested in amount blinding is that my current project is working out a multi-step plan to kill graph analysis. With the right plan and without blinded amounts we can kill graph analysis, but with blinded amounts we can drive a stake through its heart to make sure it stays dead.

We are also using SHA-256 and RIPEMD-160 hashes to protect our balances. So even ECDSA is broken our balances can be safe and then ECDSA replaced.
tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
June 27, 2015, 05:56:40 PM
 #27576

tvbcof, TPTB, iCEBlow, MOA, kazukiPIMP?

i know they gotcha on Ignore but that's beside the point.  the point is for you to help me generate even more views and keep the thread front and center so more and moar ppl can view the poll results and so you can reinforce my importance and this thread to the community.

get with the character assassinations you thugs.

Just FWIW, your attacks on Maxwell in particular contributed to my pulling out all the stops in going after your champions Hearn and Andresen.  Even so, I never stooped to using absurd bullshit arguments (that I can recall.)  All of my critiques have been what I felt comfortable arguing vigorously.  Perhaps for that reason they are rarely challenged (to my dismay.)


Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
June 27, 2015, 06:03:04 PM
 #27577

Much of the blocksize-limit debate is about keeping Bitcoin decentralized.  But I'm not even sure we even agree what that word means!  I'll propose the following as a working definition:

  "A system is decentralized if no entity exists that can exert veto power over the consensus process."

Interestingly, according to this definition a system cannot be more decentralized or less decentralized.  Similar to how a woman cannot be a little bit pregnant, a system is either decentralized or it is not.  

Of course there's certain behaviours that a woman can do to increase the chances of moving from the "not" state to the "pregnant" state, and certain precautions she can take to decrease these chances--but this is a different matter entirely to whether she is or is not pregnant.  Analogously, there are certain designs that may be more (or less) robust to moving to a centralized state, but that's a different thing from whether the system is or is not decentralized.  

So we actually need two distinct terms: "decentralized" is one of them, but we need another term that refers to the system's likelihood of remaining in the decentralized state.  

Not bad. The market is what we need.

kazuki49
Sr. Member
****
Offline Offline

Activity: 350



View Profile
June 27, 2015, 07:22:53 PM
 #27578

There may be bug (or luck to find some number) and then creating bitcoins out of nothing. And nobody can verify.
That is the risk - the scheme relies on the security of ECDSA to protect the currency supply.

We're already relying on ECDSA to protect our balances from overt theft, so I'm not sure how much it actually changes the security model to also rely on it to protect our balances from covert theft via counterfeiting.

The reason I'm interested in amount blinding is that my current project is working out a multi-step plan to kill graph analysis. With the right plan and without blinded amounts we can kill graph analysis, but with blinded amounts we can drive a stake through its heart to make sure it stays dead.

We are also using SHA-256 and RIPEMD-160 hashes to protect our balances. So even ECDSA is broken our balances can be safe and then ECDSA replaced.

Actually, the best path to a safe balance is not having a public balance at all.

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

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

http://i.imgur.com/MUOwbae.png
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 27, 2015, 07:37:02 PM
 #27579

geezuz crimony.  look at the blocks filling up.  and this is NOT a spam attack. it's from use:

http://btc.blockr.io/block/list/

yet Cripplecoin.

blocks are filling up b/c of the buying going on.  

who here wants to be stuck with unconfirmed tx buy pressure b/c of the fricking 1MB'ers?

According to https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html there are 2,794,041 (53.24%) addresses with value less than 0.0001 btc.

If we have enough space for this shit https://blockchain.info/tx/73026d18b0b3e627c7b1b84bea69496963b91d7e2ddb1b9efab9622836e6c6c8 then we do not need increase in block size.

Let them pay $1 per transaction.

Agreed. Undecided

My bank charges me $10 for international transfer.

$1 per transaction ( 250 bytes )  is $4,000 per 1 MB block.
 - 6 * $4,000 =>  $24,000 per hour
 - 24 * $24,000 => $576,000 fee/day
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 27, 2015, 07:47:25 PM
 #27580

tvbcof, TPTB, iCEBlow, MOA, kazukiPIMP?

i know they gotcha on Ignore but that's beside the point.  the point is for you to help me generate even more views and keep the thread front and center so more and moar ppl can view the poll results and so you can reinforce my importance and this thread to the community.

get with the character assassinations you thugs.

Not to give an opinion on the merit of the above posters, but have you weighed the benefits of page position versus the harm to the signal-to-noise ratio from continual acrimonious/low-content bickering? Even the harm to the reputation of this thread as the easiest place to quickly (i.e., without having to sort through many pages of noise) get abreast of the actually important happenings and debates in the space? Due to the existing quality the good name of the thread will only grow, pushing it ever high on the page, even without all the noise. The noise certainly helps keep the thread near the top but at the cost of threatening to ruin the main selling point of the thread.
Pages: « 1 ... 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 [1379] 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 ... 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!