Or a QR code that contains the file.
Wouldn't the certificates, plus the invoice memo field (which could include long contract terms) be too large for a QR code? |
|
|
|
P2SH is itself a script so you can already do that. I mean it would be easy to just provide the 20 byte bitcoin address in the invoice rather than an entire script. P2SH addresses would allow for any script to be used, but only an address would be needed in the invoice. A signed invoice and accepted transaction together are indeed proof of payment. The SignedReceipt message was deleted in a later version of the proposal.
That makes much more sense. And one should think about how a merchant provides these invoices. It could be a downloadable file or it could be a QR code with a URL to download a file. |
|
|
|
I support this idea and I have thought about this myself previously. This will especially become handy with Extended Validation certificates as you can show proof of identity for a business. script: a "TxOut" script to which the customer should direct payment.
This will normally be one of the standard Bitcoin transaction script
(e.g. pubkey OP_CHECKSIG). Why not use a P2SH as the output, instead of the entire script? Makes it very simple. And why not just accept an invoice as paid when the funds have been received? You can use a unique address for this. The proof of payment is then stored in the block-chain. That would be simple and I do not see the reason for complicating it with this Payment and Receipt message. So you just pay to the address on the invoice. If the merchant says "We have not received the funds" you can give evidence that you sent the funds by showing the transaction in the block-chain which conforms to the amount requested and P2SH given in the Invoice. |
|
|
|
Everything Adolf Hitler did in Germany was legal
Why did he go to prison? He died. I'm talking about the coup d'etat, and the prison sentence Hitler got as a result. I'm talking about everything he did in the Nazi Germany. Don't get distracted. He broke international law, does that count to you? |
|
|
|
Everything Adolf Hitler did in Germany was legal
Why did he go to prison? He died. I'm talking about the coup d'etat, and the prison sentence Hitler got as a result. |
|
|
|
Everything Adolf Hitler did in Germany was legal
Why did he go to prison? |
|
|
|
jgarzik is quite right. The SHA-256 algorithm is property of the US and export regulations for SHA-256 expressively forbid exporting the algorithm or products based on the algorithm to Iran.
What if you are not a USA citizen? Will the US government still drone bomb you, if you provide SHA256 to Iranian citizens? |
|
|
|
|
Take a look at strcpy(), it includes a termination character when copying.
|
|
|
|
It wouldn't be as fun without halving day.  |
|
|
|
Do I understand it right now?
Yes, I was thinking along those lines. the difficulty should be calculated after every block
yep, based on a rolling 2-week / 2016 block period. No reason why not to do this, it should keep the difficulty more stable this way because much could happen in 2 weeks. |
|
|
|
|
If you could figure out the expected block height (for all time), the actual block height and the block rate over the last 2016 blocks then...
1. Add 2016 to the expected block height and take away the actual block height to get the number of blocks desired.
2. Determine the expected number of blocks to be created at the current rate.
3. Adjust difficulty to make expected rate hit the desired number.
4. Limit difficulty change to prevent large changes.
So if we have a difficulty change at block 2016000, and 2001 weeks have passed then we expect to be at block 2017008. Let's say over the last 2016 blocks, they were created at 8 blocks an hour. We need to reach block 2017008 + 2016 in two weeks time which is block 2019024. This is 3024 blocks more than 2016000, so we want 3024 blocks. This means we want a block creation rate of 3024/(14*24) an hour which is 9 blocks an hour. To try to get this rate we can adjust the difficulty by 8/9 = 0.889.
I probably explained that terribly but hopefully I got across the general idea. I didn't think about it too much and it is indeed academic, it doesn't matter.
|
|
|
|
If I designed the difficulty algorithm I'd look at the time taken from block 0 to the current block and compare it to the number of blocks times 10 minutes and adjust difficulty that way. So instead of the difficulty adjusting to the rate, the difficulty adjusts to the expected number of blocks for all time.
Intriguing. Seems to me it would work. Of course it would've had to have been introduced from the beginning. Yes. It's just another way it could have been done so I was being academic. |
|
|
|
|
If I designed the difficulty algorithm I'd look at the time taken from block 0 to the current block and compare it to the number of blocks times 10 minutes and adjust difficulty that way. So instead of the difficulty adjusting to the rate, the difficulty adjusts to the expected number of blocks for all time.
|
|
|
|
^^^ Depends on who gets there first. If NASA or a coalition of governments, then our laws. If some corporation that is mainly interested in mining or operating a low G space depot, then whatever corporate law they use.
And the race is on!  The Bitcoin Foundation should join the race, to get bitcoin on Mars. |
|
|
|
is this big and little endian compatible?
Yes it is, or at least that is the way it is designed to be. It's only been tested on a little-endian machine so feel free to try it out on a big-endian machine. |
|
|
|
|
The latency between Earth and Mars would be a few minutes to over 20 minutes and communications would probably come at a premium. You are better off having a separate block-chain and call it MarsCoin or something.
|
|
|
|
|
Thanks Pieter. The purpose of this proposal is not focused upon detecting invalid blocks. It's focus is upon the parrellel downloading of blocks from multiple peers. Providing that the decrease in time that it takes to transfer the segments from multiple peers, as opposed to the entire block from one peer, is more than the additional latency added (for obtaining merkle tree data and whatever else), this can be beneficial. The proposal was suggested in response to fears about "What if blocks get really big". Of-course, this proposal becomes more and more beneficial, the bigger blocks get.
I asked for some network data about latency times and transfer rates to try and determine just how big blocks would have to be to benefit from such a proposal but I do not have that data. There will be variation within the network, I know.
The main criticism I have got is "Blocks will never get really big because we will always limit them" so it's a waste of time to consider this. Well, that is a major issue: what do we do about the block size limit?
For larger pieces of data parrellel downloading is certainly beneficial in p2p networks as can be seen with bittorrent.
So yes, I do not think I properly explained the purpose of this proposal, which is to enable parrellel downloading of blocks in smaller data segments such as with bittorrent. I call them segments because calling them "data blocks" would cause confusion with "bitcoin blocks".
And I do not suggest that this proposal is important right now. I was thinking about the future and the increasing demand for block-space.
|
|
|
|
|
Show Posts
