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

Pages: « 1 ... 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 [1207] 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1807091 times)
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 15, 2015, 07:22:31 PM
 #24121


The discussion on reddit was about this being reported in the main stream media.

The answer is, if it can be used to smear Russia, it will be reported, if not, it will not be reported (I hope I am wrong).
1481283950
Hero Member
*
Offline Offline

Posts: 1481283950

View Profile Personal Message (Offline)

Ignore
1481283950
Reply with quote  #2

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

Posts: 1481283950

View Profile Personal Message (Offline)

Ignore
1481283950
Reply with quote  #2

1481283950
Report to moderator
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
May 15, 2015, 07:27:03 PM
 #24122

I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.

First off, you can't take a 1BTC address and create 10000 zero balance outputs  with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.

Second, even if the attacking miner constructs  non zero output  TX's, he  can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject  the bloated block since they don't recognize any of the content.

There's a difference between non-standard transactions and invalid transactions.  Non-standard transactions are a subset of valid transactions. Examples of non-standard transactions are TXs with outputs less than the dust limit or TXs with insufficient fees; such transactions may still be valid, however.  

Clients do not relay nonstandard transactions, nor accept them into mempool, but will nonetheless accept a solved block that contains them (provided each TX in the block is still valid).    Example of blocks full of nonstandard (and pointless) transactions are Block #309657 and Block #309740.  They each contain thousands of 1 satoshi dust outputs that will pollute the UTXO set for a long time!

Code:
BLOCK #309740:  10,486 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749

A miner can fill a block full of nonsense transactions very easily.  

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

Activity: 1153


View Profile
May 15, 2015, 07:38:41 PM
 #24123

I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.

First off, you can't take a 1BTC address and create 10000 zero balance outputs  with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.

Second, even if the attacking miner constructs  non zero output  TX's, he  can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject  the bloated block since they don't recognize any of the content.

There's a difference between non-standard transactions and invalid transactions.  Non-standard transactions are a subset of valid transactions. Examples of non-standard transactions are TXs with outputs less than the dust limit or TXs with insufficient fees; such transactions may still be valid, however.  

Clients do not relay nonstandard transactions but will accept a solved block that contains them (provided each TX in the block is still valid).    Example of blocks full of nonstandard (and pointless) transactions are Block #309657 and Block #309740.  They each contain thousands of 1 satoshi dust outputs that will pollute the UTXO set for a long time!

Code:
BLOCK #309740:  10,486 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749

A miner can fill a block full of nonsense transactions very easily.  

Good point on the inclusion of non-standard but valid transactions. What I outlined just included standard & valid transactions. What you outlined is how much further an attacker could push this, here 1BTC could turn into 100M satoshi dush outputs....

On the UTXO topic, the distribution of balances here

http://bitcoinrichlist.com/charts/bitcoin-distribution-by-address?atblock=350000

shows that 96.97% of addresses contain less than 0.001 BTC. Now these are address totals, any analysis of UTXO outputs would show that more than 96.97% of UTXO outputs contain less than 0.001BTC.

I think this shows that the UTXO is already vastly populated by dust nonsense that simply sits around. If UTXO size becomes an issue any intelligent implementation could easily swap these out to a lower tier of storage. Most of this dust will never be spent simply because you'd have to pay more in fees than the output is worth, spending them is literally burning money.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 08:18:54 PM
 #24124

I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.

First off, you can't take a 1BTC address and create 10000 zero balance outputs  with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.

Second, even if the attacking miner constructs  non zero output  TX's, he  can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject  the bloated block since they don't recognize any of the content.

There's a difference between non-standard transactions and invalid transactions.  Non-standard transactions are a subset of valid transactions. Examples of non-standard transactions are TXs with outputs less than the dust limit or TXs with insufficient fees; such transactions may still be valid, however.  

Clients do not relay nonstandard transactions, nor accept them into mempool, but will nonetheless accept a solved block that contains them (provided each TX in the block is still valid).    Example of blocks full of nonstandard (and pointless) transactions are Block #309657 and Block #309740.  They each contain thousands of 1 satoshi dust outputs that will pollute the UTXO set for a long time!

Code:
BLOCK #309740:  10,486 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749

A miner can fill a block full of nonsense transactions very easily.  

thanks for clarifying that.

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 15, 2015, 08:29:49 PM
 #24125

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

The attacks yield zero profit, and in actuality cost money. Only a government agency (or something similar) not driven by profit and highly motivated to stop bitcoin would bother with these types of blockchain/UTXO bloat attacks.
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
May 15, 2015, 10:13:02 PM
 #24126

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.



cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 10:21:03 PM
 #24127

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.





Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
May 15, 2015, 10:39:42 PM
 #24128

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.





Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The main reason it does make sense is that p2p relaying has no fee.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 15, 2015, 10:40:26 PM
 #24129

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 15, 2015, 10:44:02 PM
 #24130

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 15, 2015, 10:44:24 PM
 #24131

NYT has an article claiming Nick is Satoshi.

http://www.nytimes.com/2015/05/17/business/decoding-the-enigma-of-satoshi-nakamoto-and-the-birth-of-bitcoin.html?_r=0

While I agree the evidence shows him to be in the likely list, there is a pool of other people who worked on similar projects and participated in similar forums, any one of which could be Satoshi as well.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 15, 2015, 10:46:12 PM
 #24132

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?


Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.

Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 15, 2015, 10:55:22 PM
 #24133

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?


Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule).

Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

Ok. And I see that the mempool (I run a standard bitcoind) is even bigger, but according to docs the nodes keep invalid transactions, and logically they therefore also keep the nonstandard transactions, in the memory pool until shutdown. There seems to be no way to display the number of valid and standard transactions waiting in the mempool in a standard node. Correct?

Edit: After (upgrade and) restart of my node, the mempool is only 107 long, i guess those are mostly valid and standard transactions waiting to get in.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 11:33:42 PM
 #24134

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?


Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.

Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from  changes to the protocol which defines what is acceptable as a block and requires a fork?
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 15, 2015, 11:38:50 PM
 #24135

That seems to be correct.

And ... each node holds a different set of non-standard and invalid transactions, because they are only held, not propagated. Correct?

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 11:45:40 PM
 #24136

That seems to be correct.

And ... each node holds a different set of non-standard and invalid transactions, because they are only held, not propagated. Correct?



i wonder why they would even be held.  why not ignored?
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 15, 2015, 11:55:47 PM
 #24137

That seems to be correct.

And ... each node holds a different set of non-standard and invalid transactions, because they are only held, not propagated. Correct?



i wonder why they would even be held.  why not ignored?

Good question.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 16, 2015, 12:03:47 AM
 #24138

That seems to be correct.

And ... each node holds a different set of non-standard and invalid transactions, because they are only held, not propagated. Correct?



i wonder why they would even be held.  why not ignored?

Good question.


it's interesting how us non CS trained participants can blur things together.  i guess i should speak for myself; as one unit, as opposed to a separate base protocol layer governed by rigid communication rules interacting with an overlaying program, like Bitcoin Core and other wallets, which have the flexibility to interact with the protocol in any number of ways, including loose agreements.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 16, 2015, 12:37:05 AM
 #24139

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?


Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.

Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from  changes to the protocol which defines what is acceptable as a block and requires a fork?

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.

Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.

Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.

Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 16, 2015, 01:03:11 AM
 #24140

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?


Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.

Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from  changes to the protocol which defines what is acceptable as a block and requires a fork?

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.

Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.

Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.

Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).

and your definition of a hard vs soft fork?
Pages: « 1 ... 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 [1207] 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 ... 1560 »
  Print  
 
Jump to:  

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