ToominCoin aka "Bitcoin_Classic" #R3KT

[Bergmann_Christoph]

This have been the questions about Lightning:

Will I be able to take a private key from a payment-channel payment - an exact amount of bitcoins - and activate it and use it on any system I want?

yes and no. Depends on the alternative system, not on Lightning's implementation

Will I be able audit it = proof, maybe with a signed message, that I did pay exactly this amount?

yes

Will I be able to use my bitcoins locked in a payment channel to pay everywhere where I can pay with bitcoins?

yes, it might be unwise, but it might not be. depends on the specific circumstances

Will I be able to log my bitcoins out of the payment channel without the "ok" from some other person? Or can some other person thread to keep my bitcoins logged in?

yes to the former, no to the latter

Nice -- more of this Carlton, less from the other -

I'm not sure about everything, have to compute how it works. Some points are unclear and it's hard to believe.

[hdbuck]

I'm not sure about everything, have to compute how it works. Some points are unclear and it's hard to believe.

meh, i concur the simple and idiotic classic et al. proposals are much more easy to believe^tm

[Carlton Banks]

Chistoph, you're in no position to be appraising my conduct, you've been an idiot thorn in the side for this forum ever since you turned up.


You're ignorant. And you admit it freely. Either read up on the topic, or get some humility.

[blunderer]

...

Will I be able to use my bitcoins locked in a payment channel to pay everywhere where I can pay with bitcoins?

yes, it might be unwise, but it might not be. depends on the specific circumstances
...

Ignorant or flat-out lying?  
Either read up on the topic, or get some humility.

[Bergmann_Christoph]

Chistoph, you're in no position to be appraising my conduct, you've been an idiot thorn in the side for this forum ever since you turned up.


You're ignorant. And you admit it freely. Either read up on the topic, or get some humility.

Carlton -- I highly recommend you to think before you press enter. Such statements do nothing good for you.

At least get some style. By now your attempts in insulting demonstrate just your lack of creativity. Learn from hdbuck and iCEBREAKER! They are, at least, funny.

I'm currently learning about Lightning. I asked some questions, I'm happy about your answers, but since you did not explain them I have to learn more before I believe. What's the problem?

[hdbuck]

I have to learn more before I believe. What's the problem?

The problem is believing has nothing to do with learning, idiot.

[Bergmann_Christoph]

I have to learn more before I believe. What's the problem?

The problem is believing has nothing to do with learning.

Good reply

But, no, wrong.

Give some humility to all that great philosophers your country has brought up! With every word you say you believe in something.

Thinking that knowing and learning has nothing to do with believing is one of the typical properties of that kind of people who think they see the truth while they sit in a dark hole. It's always fun to watch them explaining the world they don't see ...

[bargainbin]

...
The problem is believing has nothing to do with learning, idiot.

True.

[sickpig]

No matter how many times you bump the block size limit you will always run into this issue. This is because increasing the block size limit is not a solution, it is a band-aid.

meh i disagree about the band-aid analogy.

in 100 years when internet speeds are 10000X faster 1GB blocks will be viable.

Given today's technology, 1GB blocks would be a bad idea tomorrow. Given today's technology, 2MB would be a bad idea tomorrow. Given next year's tech and SegWit active on the network for several months, 2MB is probably not too bad. Let's hope the internet itself doesn't take any backward steps between now and then, I guess

(bold's mine).

Miners that are using  RLN could support 2MB blocks without even noticing. For normal nodes -blockonly could do the trick. According to gmax this would save 88% of bandwidth.

Now if you're worried about nodes not relaying txs, just do not use -blockonly and convince Core dev to apply Xthin to BitcoinCore.  You could save a lot of bandwidth while propagating new blocks  (more or less 10 times less BW required) .

edit: fix grammar

[JayJuanGee]

Personally, I believe that it would not be a good business practice to either encourage people to use other forums or to allow members to promote other forums within your forum.... even though surely we know that other bitcoin forums do exist.

Technically, yes. However, if you've spent a lot of time in threads related to contentious HF's, you would see that some are constantly trying to manipulate others in addition to discussions just kind-of looping.

Fair enough.  I don't spend too much time in HF threads, even though many threads in this forum are seeming to incorporate that HF topic.

  I understand that it is probably not easy to keep up with banning and suspending of troll accounts that keep repeating themes with little to no substance, and some trolling is probably acceptable... but maybe banning and suspending is the best solution, ultimately, rather than suggesting that members go to other forums....  

Don't get me wrong;.... I am also of the opinion that neither hardforking nor making hardforking easier in bitcoin seems to not be the solution to a better and stronger (more secure bitcoin), and there seems to be quite a bit of success in bitcoin in recent times from the fact that there has not been any actual hard fork, and the idea of a hardfork seems to be less and less convincing for people who give the repercussions some serious thought and who really want to make bitcoin stronger.

[Carlton Banks]

Given today's technology, 2MB would be a bad idea tomorrow.

Miners that are using  RLN could support 2MB blocks without even noticing. For normal nodes -blockonly could do the trick. According to gmax this would save 88% of bandwidth.

Now if you're worried about nodes not relaying txs, just do not use -blockonly and convince Core dev to apply Xthin to BitcoinCore.  You could save a lot of bandwidth while propagating new blocks  (more or less 10 times less BW required) .

Well, that solves the problem for miners, but what about the users? Remember, I said "tomorrow". Thin blocks/IBLT are not available on the network tomorrow. But in principle, I agree, it's just that "tomorrow" part.

[adamstgBit]

contentious HF's aren't evil, and implemented with 75% tigger + grace period they are hardly contentious. its silly to think everyone will agree on all changes, and its even sillier to not implement a change that the supermajority want to see. HF might actually be favourable over softforks, poeple who run machines which secur people's money have a responsibility to run a well oiled machine. A few SF later and now nodes on the network might start to have undefined/different behaviours, this will complicate things and hinder future developments.
we will see this first hand with segwit. the effective block size incress might not be be so effective.
one day Core will require a HF for some new thing they want to add...

[sickpig]

Given today's technology, 2MB would be a bad idea tomorrow.

Miners that are using  RLN could support 2MB blocks without even noticing. For normal nodes -blockonly could do the trick. According to gmax this would save 88% of bandwidth.

Now if you're worried about nodes not relaying txs, just do not use -blockonly and convince Core dev to apply Xthin to BitcoinCore.  You could save a lot of bandwidth while propagating new blocks  (more or less 10 times less BW required) .

Well, that solves the problem for miners, but what about the users? Remember, I said "tomorrow". Thin blocks/IBLT are not available on the network tomorrow. But in principle, I agree, it's just that "tomorrow" part.

-blocksonly is available today in Bitcoin Core, (see: #6993 b632145 Add -blocksonly option (Patrick Strateman))

even Xthin is available today, not in Bitcoin Core though.

[adamstgBit]

Given today's technology, 2MB would be a bad idea tomorrow.

Miners that are using  RLN could support 2MB blocks without even noticing. For normal nodes -blockonly could do the trick. According to gmax this would save 88% of bandwidth.

Now if you're worried about nodes not relaying txs, just do not use -blockonly and convince Core dev to apply Xthin to BitcoinCore.  You could save a lot of bandwidth while propagating new blocks  (more or less 10 times less BW required) .

Well, that solves the problem for miners, but what about the users? Remember, I said "tomorrow". Thin blocks/IBLT are not available on the network tomorrow. But in principle, I agree, it's just that "tomorrow" part.

afaik thin blocks will benefit user node just as much as miner nodes?
there available now, no? the code has been written and is working on some nodes ( BU nodes right? ), Core just needs to copy past.
is it part of the plan to add that in at some point? does core have reasons for not wanting thin blocks?

[QuestionAuthority]

Good lord, what a shit nest this thread has become. I can't believe I actually read through everything since the last time I looked at it. I've seen less name calling watching WWE Smackdown.

3-4 years ago every other thread was about the government interfering with Bitcoin. What could the big bad government do to destroy poor Bitcoin? Well, we don't have to worry about that anymore. The users and developers are going to destroy it. Everyone thinks Bitcoin is just fine because the price is high and stable. I guess no one remembers MtGox and the world of the artificial price.

[JayJuanGee]

contentious HF's aren't evil, and implemented with 75% tigger + grace period they are hardly contentious. its silly to think everyone will agree on all changes, and its even sillier to not implement a change that the supermajority want to see. HF might actually be favourable over softforks, poeple who run machines which secur people's money have a responsibility to run a well oiled machine. A few SF later and now nodes on the network might start to have undefined/different behaviours, this will complicate things and hinder future developments.
we will see this first hand with segwit. the effective block size incress might not be be so effective.
one day Core will require a HF for some new thing they want to add...

If you really think about what you are saying Adam, you should come to the opposite conclusion.  We don't want people fucking with our money and to be able to change bitcoin so easily.

Currently bitcoin is secure, and we want it to be very difficult to change.  If you believe that you want it to be able to change easy, then you have been taken for a ride by people who really want to undermine bitcoin (possibly unwittingly). 


The various upcoming changes for bitcoin are going to be incremental, good and keep bitcoin secure with people's money.  For everything else, there's visa.  hahahahahahaha   
 

[adamstgBit]

Good lord, what a shit nest this thread has become. I can't believe I actually read through everything since the last time I looked at it. I've seen less name calling watching WWE Smackdown.

3-4 years ago every other thread was about the government interfering with Bitcoin. What could the big bad government do to destroy poor Bitcoin? Well, we don't have to worry about that anymore. The users and developers are going to destroy it. Everyone thinks Bitcoin is just fine because the price is high and stable. I guess no one remembers MtGox and the world of the artificial price.

everything is fine, our bitching is confined to this thread, and no one bothers to read it except for a handful of poeple.

[adamstgBit]

contentious HF's aren't evil, and implemented with 75% tigger + grace period they are hardly contentious. its silly to think everyone will agree on all changes, and its even sillier to not implement a change that the supermajority want to see. HF might actually be favourable over softforks, poeple who run machines which secur people's money have a responsibility to run a well oiled machine. A few SF later and now nodes on the network might start to have undefined/different behaviours, this will complicate things and hinder future developments.
we will see this first hand with segwit. the effective block size incress might not be be so effective.
one day Core will require a HF for some new thing they want to add...

If you really think about what you are saying Adam, you should come to the opposite conclusion.  We don't want people fucking with our money and to be able to change bitcoin so easily.

Currently bitcoin is secure, and we want it to be very difficult to change.  If you believe that you want it to be able to change easy, then you have been taken for a ride by people who really want to undermine bitcoin (possibly unwittingly). 


The various upcoming changes for bitcoin are going to be incremental, good and keep bitcoin secure with people's money.  For everything else, there's visa.  hahahahahahaha   
 

where do you get that getting 75% hashing power to agree to a change is easy?
its obviously proving to be very very hard.

isn't it easier to introduce a SF??

[Carlton Banks]

afaik thin blocks will benefit user node just as much as miner nodes?

yes that's what I said. Explicitly. What's wrong with your reading?

there available now, no? the code has been written and is working on some nodes ( BU nodes right? ), Core just needs to copy past.
is it part of the plan to add that in at some point? does core have reasons for not wanting thin blocks?

Lol. Adam, I'm here to talk about Bitcoin, you're clearly here to talk about some other currency that doesn't exist. You should use BU yourself and hang out on their forums, You're never going to have any influence on Bitcoin development, especially not with commentary like "Core just needs to copy past." Core will add thin blocks, just not some 5 minute hack job cooked up from the belly button lint of the BU coders

[Carlton Banks]

where do you get that getting 75% hashing power to agree to a change is easy?
its obviously proving to be very very hard.

isn't it easier to introduce a SF??

Adam, you were trying to say that hard forks were easier to implement than soft forks, only a post or two ago. What changed?