LOL if you have 10,000 transactions in your GUI I think a hatcher scanning them in a timely fashion is going to be the least of your headaches.
Plus, 10k receipt transactions to balance up 20 eMu, that's rather insane, that would be like having $20 in 0.2cent coins!
Go into the bank to pay in all them partial cents, it'll take them longer than just paying with a $20 note, but customers generally don't mind, as they know it's going to take longer.
I'm all for poking around in the limits of a system, but when those limits require scenarios that are virtually non-existent, it makes no sense to spend time pondering them.
That said there is something worth mentioning here as I have thought about these scenarios (just not quite as drastic as this one) where a client, that's holding lots of micro transactions, can aggregate and consolidate all of those micro transactions in to one, large transaction and substitute that into the block tree instead, which ultimately will reduce block tree size and make future processing a bit easier for everyone.
I guess what I am talking about is say 10000 emu or any suitably large amount is composed of a number of prior transaction, in say 3 years time this could easily be composed of many thousands of transactions to get there....so perhaps I am missing something here how does this work |
|
|
|
ok no bites, I must not be meeting market rate!!!!
I will buy 100u AC for 2 LTC,
Deal. I'll send first. Is this offer still standing though? My LTC addy. LUh3pyTLnPoBkhMyThCNvMoXD11x43Unio ok will send, I am running the older LTC on OSX and it wants me to update it, so getting some help over on LTC, I don't want to accidentally do something I shouldn't. (also I want to know if I can avoid change addresses!) Is it still safe to send with the older client, what should the fee be in your opinion to get the transaction through |
|
|
|
If its all micro payments then yes, it can be large, and yes the transaction clear time for that one transaction will be longer, though still faster and more efficient than hashing with large difficulties.
In contrast, if that 20 eMu is dependent on say, a few larger transactions, 5-6 eMu each and those also, then transaction times for those will be very low indeed. Likely seconds as we are seeing.
So the average overall should be acceptable.
I'm not sure how this is going work out when its 10,000 transactions deep x 6 different composite transactions, eg scan though 60,000 priors, and this seems to gets exponentially more difficult due to bitrifications I hope I'm wrong what I dont get is why you can't snapshot every so often, and the complexity of that snapshot is signed, thus making it hard to duplicate, and the snapshot size is sufficient |
|
|
|
No they only have to look back far enough into the dependencies.
So lets say you have a balance of 100, and you want to send out a transaction of 20, you only need to check that 20 of it can be fulfilled by the transaction receipts it is dependent on.
but isn't that still potentially huge? |
|
|
|
has mr.5000 been revealed yet? No. We have stated from the beginning that he will reveal himself when he's "ready". You can guess whatever that means. ok i see so never |
|
|
|
|
3. Setup an escrow and execute.
sooo how does this bit work, the gov's will regulate this part heavily, and how can I trust the escrow, how is this different to gox
what I want is a way to put in my Iban/sepa/BSB wire or whatever and that money is held some how securely in this distributed system, in such a way that I can recall it at any time, before exchanged
then your talking.
Eg bitcoin works because there is not counter party risk within the bitcoin system....I don't need to trust an escrow.
|
|
|
|
Moderate hardware can process a good volume of transactions, no specialist hardware needed to run a basic hatcher, an old 5yr old Dell desktop will churn out a hundred an hour if pushed.
That means that most clients can run as hatchers too, large amount of hatchers in the network means that transaction processing stays fast and smooth.
We are seeing in the beta transaction times, fully confirmed and safe (due to the different model we use), in 15-20 seconds, and everyone is running pretty moderate hardware.
To add to this, I am running one client in a xubuntu vm with only 1 3ghz core and 1gb of ram and it just hums right along. And the tx times are AMAZING compared to btc. Waiting for confirmations is dead! yes but what happens when your record is in the gigs or terrabytes? do not the hatches have to look at/confirm the whole chain?  |
|
|
|
|
ok no bites, I must not be meeting market rate!!!!
I will buy 100u AC for 2 LTC,
|
|
|
|
has mr.5000 been revealed yet? |
|
|
|
|
I am offering LTC for Abstract coin, come and ask in that thread!
|
|
|
|
|
why would I gamble/use a system that is provable = I lose?
|
|
|
|
|
one point
if you build this a nice feature would be to have it work so transactions are done offline by signing, then transferred to another virtual running linux os inside, or other os that only happens when you hit send, an this is what accepts the signed instruction and connects, so it is auto air gapped. The primary os would have no internet driver or so it could not connect, or alternatively if the primary os had to have such this then the virtual os would be the one running you user gui client to make the signing.
This would be done behind the scene away from the user of course
|
|
|
|
Seems like complicated trolling man
confirmed lutz and confirmed |
|
|
|
|
so i see other faster coins are moving back to standard to avoid orphans, eh wdc?
amirite?
|
|
|
|
Moderate hardware can process a good volume of transactions, no specialist hardware needed to run a basic hatcher, an old 5yr old Dell desktop will churn out a hundred an hour if pushed.
That means that most clients can run as hatchers too, large amount of hatchers in the network means that transaction processing stays fast and smooth.
We are seeing in the beta transaction times, fully confirmed and safe (due to the different model we use), in 15-20 seconds, and everyone is running pretty moderate hardware.
so will specialist hardware change this? |
|
|
|
reserved
how does this help cpu mine that is agaisnt botnets which may be just directed at the coin
could I suggest a silent release of the complied qt client, to those who have over x amount of PPC or were registered on the PPC forum before a certain date,
this shows people who are at least dedicated to PPC/ your projects.
Eg the day after I purchased BTC I went around buying up PPC!
If i understand PrimeCoin may act as a bridge to PPC
but I don't understand it the hash rate away from BTC idea, see the overall hash available is increasing, so even if the pie is smaller for BTC this does not make it more vulnerable, also with asics now rolling out and by far the majority of new coins being scrypt his is even less an issue though that could change when everything that produces heat mines as well
on that point, it maybe that all heating elements mine eventually kind of putting a floor under the nergy usage as you were going to it anyway.
Imagine the amount of power a hot water element pulls, and could be directed at mining as well.
Would I like my hot water element to be makieng me btc or some otehr CC, why not!
Cause as we all know, there are absolutely no botnet operators on ppc forum. . Nice try well ok, true, but I think there would be less! maybe, than at large! or rather capture a better selection of no botnet as many botents would then not be able to participate |
|
|
|
|
how does hatching not become a majour bottle neck???
|
|
|
|
adamstgBit(5000uAC) = Wallet[AC0m97S1|adamstgBit]->SendAbstractCoins( ACN1KKE1|Praxis , 250 );
Confirmed adamstgBit(4750uAC) = Wallet[AC0m97S1|adamstgBit]->SendAbstractCoins( wastedbit|wastedbit , 250 ); adamstgBit(4745uAC) = Wallet[AC0m97S1|adamstgBit]->SendAbstractCoins( ACLEZH37|Darktongue , 5 ); confirmed |
|
|
|
|
reserved
how does this help cpu mine that is agaisnt botnets which may be just directed at the coin
could I suggest a silent release of the complied qt client, to those who have over x amount of PPC or were registered on the PPC forum before a certain date,
this shows people who are at least dedicated to PPC/ your projects.
Eg the day after I purchased BTC I went around buying up PPC!
If i understand PrimeCoin may act as a bridge to PPC
but I don't understand it the hash rate away from BTC idea, see the overall hash available is increasing, so even if the pie is smaller for BTC this does not make it more vulnerable, also with asics now rolling out and by far the majority of new coins being scrypt his is even less an issue though that could change when everything that produces heat mines as well
on that point, it maybe that all heating elements mine eventually kind of putting a floor under the nergy usage as you were going to it anyway.
Imagine the amount of power a hot water element pulls, and could be directed at mining as well.
Would I like my hot water element to be makieng me btc or some otehr CC, why not!
|
|
|
|
|
this is almost 1/3 of the killer app for bitcoin because people just need a usb they can associate a wallet and a nice gui front end operates for them....they can copy it and use a password, feel and be secure
the other 1/3 is a distributed exchange
the final third is speed, as in near instant or chain, throw away chains, local chains etc
also you may need to use electrum if the block chain gets to big.....to quickly
|
|
|
|
|
Show Posts
