Transaction time 1-2 days -> you can use bank tx..
High fees. -> you can use bank tx...
Block size usage to hard limit ratio = 1 ->. There will be always cheap spam attacks possible ( why not launched by bank supporters?) so bank txs are not spammable. -> you can use bank tx...
Wake up guys and fix it and reinstall some of the most important bitcoin features.
Topic: Unconfirmed Transactions Problem - page 2. (Read 9372 times)
Wow, quite a long text...
I felt your answer as an attack. And this was my way to react.
O.k. I surely would phrase it a little bit differently, but it could still be that in some senses we agree.
The essence of the matter is that any changes take time, and we should be able to agree that we do not want to jump into making changes that merely cause more problems or that are controversial concerning what benefits they are going to bring.
The fact of the matter is that Seg wit was largely not very controversial. In December 2015 / January 2016, more or less, guys on both sides of the fence were largely in agreement that seg wit was a good idea and brought a lot of good changes and improvements to bitcoin.
Surely, in recent times, there has been some revisionary framings of the matter and some smaller factions (including some of the big blocker nut jobs) that are suggesting stupid ass ideas that they are wanting to block seg wit unless they can get a blocksize limit at the same time.. blah blah blah .. bullshit and threats of a kind of hostage taking.
The fact of the matter also is that the various proposals to increase the blocksize limit have remained controversial, and those making the proposals have not been very convincing regarding such a change is actually prudent or justified in any kind of meaningful way. In otherwords, they have failed to meet any kind of burden of proof regarding actual factual evidence and they have failed to meet any kind of burden of persuasion regarding logic...
So, yeah, if at some point, there is a need for a block size limit increase, and the burden of proof and persuasion is met concerning the need for it, then at that point the bridge should be crossed (or at least considered to be crossed). We are a long way from having any kind of consensus regarding taking any other steps, besides seg wit, at this point.
I am not great on explaining my thoughts and my primary language is not English, so there are things that get badly "lost in translation".
But you felt it right. While I can't say I'm a big fan of increasing the block size (for example I feel like dynamic value could be a better approach), the overall feeling was that Bitcoin devs are afraid to do changes (Any changes. And this is bad and scary.). Especially as there was another change requested and that didn't happen either (sadly I don't remember what was that). I know that it was more talk and politics and the decision is the one hard to do, not as much the code.
I've just read today about the segwit release (although it will take more time until it will be active) and I became happy. A big change did happen finally.
I've seen these arguments a lot of times (stability is better than changes). And they are 99% valid. (The number of petahashes are more related to businesses earning big bucks from mining imho, not with how sturdy or useful Bitcoin is)
And I will come back to these spam attacks (or whatever they are). They show that Bitcoin is not perfect yet and it has to be improved further. And for that Bitcoin has to be changed, however difficult it is.
And yes, I know that such things cannot happen overnight, but as long as they are on an agenda, it's OK.
It's not me who asks for this (for me, if a transaction happens in 1-2 days is fine), it's the "general public" that starts to grow impatient.
You know, I feel like most would like to have the speed and fees of Dogecoin, but the price and network power of Bitcoin.
Maybe segwit will bring some fresh air into all this. We seem to need it.
You seem to be quibbling over minor and non-sensical points, and in other words attempting to get defensive rather than standing behind the gist of what you said and the tone in which you said it. Makes little sense to me that we should attempt to get caught up in parsing words rather than talking about the essence without any need to get defensive... I am not attempting to personally criticize or attack you, but I am attempting to look into the ramifications and the meaning of what you had asserted.
I felt your answer as an attack. And this was my way to react.
I know that they have their schedule and I know that they are busy with segwit which may improve some things.
I also know that pushing them brings nothing. And you know that too.
I also know that pushing them brings nothing. And you know that too.
O.k. I surely would phrase it a little bit differently, but it could still be that in some senses we agree.
The essence of the matter is that any changes take time, and we should be able to agree that we do not want to jump into making changes that merely cause more problems or that are controversial concerning what benefits they are going to bring.
The fact of the matter is that Seg wit was largely not very controversial. In December 2015 / January 2016, more or less, guys on both sides of the fence were largely in agreement that seg wit was a good idea and brought a lot of good changes and improvements to bitcoin.
Surely, in recent times, there has been some revisionary framings of the matter and some smaller factions (including some of the big blocker nut jobs) that are suggesting stupid ass ideas that they are wanting to block seg wit unless they can get a blocksize limit at the same time.. blah blah blah .. bullshit and threats of a kind of hostage taking.
The fact of the matter also is that the various proposals to increase the blocksize limit have remained controversial, and those making the proposals have not been very convincing regarding such a change is actually prudent or justified in any kind of meaningful way. In otherwords, they have failed to meet any kind of burden of proof regarding actual factual evidence and they have failed to meet any kind of burden of persuasion regarding logic...
So, yeah, if at some point, there is a need for a block size limit increase, and the burden of proof and persuasion is met concerning the need for it, then at that point the bridge should be crossed (or at least considered to be crossed). We are a long way from having any kind of consensus regarding taking any other steps, besides seg wit, at this point.
I am not great on explaining my thoughts and my primary language is not English, so there are things that get badly "lost in translation".
But you felt it right. While I can't say I'm a big fan of increasing the block size (for example I feel like dynamic value could be a better approach), the overall feeling was that Bitcoin devs are afraid to do changes (Any changes. And this is bad and scary.). Especially as there was another change requested and that didn't happen either (sadly I don't remember what was that). I know that it was more talk and politics and the decision is the one hard to do, not as much the code.
I've just read today about the segwit release (although it will take more time until it will be active) and I became happy. A big change did happen finally.
In this regard, difficulties in changing bitcoin is a really good thing, especially since out of the gate there was a lot of already real good features and incentives that has caused a very valuable network that is currently securing more than 10billion dollars and also supporting a pretty decent sized infrastructure that has been growing around it.
I say fuck off to those multiple arguments suggesting that bitcoin should be more easy to change in order to be able to adapt to the times, blah blah blah.. because in the end, bitcoin has already brought it's value and paradigm change in which there is no (NONE) system that even approaches anything close to its secure decentralized value transfer and storage.. I repeat, NONE. So, why screw with a good thing. There are a whole hell-of-a-lot of innovations coming down the pike that are going to take a while to play out.. but bitcoin remains a system that can be built upon, and in the longer run, folks are going to flock to this better mouse trap.. but it could take a while before joe blow realizes that bitcoin is the shit and bitcoin is the better mouse trap and there is no mouse trap like it and never has been a mouse trap like it. The peaking of over 2 petahashes of computing power is surely demonstrating that bitcoin has the capability to continue to stave off attacks and to secure value as the backbone, and systems can be built upon it (at a second layer level).
I say fuck off to those multiple arguments suggesting that bitcoin should be more easy to change in order to be able to adapt to the times, blah blah blah.. because in the end, bitcoin has already brought it's value and paradigm change in which there is no (NONE) system that even approaches anything close to its secure decentralized value transfer and storage.. I repeat, NONE. So, why screw with a good thing. There are a whole hell-of-a-lot of innovations coming down the pike that are going to take a while to play out.. but bitcoin remains a system that can be built upon, and in the longer run, folks are going to flock to this better mouse trap.. but it could take a while before joe blow realizes that bitcoin is the shit and bitcoin is the better mouse trap and there is no mouse trap like it and never has been a mouse trap like it. The peaking of over 2 petahashes of computing power is surely demonstrating that bitcoin has the capability to continue to stave off attacks and to secure value as the backbone, and systems can be built upon it (at a second layer level).
I've seen these arguments a lot of times (stability is better than changes). And they are 99% valid. (The number of petahashes are more related to businesses earning big bucks from mining imho, not with how sturdy or useful Bitcoin is)
And I will come back to these spam attacks (or whatever they are). They show that Bitcoin is not perfect yet and it has to be improved further. And for that Bitcoin has to be changed, however difficult it is.
And yes, I know that such things cannot happen overnight, but as long as they are on an agenda, it's OK.
I agree with you that these kinds of micro- currency applications are going to come with time, and we do not need to rush into them because there are more important things (and that is the security of the network and the value security overall).. In time, there are going to be all kinds of systems that are going to allow for micro transactions and even volume transactions, but those are going to take time to evolve to take place on top of bitcoin.. whether on the chain itself or at a second or third level through various layers on top of the underlying secure, decentralized and immutable system, aka our lillie fiend bitcoin. 
It's not me who asks for this (for me, if a transaction happens in 1-2 days is fine), it's the "general public" that starts to grow impatient.
You know, I feel like most would like to have the speed and fees of Dogecoin, but the price and network power of Bitcoin.
Maybe segwit will bring some fresh air into all this. We seem to need it.
If those transactions don't get confirmed and returned to their senders' wallets, so many shit on its way waiting for us. If bitcoin can be stopped in this way there is no way for that serious business owners will accept bitcoin again for a payment method. I hope it gets fixed soon.
If the spam attack ends, the network will be like new until Saturday or Sunday!
But you have a valid point there, the network needs some big fixes, one being to filter out these attacks somehow and quick.
The normal mempool used to be up to 4MB and during the last attack it rose to 40MB.
Devs have to take seriously into account that the world is not nice and shiny, Bitcoin also has enemies and people that try to profit from any weakness they can find.
I will agree with you that having transactions delayed is certainly a problem, but the main thing is that they go through, and that the problem is being looked at and assessed and meaningful solutions are being considered and proposed that will address the problem (to the extent that the problem is the same or different or if the attack vector is similar or different).
Your framing this matter as an "emergency" that needs to be fixed right away seems a bit short-sighted, and even bigblocktardy... You know that it is more important that the network is secure and that transactions are ultimately processed than some quick solution is rushed out that potentially either causes additional problems or creates potentially additional attack vectors.
It sounds a bit demanding to bark out orders for devs and suggesting that they better get to work on this right away and a bit patronizing and presumptuous to assert that devs are potentially naive regarding the benevolence of the world in terms of thinking that it is "nice and shiny."
No. Your post is based on the completely wrong assumption that I demand this to be handled as emergency.
I didn't demand and I didn't say it's an emergency.
Read again. I said "take seriously into account". That means "OK, this is something that should get onto the ToDo list at some point too".
You seem to be quibbling over minor and non-sensical points, and in other words attempting to get defensive rather than standing behind the gist of what you said and the tone in which you said it. Makes little sense to me that we should attempt to get caught up in parsing words rather than talking about the essence without any need to get defensive... I am not attempting to personally criticize or attack you, but I am attempting to look into the ramifications and the meaning of what you had asserted.
I know that they have their schedule and I know that they are busy with segwit which may improve some things.
I also know that pushing them brings nothing. And you know that too.
I also know that pushing them brings nothing. And you know that too.
O.k. I surely would phrase it a little bit differently, but it could still be that in some senses we agree.
The essence of the matter is that any changes take time, and we should be able to agree that we do not want to jump into making changes that merely cause more problems or that are controversial concerning what benefits they are going to bring.
The fact of the matter is that Seg wit was largely not very controversial. In December 2015 / January 2016, more or less, guys on both sides of the fence were largely in agreement that seg wit was a good idea and brought a lot of good changes and improvements to bitcoin.
Surely, in recent times, there has been some revisionary framings of the matter and some smaller factions (including some of the big blocker nut jobs) that are suggesting stupid ass ideas that they are wanting to block seg wit unless they can get a blocksize limit at the same time.. blah blah blah .. bullshit and threats of a kind of hostage taking.
The fact of the matter also is that the various proposals to increase the blocksize limit have remained controversial, and those making the proposals have not been very convincing regarding such a change is actually prudent or justified in any kind of meaningful way. In otherwords, they have failed to meet any kind of burden of proof regarding actual factual evidence and they have failed to meet any kind of burden of persuasion regarding logic...
So, yeah, if at some point, there is a need for a block size limit increase, and the burden of proof and persuasion is met concerning the need for it, then at that point the bridge should be crossed (or at least considered to be crossed). We are a long way from having any kind of consensus regarding taking any other steps, besides seg wit, at this point.
As opposed to many people in here, which think that Bitcoin is a coin and has to be used as a coin, I still think of it as an asset.
So for me the speed is not a big issue yet.
O.k... so it could have been that I read too much into what you were saying, yet whether bitcoin is a coin or an asset or a combination of these things, it still does not seem wise to push anything, and make some kind of stupid-ass mistake that messes up the security of bitcoin or even causes a situation in which it can be easily manipulated.
In this regard, difficulties in changing bitcoin is a really good thing, especially since out of the gate there was a lot of already real good features and incentives that has caused a very valuable network that is currently securing more than 10billion dollars and also supporting a pretty decent sized infrastructure that has been growing around it.
I say fuck off to those multiple arguments suggesting that bitcoin should be more easy to change in order to be able to adapt to the times, blah blah blah.. because in the end, bitcoin has already brought it's value and paradigm change in which there is no (NONE) system that even approaches anything close to its secure decentralized value transfer and storage.. I repeat, NONE. So, why screw with a good thing. There are a whole hell-of-a-lot of innovations coming down the pike that are going to take a while to play out.. but bitcoin remains a system that can be built upon, and in the longer run, folks are going to flock to this better mouse trap.. but it could take a while before joe blow realizes that bitcoin is the shit and bitcoin is the better mouse trap and there is no mouse trap like it and never has been a mouse trap like it. The peaking of over 2 petahashes of computing power is surely demonstrating that bitcoin has the capability to continue to stave off attacks and to secure value as the backbone, and systems can be built upon it (at a second layer level).
However, many think that Bitcoin should be used as a word wide currency, paying for goods in shops, which, with the current problems, is just a nice dream yet.
...just my 0.00000002BTC
I agree with you that these kinds of micro- currency applications are going to come with time, and we do not need to rush into them because there are more important things (and that is the security of the network and the value security overall).. In time, there are going to be all kinds of systems that are going to allow for micro transactions and even volume transactions, but those are going to take time to evolve to take place on top of bitcoin.. whether on the chain itself or at a second or third level through various layers on top of the underlying secure, decentralized and immutable system, aka our lillie fiend bitcoin.
If those transactions don't get confirmed and returned to their senders' wallets, so many shit on its way waiting for us. If bitcoin can be stopped in this way there is no way for that serious business owners will accept bitcoin again for a payment method. I hope it gets fixed soon.
If the spam attack ends, the network will be like new until Saturday or Sunday!
But you have a valid point there, the network needs some big fixes, one being to filter out these attacks somehow and quick.
The normal mempool used to be up to 4MB and during the last attack it rose to 40MB.
Devs have to take seriously into account that the world is not nice and shiny, Bitcoin also has enemies and people that try to profit from any weakness they can find.
I will agree with you that having transactions delayed is certainly a problem, but the main thing is that they go through, and that the problem is being looked at and assessed and meaningful solutions are being considered and proposed that will address the problem (to the extent that the problem is the same or different or if the attack vector is similar or different).
Your framing this matter as an "emergency" that needs to be fixed right away seems a bit short-sighted, and even bigblocktardy... You know that it is more important that the network is secure and that transactions are ultimately processed than some quick solution is rushed out that potentially either causes additional problems or creates potentially additional attack vectors.
It sounds a bit demanding to bark out orders for devs and suggesting that they better get to work on this right away and a bit patronizing and presumptuous to assert that devs are potentially naive regarding the benevolence of the world in terms of thinking that it is "nice and shiny."
No. Your post is based on the completely wrong assumption that I demand this to be handled as emergency.
I didn't demand and I didn't say it's an emergency.
Read again. I said "take seriously into account". That means "OK, this is something that should get onto the ToDo list at some point too".
I know that they have their schedule and I know that they are busy with segwit which may improve some things.
I also know that pushing them brings nothing. And you know that too.
As opposed to many people in here, which think that Bitcoin is a coin and has to be used as a coin, I still think of it as an asset.
So for me the speed is not a big issue yet. However, many think that Bitcoin should be used as a word wide currency, paying for goods in shops, which, with the current problems, is just a nice dream yet.
...just my 0.00000002BTC
And you can erase the main protagonist ... with the natural rise of the network (mining power) after (very) few months.
http://bitcoin.sipa.be/
http://bitcoin.sipa.be/
Thanks for your condescending tone!
Please don't clutter up the thread with huge quotes. I hope that meets your expectations on netiquette.
I believe the risk of not increasing the blocksize modestly (congestion) is greater than the risk of node count lowering (centralisation).
Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.
Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.
Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.
Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.
Well, 2MB or 4MB is exactly what the new soft fork in 13.1 is delivering. It's got more support than any of the other forks that weren't adopted, and makes Lightning possible. Without getting rid of sig malforming, Lightning doesn't work.
Problem is with bitcoin core at under 90% now and they need 95%to approve Bitcoin unlimited and others have
Stated they will not allow activation of seg witness without a hard fork. This gonna get much worse
On more big pumps in price. Also if that is the case Bitcoin core will lose more share. Stalemate. It is gonna suck without some consensus which I don't see happening
You are sounding overly pessimistic, Searing.
As we know segwit just went live, and it would be economically against the interest of the miners to play around with bullshit leveraging of a fairly non-controversial fix and a positive implementation. The ones that attempt to hold out are likely hypocrites and also acting as terrorists (or is "hostage takers" a better term?) in order to attempt to get their whinny way about something (a hard blocksize limit increase) that is not necessary or even beneficial for bitcoin.
I could be wrong but I don't think it would be profitable enough and too time consuming for the miners to spam the network just to receive a few higher fees.
I agree to that. It's not the miners.
But I've already seen posts about double spends, for example. Some do profit from this situation and I feel like they're more than usual.
I would still like to hear a better theory for this than the possible spam attack.
It could easily be "opportunistic piggy-backing", i.e. there is a real surge in transactions taking place due to the buoyancy in the exchange rate we have right now, and a spam artist decided to use the opportunity to increase the pressure on the mempool.
What is the supposed, "quick solution?" Segwit is out, and it has been vetted.. You want to change the course because of some kind of asserted need for quickness? I would think that it is better for solutions to be considered and vetted rather than rushed because of some kind of urgent and unsubstantiated need that could cause additional problems or attack vectors and may well not fix the supposed problem, no?
Seeing a peak is not a proof of spam attack.
There is never any proof, short of the person transacting saying "it's a spam attack".What we do have is an interesting change in transaction behavior reflected in the UTXO set: https://blockchain.info/charts/utxo-count?timespan=60days which coincides with the flood of higher fee transactions starting and stopping.
Hi Gmax....
I'm not sure if I understand the significance of the UTXO... Is there a way to phrase the spam versus legitimate transaction significance of such in layman's terms? It appears that blockchain.info has only been keeping charts of them since May 2016, and in essence we see a ongoing increase in these until just a few days ago with a dip.
I personally thought that the dramatic mempool size increase https://blockchain.info/charts/mempool-size?timespan=1week was a decent indicator to lead to a reasonable inference that shenanigans was going on (in terms of spamming or attempting to sabotage the bitcoin network), rather than legitimate transactions that come out of a kind of organic growth or even normal spikes in regular kinds of transactions.
If those transactions don't get confirmed and returned to their senders' wallets, so many shit on its way waiting for us. If bitcoin can be stopped in this way there is no way for that serious business owners will accept bitcoin again for a payment method. I hope it gets fixed soon.
If the spam attack ends, the network will be like new until Saturday or Sunday!
But you have a valid point there, the network needs some big fixes, one being to filter out these attacks somehow and quick.
The normal mempool used to be up to 4MB and during the last attack it rose to 40MB.
Devs have to take seriously into account that the world is not nice and shiny, Bitcoin also has enemies and people that try to profit from any weakness they can find.
I will agree with you that having transactions delayed is certainly a problem, but the main thing is that they go through, and that the problem is being looked at and assessed and meaningful solutions are being considered and proposed that will address the problem (to the extent that the problem is the same or different or if the attack vector is similar or different).
Your framing this matter as an "emergency" that needs to be fixed right away seems a bit short-sighted, and even bigblocktardy... You know that it is more important that the network is secure and that transactions are ultimately processed than some quick solution is rushed out that potentially either causes additional problems or creates potentially additional attack vectors.
It sounds a bit demanding to bark out orders for devs and suggesting that they better get to work on this right away and a bit patronizing and presumptuous to assert that devs are potentially naive regarding the benevolence of the world in terms of thinking that it is "nice and shiny."
Thanks for your condescending tone!
Please don't clutter up the thread with huge quotes. I hope that meets your expectations on netiquette.
I believe the risk of not increasing the blocksize modestly (congestion) is greater than the risk of node count lowering (centralisation).
Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.
Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.
Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.
Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.
Well, 2MB or 4MB is exactly what the new soft fork in 13.1 is delivering. It's got more support than any of the other forks that weren't adopted, and makes Lightning possible. Without getting rid of sig malforming, Lightning doesn't work.
Problem is with bitcoin core at under 90% now and they need 95%to approve Bitcoin unlimited and others have
Stated they will not allow activation of seg witness without a hard fork. This gonna get much worse
On more big pumps in price. Also if that is the case Bitcoin core will lose more share. Stalemate. It is gonna suck without some consensus which I don't see happening
Low fees (micro payments)
decentralized
secure
Pick 2.
decentralized
secure
Pick 2.
users cry for a waiting time of 12h and less than 36h.
ask at the bank to do the same job ... try ...
ask at the bank to do the same job ... try ...
Explain, given how it satisfies all your stated expectations, why Segwit shouldn't get adopted. You're sounding a little negative, Scott.
Have another read, where did I say it shouldn't be adopted? How about where you say "let's increase the blocksize before Segwit". I think you don't really get what the schedule is or what any of it means.
Mempool is empty, thank for your time.
Lol, and the miners say thank you for the fees
Mempool is empty, thank for your time.
That is good news.
Mempool is empty, thank for your time.
Explain, given how it satisfies all your stated expectations, why Segwit shouldn't get adopted. You're sounding a little negative, Scott.
Have another read, where did I say it shouldn't be adopted?
Explain, given how it satisfies all your stated expectations, why Segwit shouldn't get adopted. You're sounding a little negative, Scott.
Well, 2MB or 4MB is exactly what the new soft fork in 13.1 is delivering. It's got more support than any of the other forks that weren't adopted, and makes Lightning possible. Without getting rid of sig malforming, Lightning doesn't work.
Only for transaction that meet the SegWit format - we will see how much of a saving it really is if it gets adopted. Thanks for your condescending tone!
Please don't clutter up the thread with huge quotes. I hope that meets your expectations on netiquette.
I believe the risk of not increasing the blocksize modestly (congestion) is greater than the risk of node count lowering (centralisation).
Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.
Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.
Do you believe 1MB is exactly right? If layer one is really that exhausted then surely we should lower it? I find it funny how so many people say we should not increase, but so few say we should decrease. 1MB was arbitrarily chosen after all.
Right now I see full blocks as a bigger problem than the number of nodes. 2MB or even 4MB gives us enough time for Lightning to be ready.
Well, 2MB or 4MB is exactly what the new soft fork in 13.1 is delivering. It's got more support than any of the other forks that weren't adopted, and makes Lightning possible. Without getting rid of sig malforming, Lightning doesn't work.
Wow lots of unconfimed transactions, relax they will confirm somehow...this is good ....indicates world are using bitcoin...
Someday, any time, somewhere
Blocks are probably full due to the price increase. That move surprised all the ant colony and now everyone is rushing 
!
!What if behind it is hidden a direct correlation? Price increases, but the majority can not sell because of the fact that they can not move their coins to sell it? So let's say only those who controls all of this can skim the cream...
Jump to: