Today when someone buys a cup of coffee from Starbucks with their credit card, it is Starbucks that bears the costs of accepting the Credit Card. I don't see why it should be any different with Bitcoin, so Starbucks could receive a payment with a very low/no fee and then could use a CPFP transaction with a sufficiently high fee to get both transactions to confirm.
Credit cards are a pull system where the merchant is taking money rather than giving them money. Bitcoin is a push system where you give merchants the money. Bitcoin puts the onus of sending transactions and getting then confirmed on the sender, not the receiver. Thus it stands to reason that bitcoin continue with that idea and put the burden on the sender and not the receiver. However, I am not averse to CPFP transactions. I think it would be better if we had both RBF and CPFP enabled so that both senders and receivers can do something to get their transactions confirmed. |
|
|
|
I think that it's always been a hopeless effort, but some services try to predict when 0-conf transactions are high-risk using a number of network nodes listening for double-spends and other such things. For these, it's a simple matter to check for the RBF opt-in and treat these transactions as automatically high-risk.
I feel like most people are imagining that with RBF there's going to be a button in wallets that says "take back this money", but that's very unlikely. Right now you have to use createrawtransaction to send a RBF-enabled transaction, and in the future there will be a button to increase fees (or something), but I really doubt Core is ever going to provide an easy UI for fraudulently double-spending. As is the case today, 0-conf transactions will often work despite being totally insecure because a large percentage of people are honest, and of those who are dishonest, a large percentage of them haven't bothered to figure out how to double-spend.
Wouldn't it be possible for someone to sign a transaction that relies on input x, and has a "high" fee, save this transaction to a text file (or wherever), then sign a separate transaction that also relies on input x and has a "low" fee, and has the appropriate flags that "enable" RBF, and broadcast this transaction. Then they could simply use "sendrawtransaction' (which is significantly easier to use then "createrawtransaction" imo) to broadcast the conflicting transaction.
What's the point of broadcasting the conflicting transaction? Since the network would have already seen the first one with RBF enabled, if the conflicting transaction doesn't have RBF enabled, then AFAIK it will be rejected as a double spend. I really doubt Core is ever going to provide an easy UI for fraudulently double-spending This doesn't mean that others will not write guides on how to fraudulently double spend transactions, and that people will not design wallets/programs to help people fraudulently double spend transactions.
From what I understand RBF is similar to CPFP in a sense that both share the same goal of getting a transaction to confirm that would probably not otherwise confirm. However there are potentially fraudulent uses for RBF while there are not (that I am aware of) for CPFP. Additionally CPFP puts the "burden" of the cost of getting a transaction confirmed on the receiver, which is generally the status quo for retail transactions (especially those involving credit cards), which consumers are used to, and often demand. I am having difficulty finding reasons why RBF is better then CPFP and/or RBF is being implemented in core while CPFP is not supported (for the most part). In most cases, what I have seen is that the sender usually wants the transaction to confirm, not the receiver although both do happen somewhat frequently. Many times the receiver doesn't care about the transaction as it might just be a deposit which the sender wants done quickly. With CPFP, there may not be any change addresses for the sender to use to attempt a CPFP. RBF allows that. Also, CPFP adds additional transactions to the blockchain and to mempools while RBF will not thus helping to reduce blockchain bloat. |
|
|
|
So can we avoid all this just by saying "only accept confirmed payments" ?
Yup |
|
|
|
|
You can use the flag -maxuploadtarget=<n> to set a maximum upload where <n> is MiB per 24 hours. You can also use -maxconnections=<n> to limit your connections where <n> is the maximum number of connections possible.
|
|
|
|
|
There is no automatic method of dealing with such a situation since such a situation is unlikely. Should the internet go down, we have much bigger problems to worry about than just Bitcoin fragmenting.
There is actually no way for a node to know whether the network has fragmented due to internet disruptions. How would a node distinguish between miners getting blocked, miners hardware failing and thus unable to mine, miners choosing to stop mining, or simply bad luck? There is no way for a node to know that there was a disruption.
Furthermore, a node doesn't know about the number of nodes online. The only way to know that would be to maintain connections to every single node, which a node is not able to do. It requires too many resources.
Bitcoin should not cater to this since such an event would be incredibly rare. Even if internet censors were blocking connections, methods of bypassing that through Tor and proxies will still bypass those filters and allow nodes to connect through firewalls, albeit slowly. Even so, miners could communicate with others around the firewall and a plan could be worked out to prevent the fragmentation of the network.
|
|
|
|
Is the account signed in any signature campaign? Specially the ones with no open spots now
Unfortunately it is not. |
|
|
|
|
Screenshot of the error? Can you post the logs?
|
|
|
|
If this is correct then what is the disadvantage of RBF? The free market for transactions fees is created and merchants that want to keep allowing 0 conf transactions without risk can just exclude those who use the RBF flag.
There is no disadvantage, but people don't realize this. All they do is spread FUD about this and not understand what it is actually doing. |
|
|
|
lol mate... you really totally lost me here... i'm not that techincal on BTC ;-) I do think i did send with enough fee though.
No, you did not send with enough fee. The current fee, according to this site: http://www.cointape.com/#delay, is around 40 satoshis per byte. You sent it with a 10,000 satoshi fee, and it is 976 bytes. This means that the fee is roughly 10 satoshis per byte, not nearly enough to get confirmed in a short amount of time. Oh i just had it set to standard fee like i always do.... anything i can do to get it confirmed in a short amount of time? Thx for the help by the way! You have 1 conf now. |
|
|
|
lol mate... you really totally lost me here... i'm not that techincal on BTC ;-) I do think i did send with enough fee though.
No, you did not send with enough fee. The current fee, according to this site: http://www.cointape.com/#delay, is around 40 satoshis per byte. You sent it with a 10,000 satoshi fee, and it is 976 bytes. This means that the fee is roughly 10 satoshis per byte, not nearly enough to get confirmed in a short amount of time. |
|
|
|
Here is the RAW transaction: 0ec652f384b3889ff324bff673081d700cf24a7b6001e090895d7ca52f0fe372: Seen by 6 peers. Pending/unconfirmed.
in [3045022100b0ffed852731ddf394f6589a61065942b0ee82de35af7c325041f47ca5aeae2f022070fbb37fbd1413ae17a62f43c90498bed45fd827a25c4cffb1dc0ab79fa7010201] [047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686]
outpoint:4723e0cb560905a23128a7acd1c22a026061d49c3241720bdd96d23c1df86439:0 hash160:952ed9786a4ed2c7753b26fa224c1d1ca7f2d241
in [3044022048a946633ce2eeb896b851658163baa9f27713659ee9138f05bae24813e23f4802200d355ccd17b8f1c3ca83e118c937d1e0481faf59ae44079fc5a7b45b201796dd01] [047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686]
outpoint:438a1c3170636d77afe94e7aecefa6dfe1d3a513065b90df0d5002f7b31de814:1 hash160:952ed9786a4ed2c7753b26fa224c1d1ca7f2d241
in [3045022100d8101aa0d1d9845e0024375e3ca173aec40d3f33fb30a00e9cc2161fd2d38e450220266a516dd06d0ab63e246a681bbfe09ee2eae56168fe45b40180b352eb9e5bda01] [047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686]
outpoint:f4362ab07e1f35de075352e4a803ed49d449bade72a2f3562603df30020c8f9b:1 hash160:952ed9786a4ed2c7753b26fa224c1d1ca7f2d241
in [304502210096ff8385859f2ad56d90895479f45d43faa98a18b445a43c99f27dc3c06546f5022046492ef4afc51f252d550ece265f5945aa1eec5623daf74ac22a19e2bf82d51c01] [047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686]
outpoint:0e0b1b6162e21882fc120084b39f641dda4f9495a0fc65a62c4a3658de6ca90a:0 hash160:952ed9786a4ed2c7753b26fa224c1d1ca7f2d241
in [3044022058f95347847316b7d1d78ecf22e105da53fc4b187fc605c47f641c21097b733402207a3dde124536013bf40cef42f2c96aeeddb4956629830420795fc5e6c7e297ee01] [047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686]
outpoint:7bf228020238da1a33c797582c2c1c4db891f3505e9ee6c88311f9b5557dc9d1:1 hash160:952ed9786a4ed2c7753b26fa224c1d1ca7f2d241
out DUP HASH160 [31e5b2f4583d6f1d9f2b6fea0ae521fdc56c0301] EQUALVERIFY CHECKSIG 0.01298087 BTC
out DUP HASH160 [952ed9786a4ed2c7753b26fa224c1d1ca7f2d241] EQUALVERIFY CHECKSIG 0.0027956 BTC
Anybody? Not raw enough. Needs to be just hex code, not this which is broken down. This is the raw transaction: 01000000053964f81d3cd296dd0b7241329cd46160022ac2d1aca72831a2050956cbe02347000000008b483045022100b0ffed852731ddf394f6589a61065942b0ee82de35af7c325041f47ca5aeae2f022070fbb37fbd1413ae17a62f43c90498bed45fd827a25c4cffb1dc0ab79fa701020141047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686ffffffff14e81db3f702500ddf905b0613a5d3e1dfa6efec7a4ee9af776d6370311c8a43010000008a473044022048a946633ce2eeb896b851658163baa9f27713659ee9138f05bae24813e23f4802200d355ccd17b8f1c3ca83e118c937d1e0481faf59ae44079fc5a7b45b201796dd0141047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686ffffffff9b8f0c0230df032656f3a272deba49d449ed03a8e4525307de351f7eb02a36f4010000008b483045022100d8101aa0d1d9845e0024375e3ca173aec40d3f33fb30a00e9cc2161fd2d38e450220266a516dd06d0ab63e246a681bbfe09ee2eae56168fe45b40180b352eb9e5bda0141047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686ffffffff0aa96cde58364a2ca665fca095944fda1d649fb3840012fc8218e262611b0b0e000000008b48304502210096ff8385859f2ad56d90895479f45d43faa98a18b445a43c99f27dc3c06546f5022046492ef4afc51f252d550ece265f5945aa1eec5623daf74ac22a19e2bf82d51c0141047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686ffffffffd1c97d55b5f91183c8e69e5e50f391b84d1c2c2c5897c7331ada38020228f27b010000008a473044022058f95347847316b7d1d78ecf22e105da53fc4b187fc605c47f641c21097b733402207a3dde124536013bf40cef42f2c96aeeddb4956629830420795fc5e6c7e297ee0141047609f59375ff4547430124435a5eeb8048d65dbe9708e2f35726cb14bbc29884717241c71c8630a396aa3f80bfc21ff1e38e61e844346ce44db9dc1c1e579686ffffffff02a7ce1300000000001976a91431e5b2f4583d6f1d9f2b6fea0ae521fdc56c030188ac08440400000000001976a914952ed9786a4ed2c7753b26fa224c1d1ca7f2d24188ac00000000 which can be pushed by people (like me). |
|
|
|
I was thinking of this site of yours yesterday with people saying they are number so and so in the queue and some complaining that they have been waiting hours [including me], in any case, I was wondering, how many hits/requests do this site process each day?
I think it would be quite interesting if you don't mind to share it. I believe it to be much higher than we think it might be.
I don't have stats on that now because I forgot to enable the ads (just did that though) which took the stats for me. Previous stats show I got somewhere between 50-100 impressions per day with only around 20 unique visitors. |
|
|
|
In the bitcoin.conf file, add lines with where <node ip> is the ip address of the node you want to connect to. That way, when you start up Bitcoin Core, it will always attempt to connect to those nodes. It is for my wallet of CorgiCoin. But when i look in my map roaming, i don't find a conf file there. If it doesn't exist, make one. |
|
|
|
the transaction id is
1bb734cef0951526d490cb0e86056aafd440cb04877eaee1537865fe701a3207
f603bbd3ab4201b3660a8565584c77d4c36e3eb611089354491ccd8124c2f6a6
d32b14255163f0100ade24855de3b5ea3d27c8c1e81cff182ee6c684563b497e
is there nothing I can do at all because I cant send any coins, even if I have some btc in my wallet, it will be stock again if I try
There is absolutely nothing you can do. Those transactions are part of a large chain of unconfirmed transactions. I think the beginning of that chain is probably a double spent transaction which will never be confirmed because a different transaction spending those same inputs was confirmed. There is nothing you can do about this except to forget those transactions ever existed. |
|
|
|
In the bitcoin.conf file, add lines with where <node ip> is the ip address of the node you want to connect to. That way, when you start up Bitcoin Core, it will always attempt to connect to those nodes. |
|
|
|
When I wanted to check a transaction it goes to white screen saying: Maximum connections have occurred. Never seen that in my life.  What is happening to blockchain? Is it too much transactions for it too handle at one time  It just means that blockchain.info has too many people trying to look stuff up. I get it all the time. Just wait a couple seconds and it should go away. |
|
|
|
My hard drive died. I had backed up my wallet.dat file. I installed Bitcoin core on a new computer (it will take forever to sync). I started Bitcoin core, then exited, then replaced the wallet.dat with my back up version. When I open Bitcoin Core again, the wallet is empty. It doesnt show any addresses either. Please tell me I havent lost my bitcoin.
Wait for it to sync. If it isn't synced, it doesn't know of your transactions yet, so just let it sync. When it is done, then you should see your full balance. |
|
|
|
|
There is nothing you can do about those unconfirmed transactions. They cannot be deleted or spent from. You can either wait for them to confirm, or wait for blockchain.info to drop those transactions from your wallet in a few days. After they are dropped from the network, you can resend them with a higher fee if the fee was causing the problem.
Can you post the transaction ids?
|
|
|
|
|
Show Posts
