Quote from: franky1 on January 06, 2017, 11:54:52 PM

Quote from: jackg on January 06, 2017, 11:40:36 PM

All of these would probably take years to implement. They are all "hard forks" that need to be done and can only be done with the majority of nodes running the new system.
There would also be multiple security threats that may rise with these hard forks if they are rushed or not fully tested (due to the pressure of the community).

nope.

the blocksize option is not that bad. right now my client has a 2mb rule and is working fine. there are several hundred nodes with blocksize rules of over 1mb actually running right now on the network..

in 2009-2014. there were thousands of nodes with 1mb rule even when the blocks were only 0.5mb.. i know shocking right.. mindblowing thought that users can actually have a higher buffer set than what pools are producing. and doing it years before pools think the network can cope with it..
yes, mega brain fart explosion moment that decimates most of all the doomsdays rhetorics.

the funny part is that the node count can have the rule inplace before mining pools even decide to vote. the code has been available for implementations that are not core since last year. and it would only take a couple days for core to tweak their code too.. but they refuse as they fear the community will adopt it.. so their mindset is if you dont give the community caviar they will never ask for it next time they are spoonfed.

ofcourse mining pools wont move to bigger blocksizes unless majority of nodes can cope with it. which is why core wont offer it.
as for cores segwit. this doesnt need node implementation meaning the code that has a functioning wallet (not released yet(yep even 0.13.2 doesnt allow segwit transaction creation on mainnet)) is not released and wont be released until after activation, which means after activation there will be mad panic to download and peer review the code independently.

kind of backwards.. but hey. thats core.

Quote from: jackg on January 06, 2017, 11:40:36 PM

It would clear up a lot of issues if the block intervals were set to 1 minute/block (not really a good idea for obvious reasons - blocks could have just one transaction and block rewards would have to be changed which I'm not sure is possible).

1min?
those complaining about 10mins would complain about 1min

think about it, you are at a shop and someone swipes their touchless NFC debit card and is gone in 3 seconds. you are then there standing around. after 10 seconds you hear people tutting and whispering "why is he just standing there" by 30 seconds you see them looking at their watches and getting angry. by the 1minute mark your apologising for making them wait.

1minute and 10minutes wont help most situations people cry about..
onchain double spending needs to be fixed by not having invented things like the fee mechanism (causing possible reject by simply not paying adequate fee maliciously/intently) or making a second tx that diverts funds and then use RBF and CPFP to force your preferred tx through first. thus rejecting the other tx.

Quote from: jackg on January 06, 2017, 11:40:36 PM

If we had wallets on exchanges such as coinbase or blockchain.info then when sending "internally" the transaction could be instant and done in house (I think coinbase already do this to a certain degree - although I could be wrong). Then all you'd have to do is keep a small amount there to put the coins in daily for these transactions.

but now you are talking about middlemen managed services.. this is what offchain LN is. imagine coinbase you you set up a multisig together where coinbase cant move the funds without your permission and you cant move funds between them. yep it allows for faster transactions than the ones requiring confirmations.. but now your no longer in a permissionless position but instead a banking position.
also although you can 'trust' the funds instantly.. the true settlement lock will be longer than the 10 minutes. but hey if settling is of no concern, then go for it.. but you might aswell be using fiat too..

Law inforcement is very good in a lot of countries. If you have good enough CCTV then the person doesn't have to wait at all. The shopkeeper merely logs all transactions of bitcoin daily on thir till (which they have to do for ta purposes anyway) and then they can spend their time when they are less busy to check if a transaction has gone through.
You could also set up online accounts with them where you deposit say 0.1BTC to a supermarket in the morning and then go to collect your groceries when you finish work (ensuring your transaction has been confirmed).
Or you preload a paper wallet with 0.1BTC and hand it to them, they then use their bar code scanner to start the transaction process (there is currently no way well known to reverse the process of a transaction once the correct inputs, amount and outputs are suggested (I dont think)).

Also, I didn't realise the ma block size can be changed by the user of each node/core client. But if you're going to double the limit, why have a limit at all? It's not likely to be over 1GB in size so set that as the maximum and then everyone gets fast transactions, although then the network has to be changed with the difficulty based on different size blocks (doesn't it)?