It needs to be impossible to fake.
what would be gained by faking a transaction message? All it needs to do is let the receiver tie a transaction to a purchase. Someone other than the sender of the transaction can usurp him. ok broseph if you want to believe having a different address for every transaction you receive adds some significant amount of anonymity go right on ahead
Using different addresses helps casual anonymity. For secure anonymity you need mixing transactions. |
|
|
|
@Pieter: I don't think it's too much to ask for a 32-byte hash to tie the transaction with the real world. The actual real-world data will be somewhere else but this connection is necessary to make the transaction meaningful.
32 bytes is way overkill. 8 bytes would be more than sufficient. That is 18,446,744,073,709,551,616 possible hash values, unlikely a hashed receipt or message would incur a collision. And it would also be large enough for a reasonable transaction number. It needs to be impossible to fake. |
|
|
|
|
@Pieter: I don't think it's too much to ask for a 32-byte hash to tie the transaction with the real world. The actual real-world data will be somewhere else but this connection is necessary to make the transaction meaningful.
The amortized cost of storing 32 bytes forever by all nodes is not very high, and can be covered by transaction fees. If anything, we may want to look into how to spread the transaction fees over more than just the first miner.
The receiver can't do anything anyway without the entire network being aware of the transaction (it could be deferred until he wants to spend, but still required), so I don't see the advantage of directly sending transactions.
|
|
|
|
I believe this can be done on the client (or any alternate client) without modifying the network.
As it fetches new blocks it simply updates its ledger, instead of storing the entire blockchain (although it should store say X number of the latest blocks for security).
If the client is not mining, why would it need the entire blockchain?
If the client doesn't have the blockchain, it can't verify transactions. Having just the "balance" is useless because there is no protection against using the same output twice when there is additional balance available. If it is a lightweight client that doesn't verify transactions, and relies on someone else to do it, then it doesn't need to download blocks in the first place, or to know balances. It just needs block headers and relevant Merkle branches. With a hard protocol change you could do something like promoting the summary balance to an effective output which can be spent. |
|
|
|
and the tables for the asking and bidding side are much better than before.
The new ask/bid tables are ok, but they will be much better if the bids and asks are in the same horizontal location. You could have a bid table immediately following an ask table, or make a single table with a clear indication (maybe a colored bar) of where one ends and the other begins. Also, it seems wherever volume@price is displayed, it shows the volume of the last trade, which isn't useful at all. It would be better to show volume today or past 24 hours, or something like that. By the way, the GLBSE forum seems to be down. |
|
|
|
|
1. Going forward bandwidth is likely to be as much of a problem as storage. A client working with summaries will still have to download all new transactions, and thus will be unsuitable for cellular internet connection.
2. If Bitcoin becomes ubiquitous there will probably be billions of used addresses, so summary storage will still requires tens of gigabytes.
3. Rapidly dropping transaction history will limit what you can do with the Bitcoin system.
4. Gains are likely not to be much above what pruning can do.
I don't see how this improves on the (future planned) status quo of full or pruned blockchains on servers, lightweight clients on devices.
|
|
|
|
"even a successful double spend attempt fails 50% of the time"
Divergent series can converge much faster than convergent series, because they don't have to converge. Yeah; I did anticipate it could be read like that which is why I explained it in the next sentence, which you didn't quote... Come on, I was trying to make a joke... I know exactly what you meant, but it was funny and reminded me of Carrier's rule.  |
|
|
|
If all goes well, I will issue 500 new bonds early next week.
The issue price is to be determined, but it will almost certainly be significantly lower than the current highest bid of 0.5 BTC. If the issue functionality will work similarly to how it was in 1.0, high bidders may end up paying more than they could have, so please take this into consideration.
I was asking myself the same question, how will be buy orders filled if you issue new shares at lower price? it might be also the case that they would trade at the issuing price. edit: I should probably read some theory book about trading and how market should work I don't know how it works in the traditional world. In GLBSE 1.0 new issued bonds are sold normally from my account, so they will be matched against existing bids. I asked Nefario once for a feature to force the bonds to be sold at the lower price (which I think is fairer, as bidders will no longer have to worry about new issues); if this is not how it already is in 2.0, I'll remind him of this. |
|
|
|
"even a successful double spend attempt fails 50% of the time"
Divergent series can converge much faster than convergent series, because they don't have to converge. |
|
|
|
|
If all goes well, I will issue 500 new bonds early next week.
The issue price is to be determined, but it will almost certainly be significantly lower than the current highest bid of 0.5 BTC. If the issue functionality will work similarly to how it was in 1.0, high bidders may end up paying more than they could have, so please take this into consideration.
|
|
|
|
I may be wrong; but I don't believe a double spend results in neither spend attempt going through -- it results in one only of the spend attempts going through. So a double spend attempt fails 50% of the time.
The other 50% of the time the successful second spend means that the TX listed as 0/unconfirmed never makes it into a block, and so stays at 0/unconfirmed -- which is exactly what it is.
A successful double spends means that the double spender got the goods he supposedly paid for, and kept his bitcoins. If the receiver waits a few seconds to see if any of his peers knows of a conflicting transaction, there's about 99% chance of discovering a double-spend attempt and refusing to deliver the goods. Thus, double-spend attempts would fail 99% of the time. The double-spender may or may not receive his coins back, but as he got no good, it was not a successful attempt. A nice feature for the client would be a 0/DOUBLESPEND if a second conflicting TX is detected.
Yes. Personally I don't think it would be unreasonable for miners to reject both transactions. There is no risk of DOS on genuine transactions as both transactions are verifiably from the same person (their signature proves it); and they are also demonstrably a scammer.
This is a fundamental protocol change which is not needed and may have unintended consequences. |
|
|
|
|
For your purposes it is instant.
You will receive notification about the transfer within seconds. You will not be able to spend them right away, and if your counterparty is a criminal mastermind with custom software he has a tiny chance of reversing it if you don't wait for a block confirmation.
|
|
|
|
I'll be adding market maker fees, which will allow users to get paid 50BP(they won't pay any fees) when they make buy sell orders to provide liquidity.
Please don't. As I explained in another thread, these don't do anything functionally and just create more confusion and obfuscation. |
|
|
|
Also, another problem with this: trust. If you don't ultimately trust a node that provides the verification hash, and you have no way of verifying the pending transaction list yourself (if you did, you'd just calculate it yourself), you would logically only use a verification hash that includes no pending transactions. Being the only list that can be independently verified without the blockchain, several nodes/websites would gladly publish it, bringing us back to square one.
Additionally, what's stopping people from just publishing H1? Since H1 will always be the same for everyone, it becomes no different from just asking a node what the last block hash was.
The only way around this that I can think of would be if there was a standard method of selecting transactions for the next block and then making it a block requirement, but for obvious reasons that is a bad idea. (not to mention, it'd also be able to solve the problem on its own and not require this anyway)
I don't see why you think people would publish sets that excluded transactions, or why they'd publish H1. Why would I expend resources to generate tokens so _you_ can mine while DOSing the network? That would be counterproductive. The miner can pay the node for this service. Going forward running a node will be expensive, node operators will look for ways to monetize it and others will look for nodes offering services to obviate the need to run a node themselves. Since it's not at all clear that mining tx-free blocks constitutes DoS, there's nothing shady about such an agreement. |
|
|
|
It needs to be greater than the median timestamp of previous 11 blocks ( https://en.bitcoin.it/wiki/Block_timestamp). So you can't make it as early as you want, and making the timestamp early in one adjustment will mean that the span will be longer for the next adjustment. There is a difficulty disruption attack, sometimes called "time warp", allowed by the off-by-one bug, which requires having >50%. It was originally described by ArtForz. |
|
|
|
I'll send you the same amount in BTC to make another payment. It's going to mean that some users get a double payment but no one misses oemail me a bitcoin address to send to.
As far as I can tell I wasn't charged the first time, so a refund is not necessary. It also doesn't seem anyone got paid. I've made a payment again. Seems to be working now, reports on receiving the coupon are welcome. |
|
|
|
I have the greatest respect for slush, but his hesitance to adopt a modern reward method has gone too far.
We discussed switch to double geometric back on November during Prague conference - and you know that it's not *that* simple as it sounds. I played with dgm method a bit, but it is making pool architecture too complicated. Yes. And I suggested shift-PPLNS (or shift-DGM) as an alternative which would work in parallel, but you never contacted me to work on this further. I've been trying to get you to switch to a hopping-proof method since March last year, that is, one year ago. That's a long time to make a critical fix. |
|
|
|
can it be that not migrated accounts are holding the 500 - 353 shares and that screws up the dividend payment?
That's my guess too. |
|
|
|
You can see the divided on the puremining asset page.
That's kind of the problem, there is an entry in the asset page but we don't know if it was deducted and credited properly. Is 0.2BTC a normal dividend payment or a test one?
If you mean the 0.72943025 BTC total paid, it's a real payment. I'm guessing it was registered when I first tried to pay dividend. But instead of paying 0.00206637 each to 353 shares, it should have paid 0.00145886 each to 500 shares. It would be ideal if you can make sure the other 147 shares get paid. If all else fails I can do another 0.72943025 BTC payment, but I want to be reasonably assured that it will be distributed to everyone, including those who haven't migrated yet. Was a dividend really paid at all? I'm not sure it was deducted at all from my account. If not I'll just try again to make a payment. Payment date | Total paid | Shares paid | Payment per share
2012-03-25 10:33 0.72943025 353 0.00206637
Perhaps 353 is actually the number of shareholders, many of whom own more than one share? I doubt it. I did not receive your dividend.
Did you import your account to 2.0? When? |
|
|
|
GLBSE is back up again, have another go at paying dividends.
The problem was caused by imported data from GLBSE1.0, it was a case of a single account that had your shares that was stopping the whole process.
Sorry for the delay.
Thanks. Now when I look at the asset page, I get the following entry for the dividends paid: Payment date | Total paid | Shares paid | Payment per share
2012-03-25 10:33 0.72943025 353 0.00206637
0.72943025 is indeed the total that should have been paid. But it should have been paid to 500 shares, at 0.00145886 per share. So what does this mean? 1. Did asset holders receive the described dividend? 2. Was it deducted from my account? 3. Did the holders of the other 147 shares get anything? 4. How do I give payment to them? |
|
|
|
|
Show Posts
