btw you have a solution on your mind?
Yes
Topic: NXT :: descendant of Bitcoin - Updated Information - page 1046. (Read 2761644 times)
btw you have a solution on your mind?
Yes
Blacklist would contain single numbers and number ranges that you never want to send a SMS to. Things like emergency numbers and premium SMS numbers.
Whitelist would contain known safe numbers and ranges.
Grey list would be the final fall back where numbers that did not match the first two filters would be stored temporarily for a human to look over and decide which of the two filters, black or white, it belongs.
Only send SMSs to numbers that are whitelisted.
Whitelist would contain known safe numbers and ranges.
Grey list would be the final fall back where numbers that did not match the first two filters would be stored temporarily for a human to look over and decide which of the two filters, black or white, it belongs.
Only send SMSs to numbers that are whitelisted.
Shouldn't there be any sms provider who offers this already? So you just have to connect to his API...
How about a NXT -> SMS gateway? Using Arbitrary messages, you send an AM to a NXT account along with 5NXT and your message gets sent via SMS to any phone in the world.
Would this be something interesting to build? Who would use it?
Would this be something interesting to build? Who would use it?
Almost did that myself as a proof-of-concept. Finally didn't do it because you'll have to do a lot of manual filtering.
I'd recommend an approach that uses 3 lists of phone numbers. SMS numbers are filtered in this order:
blacklist
whitelist
greylist
Blacklist would contain single numbers and number ranges that you never want to send a SMS to. Things like emergency numbers and premium SMS numbers.
Whitelist would contain known safe numbers and ranges.
Grey list would be the final fall back where numbers that did not match the first two filters would be stored temporarily for a human to look over and decide which of the two filters, black or white, it belongs.
Only send SMSs to numbers that are whitelisted.
what's this about.
is bill gate going to buy some nxt?
It's the reply to the guy who offered mixing algo for 1M NXT. His sending address was "[email protected]".
This is just unfortunate, sounds like someone is trying to scam you.
btw you have a solution on your mind?
How about a NXT -> SMS gateway? Using Arbitrary messages, you send an AM to a NXT account along with 5NXT and your message gets sent via SMS to any phone in the world.
Would this be something interesting to build? Who would use it?
Would this be something interesting to build? Who would use it?
what's this about.
is bill gate going to buy some nxt?
It's the reply to the guy who offered mixing algo for 1M NXT. His sending address was "[email protected]".
Doesn't somebody already know the bug, and test-exploited it yesterday?
Also, any way to tell what percentage of forging power is upgraded at any moment in time?
Also, any way to tell what percentage of forging power is upgraded at any moment in time?
Yes. (that was 1 time test with 1 NXT amount)
No.
what's this about.
is bill gate going to buy some nxt?
Quite boring day, let's play a game!
In 1000 blocks I'll disclose the critical bug info. If the network doesn't upgrade till that... well, at least we'll have some fun.
In 1000 blocks I'll disclose the critical bug info. If the network doesn't upgrade till that... well, at least we'll have some fun.
Doesn't somebody already know the bug, and test-exploited it yesterday?
Also, any way to tell what percentage of forging power is upgraded at any moment in time?
I don't think a low-memory device like a RaspberryPi would need a full blockchain to forge. It would only need just over 1440 blocks. If it needs to consult blocks that it doesn't have because they're too far in the past, it can get them by querring the API of a public node -- or several public nodes.
It can keep a list of SHA256 hashes of the blocks it deletes to check that the ones it gets from a public node are correct.
Or am I missing something?
It can keep a list of SHA256 hashes of the blocks it deletes to check that the ones it gets from a public node are correct.
Or am I missing something?
BUMP
Please shoot holes in the above.
James, CfB, etc --
Has there been any decision on the low-level VM language?
Has there been any decision on the low-level VM language?
I posted instruction set 10-20 pages ago.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
More detailed change log of 0.6.0:
Hash: SHA1
More detailed change log of 0.6.0:
Thanks. What would Nxt be without you?
edit: eMunie
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
More detailed change log of 0.6.0:
The critical bugfix will still be disclosed later. This is only to document
the other changes from 0.5.12 to 0.6.0, as there are plenty of them.
The 0.5.x branch is really painful for me to work with, after getting used to
the fully refactored code in 0.6.x and 0.7.x. Therefore, I decided to stop
maintaining 0.5.x completely and move on to 0.6.x.
The last bugfix in 0.5.12 was not sufficient, and all forging users should
upgrade to 0.6.0 as soon as possible. 0.5.12 is broken and will not be fixed.
The 0.6.x branch still uses serialized object files, however those are not
backwards compatible with 0.5.x. Old blocks.nxt and transactions.nxt files
from 0.5.x will be imported automatically and converted to the new format
the first time 0.6.0 is run.
The blockchainStoragePath parameter in web.xml is no longer needed.
The code has been significantly refactored and is no longer a single java file.
All classes previously nested in Nxt have been moved out to their own files.
Everything is under a top level nxt package, and as a result the servlet-class
parameter in web.xml has to be changed to nxt.Nxt. Sorry that I forgot to
mention that when releasing 0.6.0:
Nxt
nxt.Nxt
There are three subpackages, nxt.user, nxt.peer, and nxt.http, with request
handlers in separate classes for all the UI, peer to peer, and http API
requests respectively. This completely replaces the old huge switch/case
statements in the servlet doGet and doPost methods.
All the business logic has been moved out of the Nxt servlet class.
A new Transaction.Type class hierarchy has been added to handle all logic
for transaction validation, transaction attachment handling, and transaction
application. This completely replaces the switch statements that used to
hold the transaction validation and processing logic.
Transaction undo, on block pop-off, has been implemented for transactions which
can be undone. For all others, an UndoNotSupportedException triggers a full
blockchain rescan.
A custom NxtException exception hierarchy is now used to help with block and
transaction validation. Most transaction and block parameters are now enforced
to be valid in the Transaction and Block constructors, which makes it sort of
difficult to forget to validate them.
Many minor and not so minor performance and memory optimizations, based on
actual profiling measurements, have been applied.
All field and method access modifiers have been reviewed. No java field or method
is more accessible than it needs to be. Everything that can be private, is now
private. Everything that should be final, is now final.
All JSON response and error handling has been cleaned up and optimized.
Unnecessary to and from ByteBuffer conversions in block and transaction processing
have been removed.
A deadline limit of not more than 1440 minutes for new transactions is now enforced.
Peers that submit invalid block or transaction data are automatically blacklisted.
Java API documentation is now available at http://localhost:7874/doc/ , all APIs
are subject to change as it is work in progress.
Minor UI changes: added warnings to the unlock account dialog and message.html,
added sendMoney to admin.html.
New or improved APIs:
getAccount
parameter: account (the account id)
returns: publicKey (if known), balance, effectiveBalance, all asset balances
getAsset
parameter: asset (the asset id)
returns: accountId of the asset issuer, asset name, description and quantity
getAssetIds
returns: all existing asset id's.
getAskOrderIds and getBidOrderIds now require an asset parameter, and return
the order id's for that asset only.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJS82bBAAoJEFOhyXc7+e2A9UYP/ignHYDkNQsl7mIEmtHjLXQL
Vnhk2qdpR4g1N9JS7Q7JjzlhW9XzMT5aCiEqWgl4hi2zq1ymPL6McO1zD5IxQz1N
tDy1MnjXYp3SrabqnOhPGF/VHqO7VACaCi2uboBHo9fTF+TzW8fu7UD/4oo9LTLl
EaHrKTmBBPjAXooTP7eHgGhUbKi3cc0adwDppK9m0XZKoo7igkt6Rn91p4TXNwYf
WKUY6cce4BdhdtlUsGXKNLPKXEBxIG74MzTyb+2KT4TqlREQkVWV5e4+wctdgj5+
Hrh0lTUvDomzoT+ohXVxgkSKILvGHanX8t1laTkNpjVMqFbSGI9ViJfazFq5heXw
rs/bi9IclFBQvSowz3pToCC8VVxQm6sYrjOj1k2+wVPIie2qWCDj+4WOOqnYf8P8
QNUqP0VncJ0n0RjlvBlX5LQRENekHIR4SaI5rCPcppwz/tNQGB6tDfbXqUT7V77m
Oxg869TOknszSaPu3M/D63Y0i2tn+R27fuaAcvBeKK5ArGlKAlwMSQgjpocoxRos
RJan41fv50YfenniyTjYkRAx0R3iXiFNrdMD3lqEntYyqSxfviZf1fSpUazheMNW
7JwTfOpcV2mTObPMr1ZKJWz2yl1CzPy/J4caA7SXGkzB1nc/onkjJWHYNSBRyGLr
+0/q4Hc0x3XYVvyHM4ng
=OQ1o
-----END PGP SIGNATURE-----
Hash: SHA1
More detailed change log of 0.6.0:
The critical bugfix will still be disclosed later. This is only to document
the other changes from 0.5.12 to 0.6.0, as there are plenty of them.
The 0.5.x branch is really painful for me to work with, after getting used to
the fully refactored code in 0.6.x and 0.7.x. Therefore, I decided to stop
maintaining 0.5.x completely and move on to 0.6.x.
The last bugfix in 0.5.12 was not sufficient, and all forging users should
upgrade to 0.6.0 as soon as possible. 0.5.12 is broken and will not be fixed.
The 0.6.x branch still uses serialized object files, however those are not
backwards compatible with 0.5.x. Old blocks.nxt and transactions.nxt files
from 0.5.x will be imported automatically and converted to the new format
the first time 0.6.0 is run.
The blockchainStoragePath parameter in web.xml is no longer needed.
The code has been significantly refactored and is no longer a single java file.
All classes previously nested in Nxt have been moved out to their own files.
Everything is under a top level nxt package, and as a result the servlet-class
parameter in web.xml has to be changed to nxt.Nxt. Sorry that I forgot to
mention that when releasing 0.6.0:
There are three subpackages, nxt.user, nxt.peer, and nxt.http, with request
handlers in separate classes for all the UI, peer to peer, and http API
requests respectively. This completely replaces the old huge switch/case
statements in the servlet doGet and doPost methods.
All the business logic has been moved out of the Nxt servlet class.
A new Transaction.Type class hierarchy has been added to handle all logic
for transaction validation, transaction attachment handling, and transaction
application. This completely replaces the switch statements that used to
hold the transaction validation and processing logic.
Transaction undo, on block pop-off, has been implemented for transactions which
can be undone. For all others, an UndoNotSupportedException triggers a full
blockchain rescan.
A custom NxtException exception hierarchy is now used to help with block and
transaction validation. Most transaction and block parameters are now enforced
to be valid in the Transaction and Block constructors, which makes it sort of
difficult to forget to validate them.
Many minor and not so minor performance and memory optimizations, based on
actual profiling measurements, have been applied.
All field and method access modifiers have been reviewed. No java field or method
is more accessible than it needs to be. Everything that can be private, is now
private. Everything that should be final, is now final.
All JSON response and error handling has been cleaned up and optimized.
Unnecessary to and from ByteBuffer conversions in block and transaction processing
have been removed.
A deadline limit of not more than 1440 minutes for new transactions is now enforced.
Peers that submit invalid block or transaction data are automatically blacklisted.
Java API documentation is now available at http://localhost:7874/doc/ , all APIs
are subject to change as it is work in progress.
Minor UI changes: added warnings to the unlock account dialog and message.html,
added sendMoney to admin.html.
New or improved APIs:
getAccount
parameter: account (the account id)
returns: publicKey (if known), balance, effectiveBalance, all asset balances
getAsset
parameter: asset (the asset id)
returns: accountId of the asset issuer, asset name, description and quantity
getAssetIds
returns: all existing asset id's.
getAskOrderIds and getBidOrderIds now require an asset parameter, and return
the order id's for that asset only.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJS82bBAAoJEFOhyXc7+e2A9UYP/ignHYDkNQsl7mIEmtHjLXQL
Vnhk2qdpR4g1N9JS7Q7JjzlhW9XzMT5aCiEqWgl4hi2zq1ymPL6McO1zD5IxQz1N
tDy1MnjXYp3SrabqnOhPGF/VHqO7VACaCi2uboBHo9fTF+TzW8fu7UD/4oo9LTLl
EaHrKTmBBPjAXooTP7eHgGhUbKi3cc0adwDppK9m0XZKoo7igkt6Rn91p4TXNwYf
WKUY6cce4BdhdtlUsGXKNLPKXEBxIG74MzTyb+2KT4TqlREQkVWV5e4+wctdgj5+
Hrh0lTUvDomzoT+ohXVxgkSKILvGHanX8t1laTkNpjVMqFbSGI9ViJfazFq5heXw
rs/bi9IclFBQvSowz3pToCC8VVxQm6sYrjOj1k2+wVPIie2qWCDj+4WOOqnYf8P8
QNUqP0VncJ0n0RjlvBlX5LQRENekHIR4SaI5rCPcppwz/tNQGB6tDfbXqUT7V77m
Oxg869TOknszSaPu3M/D63Y0i2tn+R27fuaAcvBeKK5ArGlKAlwMSQgjpocoxRos
RJan41fv50YfenniyTjYkRAx0R3iXiFNrdMD3lqEntYyqSxfviZf1fSpUazheMNW
7JwTfOpcV2mTObPMr1ZKJWz2yl1CzPy/J4caA7SXGkzB1nc/onkjJWHYNSBRyGLr
+0/q4Hc0x3XYVvyHM4ng
=OQ1o
-----END PGP SIGNATURE-----
James, CfB, etc --
Has there been any decision on the low-level VM language?
Has there been any decision on the low-level VM language?
- SMS gateway (bounty by CfB community) must be developed (eg Africa is using SMS as some sort of currency). This would be a really nice feature, especially for marketing
Where can I find info on this bounty please?
https://bitcointalksearch.org/topic/m.4596611
Bounty announcement
1st one who implements a working (during 7 days at least) SMS-to-NXT gateway will get a bounty. Amount of the bounty will be considered by the community.
Deadline: 28th of February, 2014.
1st one who implements a working (during 7 days at least) SMS-to-NXT gateway will get a bounty. Amount of the bounty will be considered by the community.
Deadline: 28th of February, 2014.
Hm.... this could be quite a cool thing to add to the mynxt.info wallet. But there are so many risks and challenges...
1) There is a risk of charge backs
2) Where to get the NXT from to give to users that make a deposit using SMS?
3) Regulatory concerns: would I be a money transmitter?
4) etc...
Will this affect those, who upgraded to 0.6 and continues forging?
No
PS: Maybe I'm a little bit crazy, but not crazy enough to kill Nxt.
It seems that bitcoin is in some trouble and not moving past $800 for very long time and there are people going around doing lots of pumping and dumping through the list of altcoins just to be sane?
First was Doge, Then there was Kitteh,.. Yesterday was Vertcoin, today is Astro then eToken, few more hours later is going to be another one... all of it is going through 200%-400% boosts, it just doesn't stop! Some pumper is getting really rich.
First was Doge, Then there was Kitteh,.. Yesterday was Vertcoin, today is Astro then eToken, few more hours later is going to be another one... all of it is going through 200%-400% boosts, it just doesn't stop! Some pumper is getting really rich.
Quite boring day, let's play a game!
In 1000 blocks I'll disclose the critical bug info. If the network doesn't upgrade till that... well, at least we'll have some fun.
Current block is
PS: There is another way to keep my mouth shut - stop forging before 1000th block comes.
Will this affect those, who upgraded to 0.6 and continues forging? In 1000 blocks I'll disclose the critical bug info. If the network doesn't upgrade till that... well, at least we'll have some fun.
Current block is
Code:
59427 10006970057300228034 6.2.2014 13:13:28
0 0 + 0 0 B
2 1386255593342569532 821 %
PS: There is another way to keep my mouth shut - stop forging before 1000th block comes.
Jump to: