OK, thanks for the explanation. That's indeed a valid counter-argument. According to the blog post (as I understand it) the Payment Protocol can be used via Tor/VPN, but the merchant in this case can refuse payment if he detects this. Is this correct?
I took a superficial look at the developers' guide and haven't found a statement that the IP address is necessary to confirm validity of the payment. If my understanding is correct, merchants could use the Payment Protocol "the right way", without forcing users to reveal their IP address. However, the fact that the Payment Protocol requires a direct connection between wallet and merchant server (without routing through the Bitcoin network) isn't ideal. Wallets can offer easy-to-use Tor/VPN assistance but it adds hassle for a non-expert user that wants to stay anonymous.
I'm not sure if the merchants have any say in this, but the breakdown is this: If Bitpay detects you are making a connection through a VPN or Tor, they will not call back and make it impossible for you to pay your invoice until you reveal your IP. That is, similar to how one may get Cloudflare CAPTCHAs when browsing with Tor, in this case the BIP70 server simply denies your connection. This is unrelated to how you as a developer would implement their API. Working on the application level, you don't know anything about which connections the underlying server decides to block. The thing is, I understand if credit card providers or banks don't want Tor users to access their pages (if they do block them, never tried it), but a BIP70 server that merely serves payment metadata? Seems kinda unnecessary, especially given the fact that payments could still be easily accepted if they had simply continued providing the advanced payment mode. |
|
|
|
Counter-argument: BIP70 deanonymizes users and should not become the de-facto standard for Bitcoin payments. I guess it de-anonymizes the payee/merchant only, right? Anyway, I would like it to become supported by all major platforms and wallets. In cases where the payee is already known, like in the case of exchange deposits and merchant payments, this "de-anonymization" should be no issue. No, I'm indeed referring to the paying party. Problem being that while the invoice pages themselves are usable via Tor, BIP70 is not [1]. Therefore unless you get out of your way to protect your privacy they can unnecessarily track your IP address. [1] https://blog.bitcoin.org.hk/bitpay-is-using-the-payment-protocol-to-take-your-privacy-8093bf91eda7Of course, the most simple way of transacting (manually entering amounts and addresses) should always be allowed, too. Here I agree that BitPay - and all merchants - should offer it as a fallback method, also for people with hardware wallets. But the Payment Protocol could be highlighted as the "recommended" way.
That's exactly what BitPay did for a while... IIRC they offered BIP70 and the "old way" in parallel for quite some time. By default you would get an easy to use QR code / invoice link but then also a small hidden link to an advanced payment mode with a big fat warning that you should absolutely know what you are doing. In my opinion this was the best of both worlds, easy payments by default but also a non-obstrusive fallback method for more experienced users. Alas they decided to get rid of the advanced payment link, a move which at least to me seems rather arbitrary. |
|
|
|
BACK LATER
---
MICE SLEEPING D'awww Looks like a fun project, I'll keep an eye on this thread and hope to soon see a live race. Treat those little champions well!  |
|
|
|
I like Bitpay's Payment Protocol ( BIP70) - it is - in theory - very easy to use because the merchant you want to pay generates something like a "pre-transaction" you simply import to your client and it will transact the Bitcoins to the correct address. As you only see the correct payment receiver in the wallet if you imported it correctly, there is practically zero risk to do it wrong. So it's just the method non-experts need ... [...] Counter-argument: BIP70 deanonymizes users and should not become the de-facto standard for Bitcoin payments. As such I dislike BitPay having made BIP70 their obligatory means of payment without any fallback method (apart from using external scripts such as the one by achow101 [1]). I fully agree though that it absolutely does improve user experience, I just wish it wouldn't be the only option offered by BitPay. [1] https://github.com/achow101/payment-proto-interface |
|
|
|
Of course not, but for example, the Electrum is the only computer wallet i know that supports RBF (Replace By Fee) function, i dont know other computer wallet that supports it and i had some big problems in the past not doing RBF supported transactions, so, if id like to do RBF support transactions i can only use Electrum, what type of decentralization is that?
Bitcoin Core has been supporting RBF since 0.12: https://bitcoin.org/en/release/v0.12.0#opt-in-replace-by-fee-transactionsGreenAddress also supports RBF: https://greenaddress.it/en/faq.htmlArmory: https://btcarmory.com/0.96.0-release/And probably some other wallets as well that I'm not aware of. So there you go, RBF choice galore. And that's just desktop. I should have the possibility of using bitcoin core node wallet, without need to install the full node or prune, because i dont even have a good internet to install it. This way bitcoin core software would have 3 modes of running, full node mode, prune mode and wallet mode.
Maybe some time in the future, if there's demand. I've got a feeling that there's more important things to tackle in Bitcoin development than yet another SPV wallet. Until then there's plenty of other open source choices with great track records. |
|
|
|
I know 0.00000000000000000001 its possible, but its not pratical and human, im not trying to go back to traditional banking system and i agree with you that USDT its a scam, but if we could turn bitcoin payments more human stopping using a lot of decimal parts why not?
If in the end of the 21 millions we make one airdrop to double the bitcoins of everyone or multiply by 100000000 that dont makes any difference and the bitcoin would look more easily to normal people figure out is value, if you could buy almost exactly the same things with one bitcoin and 1 dolar you will have a better idea of the money you are wasting without doing calculations 0.00001 x $5700 = ?
As mentioned above: Hence why you got mBTC, uBTC, Satoshis, etc. The question of terminology of fractions of Bitcoin is long solved and a non-issue.
The usage of mBTC (ie. 0.001 BTC) is already fairly common. I think some wallets even default to displaying your balance in mBTC rather than BTC, precisely to get rid of those decimals  Currently mBTC 1.00,- equals USD 5.43,- which is not much different from calculating foreign fiat currency exchange rates. For smaller amounts you can use uBTC (sometimes called bits) with uBTC 1.00,- currently equaling about half a penny. Then there's sat (satoshis), msat (millisatoshis)... and just like that you get ever smaller, manageable units of account. |
|
|
|
However, if the structure of the wallet.dat was fundamentally changed on disk by compressing it (using an archiving tool like WinRar)... Or by encrypting the file using an external encryption tool... Or "hiding it" in another file using stenography... Chances are that finding that data will be next to impossible as it will just look like any other random block of data of disk.
It depends... if OP used a steganography tool or something like a hidden encrypted volume than there's pretty much no chance of finding the file (which is the whole point of steganography and hidden volumes after all). If OP merely renamed the extension of a zipped wallet file it should be possible to scan the files for meta data indicating a file archive (ie. zip utilities don't try their hardest to hide). |
|
|
|
Just to be clear, I think bitcoin.COM recommends the "Electron Cash" wallet. I think bitcoin.ORG recommends Electrum. IIRC, Electron is for Bitcoin Cash, Electrum is for Bitcoin.
That is correct. Electr um is the Bitcoin wallet, Electr on is the Bitcoin Cash fork. Be sure to get the correct one. I read that we can use prune mode, but prune mode needs for about 10GB, so, that is not solution and prune mode keeps validating transactions, but many people (my case) only search for a trusted wallet and some existing software wallet recommended by bitcoin.org could be easily compromissed.
Unless something changed since SegWit the minimum requirement for a pruned node is 550MB (ie. prune=550), not 10GB. You still won't get around downloading and verifying the whole blockchain first though. As far as SPV wallets are concerned Electrum is the most trusted however. |
|
|
|
When you say that you hid the wallet.dat in a file what exactly do you mean? Did you put it in an archive together with pictures, MP3 files, used an icon changer to change its appearance and used winrar to archive it? I'd like to know this too Depending on what you did, pywallet can be used to search the entire partition. Don't forget to create one or more backups before continuing your search. I think I used Winrar but I'm not sure, it was a long time ago  So you used something like WinRar / WinZip / 7zip to compress the file and then changed the file extension? If so, did you also use a password or did you merely zip the file? |
|
|
|
|
I'm not sure whether I'd actually use it, but I think that's pretty damn neat. Looks slick, works fine (at least for me), quick sign-up process... good luck, if it takes off it might just make crypto more attractive and accessible.
Also it was nice to see that satoshi's page was still up for grabs ;p
|
|
|
|
The amount of people with bitcoins in pocket is relevant for Metcalfe's Law, if one guy have all the 21 million bitcoins is value is $0. Sure, but that's not even remotely the argument posted above. As long as a unit of account is fungible enough to be divided amongst any number of market participants, the unit of account itself doesn't matter. Bitcoin, being digital, is pretty damn fungible. After 1 million guys died and lost the bitcoins the other guys will not split and share for free. Neither would the miners reclaiming recycled coins. Regardless of that, anyone holding a share of the total currency supply wouldn't lose anything. Quite the opposite actually, their share just grew. Anyone not holding a share of the total currency supply would need to work for it anyway. That's the economic system we currently live in. The only ones losing shares of the total currency supply are the people that died; and they will hardly care anymore. Metcalfe's Law says that if you split your bitcoins with all the other guys in the world in the END you will have less bitcoins, but you will have more $, do you see anybody offering bitcoin to the others? They were called faucets and there used to be a lot of them around. That being said, Metcalfe's law says nothing about fiat or even cryptocurrencies. It can be applied under the assumption that an increase in utility of a cryptocurrency results in an increase of price in fiat terms. However the utility increase caused by the network effect, as postulated by Metcalfe's law, is unaffected by where you decide to place the decimal point that constitutes a "coin". As aplistir told, if some guy recover the old address with X BTCs, that would crash the market,
If some guy recovers old coins of his, they are hardly lost coins that are hardly up for grabs, are they? Either coins are gone and lost forever, in which case they don't affect the utility of a digital currency due to its fungibility. Or coins are still accessible, in which case they shouldn't be stolen from their rightful owners. other thing is try to make you excell month expenses with something like this:
Internet: 0.00000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000005 BTC
Energy: 0.00000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000001 BTC
Food:
0.00000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000003 BTC
21 millions was just a number to begin, if bitcoin really rules the world that number can and should be changed to normal integer, that will be much more pratical, even to computer calculations, floating point numbers are not as pratical as integer.
Hence why you got mBTC, uBTC, Satoshis, etc. The question of terminology of fractions of Bitcoin is long solved and a non-issue. |
|
|
|
In the case of cryptocurrencies the amount of coins in circulations is irrelevant to Metcalfe's law as fractions of coins work just as well. What a cryptocurrency deems a "coin" is essentially just a question of where the decimal point is placed. Eg. if you have a network of 100 people it makes no difference if everyone has one coin each (from a total supply of 100 coins) or everyone has 1/100th of a coin (from a total supply of 1 coin). The freeing of diskspace that you quoted from the Bitcoin whitepaper is already implemented and available in the form of pruning (as pointed out by mocacinno). The question of whether a blockchain should get rid of historical blocks in general is a wholly different discussion -- and one not slightly answered as seen in the discussion above. I personally doubt it's a good idea to get completely rid of historical transactions every decade or so. Assuming Bitcoin lives on for generations to come this sort of historical cleansing will likely lead to abuse somewhere done the road. Assuming technology keeps progressing, storing the whole blockchain should remain fairly achievable (as long as blockchain growth is held at sustainable levels). |
|
|
|
When you say that you hid the wallet.dat in a file what exactly do you mean? Did you put it in an archive together with pictures, MP3 files, used an icon changer to change its appearance and used winrar to archive it? Give me some more info please.
Presumably OP used one of the many Steganography tools out there, but you're right, that may not necessarily be the case. OP what tool did you use to hide the wallet.dat file? |
|
|
|
|
As mocacinno already pointed out it would be perfectly fine to run with just 1 BTC in circulation.
Point being, the units of account are completely arbitrary. For the usability of Bitcoin as a currency it doesn't really matter whether all 21,000,000 coins are in circulations or half the coins are lost. "Recycling" old coins is a solution to a non-problem that would only add unnecessary complexity, which is rarely a good idea.
|
|
|
|
Prematurely broadcasted timelocked transactions are invalid and ignored by the network. That's why additional application logic is needed to broadcast the timelocked transaction after the timelock has passed.
They can't be included in a block until the timelock is reached, but I do assume that they stay in the mempool for a while. Still, it makes since that you should keep your wallet running at least until few days before you die, so it doesn't disappear from the mempool. Most wallets, including Bitcoin Core, will keep broadcasting your transaction until it is included in a block. If I recall correctly nodes usually drop transactions off their mempool within 3-4 days or so. Maybe after a bit longer, but definitely a timeframe that's too short to be practical for a dead man's switch. That is assuming a not-yet-spendable transaction is kept around in the first place. Good point about wallets keeping rebroadcasting transactions. In the case of a dead man's switch I personally would probably double and triple check that the wallet does indeed keep rebroadcasting the transaction but if it does you could keep the surrounding application logic at a minimum (if additional logic is even necessary at all). |
|
|
|
That's it. Now he only needs to create a "switch" to spend his coins to the address A whenever he dies. A button on his phone when he's on his deathbed, or something.
That's not a dead man's switch though, that's just a... switch The whole idea behind a dead man's switch is that it's triggered by the inactivity of the dead-man-to-be rather than by a last second attempt to send off a signal (the latter which could faile due to the dead-man-to-be's untimely demise). Make a timelocked transaction that spends his coins when he's a 100 years old, or a 120, some time that he obviously won't reach.
Broadcast it and that's it.. If he decides to spend his coins before that, then do it, otherwise, they'll be transferred to his friend. Prematurely broadcasted timelocked transactions are invalid and ignored by the network. That's why additional application logic is needed to broadcast the timelocked transaction after the timelock has passed. But as a quick answer to you bob123 :
1. HeRetiK's solution also stores the timelocked transaction on a server.
2. You can easily change my solution from "press a button to send the tx", to "press a button occasionally before to prevent the tx from being sent from the server."
My solution also doesn't expose his private keys, or endanger his money, all of those are only known to him. The server holds 2 transactions to addresses he already owns.
The timelocked transaction does absolutely nothing until after the timelock has passed however, that's the beauty of it If the server gets compromised or the software fails for some other reason, a regular transaction would cause the coins to move prematurely. With a timelocked transaction you have the added security of the Bitcoin blockchain. |
|
|
|
|
I'm not sure about the implementation details, but I think the general logic would be as follows:
1) They sign a timelocked transaction using their private key, sending the coins to the target address but not redeemable until date x.
2) The timelocked transaction is stored on your server
3) Before date x arrives, they move their coins to a new address and sign another timelocked transaction using the private key of the new address.
4) Rinse and repeat until date x arrives when your server publishes the timelocked transaction to the network.
This way their private keys never touch the server, they can spent their coins however they like and the owner of the receiving address can't spend the coins until the dead man's switch has triggered.
Alternatively they could also lock a hardware wallet away in a bank tresor and have a dead man's switch email send the passphrase and PIN to unlock said hardware wallet in case of their demise as it's rather unlikely that someone would manage to prematurely get access to both.
|
|
|
|
|
Show Posts
